CVE-2024-43835 (GCVE-0-2024-43835)

Vulnerability from cvelistv5 – Published: 2024-08-17 09:21 – Updated: 2026-05-11 20:30

Title

virtio_net: Fix napi_skb_cache_put warning

Summary

In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix napi_skb_cache_put warning After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case. To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context.

Severity

No CVSS data available.

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-09-10 16:08 UTC

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6667 records in the last 180 days details

References

9 references

URL	Tags
https://git.kernel.org/stable/c/d3af435e8ace119e5…
https://git.kernel.org/stable/c/842a97b5e44f0c8a9…
https://git.kernel.org/stable/c/cc7340f18e4588612…
https://git.kernel.org/stable/c/6b5325f2457521bbe…
https://git.kernel.org/stable/c/f5e9a22d19bb98a7e…
https://git.kernel.org/stable/c/468a729b78895893d…
https://git.kernel.org/stable/c/f8321fa75102246d7…
https://lists.debian.org/debian-lts-announce/2025…
https://lists.debian.org/debian-lts-announce/2024…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa (git) Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < 842a97b5e44f0c8a9fc356fe976e0e13ddcf7783 (git) Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < cc7340f18e45886121c131227985d64ef666012f (git) Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < 6b5325f2457521bbece29499970c0117a648c620 (git) Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < f5e9a22d19bb98a7e86034db85eb295e94187caa (git) Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < 468a729b78895893d0e580ceea49bed8ada2a2bd (git) Affected: df133f3f96257ee29696c0ed8bd198ec801dc810 , < f8321fa75102246d7415a6af441872f6637c93ab (git)	guessed
Linux	Linux	Affected: 5.0 Unaffected: 0 , < 5.0 (semver) Unaffected: 5.4.284 , ≤ 5.4.* (semver) Unaffected: 5.10.226 , ≤ 5.10.* (semver) Unaffected: 5.15.167 , ≤ 5.15.* (semver) Unaffected: 6.1.109 , ≤ 6.1.* (semver) Unaffected: 6.6.50 , ≤ 6.6.* (semver) Unaffected: 6.10.3 , ≤ 6.10.* (semver) Unaffected: 6.11 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-43835",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:08:14.954725Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-12T17:33:23.316Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2025-11-03T22:05:26.358Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
          },
          {
            "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/virtio_net.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "842a97b5e44f0c8a9fc356fe976e0e13ddcf7783",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "cc7340f18e45886121c131227985d64ef666012f",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "6b5325f2457521bbece29499970c0117a648c620",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "f5e9a22d19bb98a7e86034db85eb295e94187caa",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "468a729b78895893d0e580ceea49bed8ada2a2bd",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "f8321fa75102246d7415a6af441872f6637c93ab",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/virtio_net.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.0"
            },
            {
              "lessThan": "5.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.284",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.226",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.167",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.109",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.11",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.284",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.226",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.167",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.109",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.50",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10.3",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11",
                  "versionStartIncluding": "5.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix napi_skb_cache_put warning\n\nAfter the commit bdacf3e34945 (\"net: Use nested-BH locking for\nnapi_alloc_cache.\") was merged, the following warning began to appear:\n\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\n\n\t  __warn+0x12f/0x340\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  report_bug+0x165/0x370\n\t  handle_bug+0x3d/0x80\n\t  exc_invalid_op+0x1a/0x50\n\t  asm_exc_invalid_op+0x1a/0x20\n\t  __free_old_xmit+0x1c8/0x510\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  __free_old_xmit+0x1c8/0x510\n\t  __free_old_xmit+0x1c8/0x510\n\t  __pfx___free_old_xmit+0x10/0x10\n\nThe issue arises because virtio is assuming it\u0027s running in NAPI context\neven when it\u0027s not, such as in the netpoll case.\n\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:30:44.066Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa"
        },
        {
          "url": "https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783"
        },
        {
          "url": "https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f"
        },
        {
          "url": "https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620"
        },
        {
          "url": "https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa"
        },
        {
          "url": "https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd"
        },
        {
          "url": "https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"
        }
      ],
      "title": "virtio_net: Fix napi_skb_cache_put warning",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-43835",
    "datePublished": "2024-08-17T09:21:52.425Z",
    "dateReserved": "2024-08-17T09:11:59.274Z",
    "dateUpdated": "2026-05-11T20:30:44.066Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-43835",
      "date": "2026-10-15",
      "epss": "0.0025",
      "percentile": "0.15145"
    },
    "microsoft_vex": {
      "current_release_date": "2026-02-21T01:57:33.000Z",
      "cve": "CVE-2024-43835",
      "id": "msrc_CVE-2024-43835",
      "initial_release_date": "2024-08-02T00:00:00.000Z",
      "product_status:fixed": "5",
      "product_status:known_affected": "5",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "virtio_net: Fix napi_skb_cache_put warning",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-43835.json",
      "version": "2"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/virtio_net.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "842a97b5e44f0c8a9fc356fe976e0e13ddcf7783",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "cc7340f18e45886121c131227985d64ef666012f",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6b5325f2457521bbece29499970c0117a648c620",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "f5e9a22d19bb98a7e86034db85eb295e94187caa",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "468a729b78895893d0e580ceea49bed8ada2a2bd",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "f8321fa75102246d7415a6af441872f6637c93ab",
                    "status": "affected",
                    "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/virtio_net.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "5.0"
                  },
                  {
                    "lessThan": "5.0",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.284",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.226",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.167",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.109",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.50",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.10.*",
                    "status": "unaffected",
                    "version": "6.10.3",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.11",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "24574782-30C5-4044-BD18-A21100B2C80D",
                    "versionEndExcluding": "6.10.3",
                    "versionStartIncluding": "5.0",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix napi_skb_cache_put warning\n\nAfter the commit bdacf3e34945 (\"net: Use nested-BH locking for\nnapi_alloc_cache.\") was merged, the following warning began to appear:\n\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\n\n\t  __warn+0x12f/0x340\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  report_bug+0x165/0x370\n\t  handle_bug+0x3d/0x80\n\t  exc_invalid_op+0x1a/0x50\n\t  asm_exc_invalid_op+0x1a/0x20\n\t  __free_old_xmit+0x1c8/0x510\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  __free_old_xmit+0x1c8/0x510\n\t  __free_old_xmit+0x1c8/0x510\n\t  __pfx___free_old_xmit+0x10/0x10\n\nThe issue arises because virtio is assuming it\u0027s running in NAPI context\neven when it\u0027s not, such as in the netpoll case.\n\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: virtio_net: corrige la advertencia de napi_skb_cache_put Despu\u00e9s de que se fusion\u00f3 el commit bdacf3e34945 (\"net: Use bloqueo de BH anidado para napi_alloc_cache.\"), comenz\u00f3 a aparecer la siguiente advertencia: ADVERTENCIA: CPU: 5 PID: 1 en net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+ 0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 El problema surge porque virtio asumiendo que se est\u00e1 ejecutando en el contexto NAPI incluso cuando no lo es, como en netpoll caso. Para resolver esto, modifique virtnet_poll_tx() para configurar NAPI solo cuando haya presupuesto disponible. Lo mismo ocurre con virtnet_poll_cleantx(), que siempre asumi\u00f3 que estaba en un contexto NAPI."
          }
        ],
        "id": "CVE-2024-43835",
        "lastModified": "2026-06-17T07:51:48.363",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2024-43835",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:08:14.954725Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-08-17T10:15:09.183",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "NVD-CWE-noinfo"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2025-11-21T14:25:44+00:00",
      "cve": "CVE-2024-43835",
      "id": "CVE-2024-43835",
      "initial_release_date": "2024-08-17T00:00:00+00:00",
      "product_status:known_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: virtio_net: Fix napi_skb_cache_put warning",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-43835.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2025-11-03T22:05:26.358Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
              },
              {
                "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-43835",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-10T16:08:14.954725Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-11T12:42:23.121Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/net/virtio_net.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                },
                {
                  "lessThan": "842a97b5e44f0c8a9fc356fe976e0e13ddcf7783",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                },
                {
                  "lessThan": "cc7340f18e45886121c131227985d64ef666012f",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                },
                {
                  "lessThan": "6b5325f2457521bbece29499970c0117a648c620",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                },
                {
                  "lessThan": "f5e9a22d19bb98a7e86034db85eb295e94187caa",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                },
                {
                  "lessThan": "468a729b78895893d0e580ceea49bed8ada2a2bd",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                },
                {
                  "lessThan": "f8321fa75102246d7415a6af441872f6637c93ab",
                  "status": "affected",
                  "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/net/virtio_net.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "5.0"
                },
                {
                  "lessThan": "5.0",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.284",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.226",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.167",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.109",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.50",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.10.*",
                  "status": "unaffected",
                  "version": "6.10.3",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.11",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.4.284",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.10.226",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.15.167",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.1.109",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.50",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.10.3",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.11",
                      "versionStartIncluding": "5.0",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix napi_skb_cache_put warning\n\nAfter the commit bdacf3e34945 (\"net: Use nested-BH locking for\nnapi_alloc_cache.\") was merged, the following warning began to appear:\n\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\n\n\t  __warn+0x12f/0x340\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  report_bug+0x165/0x370\n\t  handle_bug+0x3d/0x80\n\t  exc_invalid_op+0x1a/0x50\n\t  asm_exc_invalid_op+0x1a/0x20\n\t  __free_old_xmit+0x1c8/0x510\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  __free_old_xmit+0x1c8/0x510\n\t  __free_old_xmit+0x1c8/0x510\n\t  __pfx___free_old_xmit+0x10/0x10\n\nThe issue arises because virtio is assuming it\u0027s running in NAPI context\neven when it\u0027s not, such as in the netpoll case.\n\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-05-11T20:30:44.066Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa"
            },
            {
              "url": "https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783"
            },
            {
              "url": "https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f"
            },
            {
              "url": "https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620"
            },
            {
              "url": "https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa"
            },
            {
              "url": "https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd"
            },
            {
              "url": "https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"
            }
          ],
          "title": "virtio_net: Fix napi_skb_cache_put warning",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2024-43835",
        "datePublished": "2024-08-17T09:21:52.425Z",
        "dateReserved": "2024-08-17T09:11:59.274Z",
        "dateUpdated": "2026-05-11T20:30:44.066Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2024-43835

Vulnerability from fkie_nvd - Published: 2024-08-17 10:15 - Updated: 2026-06-17 07:51

Severity

5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Summary

References

URL	Tags
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab	Patch
af854a3a-2127-422b-91ae-364da2661108	https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
af854a3a-2127-422b-91ae-364da2661108	https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html

Impacted products

	Vendor	Product	Version
	linux	linux_kernel	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/virtio_net.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "842a97b5e44f0c8a9fc356fe976e0e13ddcf7783",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "cc7340f18e45886121c131227985d64ef666012f",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "6b5325f2457521bbece29499970c0117a648c620",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "f5e9a22d19bb98a7e86034db85eb295e94187caa",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "468a729b78895893d0e580ceea49bed8ada2a2bd",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            },
            {
              "lessThan": "f8321fa75102246d7415a6af441872f6637c93ab",
              "status": "affected",
              "version": "df133f3f96257ee29696c0ed8bd198ec801dc810",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/virtio_net.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.0"
            },
            {
              "lessThan": "5.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.284",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.226",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.167",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.109",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.11",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "24574782-30C5-4044-BD18-A21100B2C80D",
              "versionEndExcluding": "6.10.3",
              "versionStartIncluding": "5.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix napi_skb_cache_put warning\n\nAfter the commit bdacf3e34945 (\"net: Use nested-BH locking for\nnapi_alloc_cache.\") was merged, the following warning began to appear:\n\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\n\n\t  __warn+0x12f/0x340\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  report_bug+0x165/0x370\n\t  handle_bug+0x3d/0x80\n\t  exc_invalid_op+0x1a/0x50\n\t  asm_exc_invalid_op+0x1a/0x20\n\t  __free_old_xmit+0x1c8/0x510\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  __free_old_xmit+0x1c8/0x510\n\t  __free_old_xmit+0x1c8/0x510\n\t  __pfx___free_old_xmit+0x10/0x10\n\nThe issue arises because virtio is assuming it\u0027s running in NAPI context\neven when it\u0027s not, such as in the netpoll case.\n\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: virtio_net: corrige la advertencia de napi_skb_cache_put Despu\u00e9s de que se fusion\u00f3 el commit bdacf3e34945 (\"net: Use bloqueo de BH anidado para napi_alloc_cache.\"), comenz\u00f3 a aparecer la siguiente advertencia: ADVERTENCIA: CPU: 5 PID: 1 en net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+ 0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 El problema surge porque virtio asumiendo que se est\u00e1 ejecutando en el contexto NAPI incluso cuando no lo es, como en netpoll caso. Para resolver esto, modifique virtnet_poll_tx() para configurar NAPI solo cuando haya presupuesto disponible. Lo mismo ocurre con virtnet_poll_cleantx(), que siempre asumi\u00f3 que estaba en un contexto NAPI."
    }
  ],
  "id": "CVE-2024-43835",
  "lastModified": "2026-06-17T07:51:48.363",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-43835",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-10T16:08:14.954725Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-08-17T10:15:09.183",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "NVD-CWE-noinfo"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

GHSA-VGJ5-HQJJ-6HCJ

Vulnerability from github – Published: 2024-08-17 12:30 – Updated: 2025-11-04 00:31

Details

In the Linux kernel, the following vulnerability has been resolved:

virtio_net: Fix napi_skb_cache_put warning

After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear:

 WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0

  __warn+0x12f/0x340
  napi_skb_cache_put+0x82/0x4b0
  napi_skb_cache_put+0x82/0x4b0
  report_bug+0x165/0x370
  handle_bug+0x3d/0x80
  exc_invalid_op+0x1a/0x50
  asm_exc_invalid_op+0x1a/0x20
  __free_old_xmit+0x1c8/0x510
  napi_skb_cache_put+0x82/0x4b0
  __free_old_xmit+0x1c8/0x510
  __free_old_xmit+0x1c8/0x510
  __pfx___free_old_xmit+0x10/0x10

The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case.

To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-43835"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-17T10:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix napi_skb_cache_put warning\n\nAfter the commit bdacf3e34945 (\"net: Use nested-BH locking for\nnapi_alloc_cache.\") was merged, the following warning began to appear:\n\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\n\n\t  __warn+0x12f/0x340\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  report_bug+0x165/0x370\n\t  handle_bug+0x3d/0x80\n\t  exc_invalid_op+0x1a/0x50\n\t  asm_exc_invalid_op+0x1a/0x20\n\t  __free_old_xmit+0x1c8/0x510\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  __free_old_xmit+0x1c8/0x510\n\t  __free_old_xmit+0x1c8/0x510\n\t  __pfx___free_old_xmit+0x10/0x10\n\nThe issue arises because virtio is assuming it\u0027s running in NAPI context\neven when it\u0027s not, such as in the netpoll case.\n\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context.",
  "id": "GHSA-vgj5-hqjj-6hcj",
  "modified": "2025-11-04T00:31:15Z",
  "published": "2024-08-17T12:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43835"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/19ac6f29bf64304ef04630c8ab56ecd2059d7aa1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

MSRC_CVE-2024-43835

Vulnerability from csaf_microsoft - Published: 2024-08-02 00:00 - Updated: 2026-02-21 01:57

Summary

virtio_net: Fix napi_skb_cache_put warning

Scope

1 vulnerability in this advisory, including CVE-2024-43835.

CVE-2024-43835

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Fixed: 5 products Known affected: 5 products

https://learn.microsoft.com/en-us/azure/azure-linux/tutoria…

Open the full advisory

OESA-2024-2446 (CVE-2024-26944)

Vulnerability from osv_openeuler – Published: 2024-11-22 11:07 – Updated: 2026-08-06 11:07 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

btrfs: zoned: fix use-after-free in do_zone_finish()

Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070.

BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007

CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK>

Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76

The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)

The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish().

The sequence of events is as follows:

btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed

cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device

The reason for this is that we're using a ---truncated---(CVE-2024-26944)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: HCI: Fix potential null-ptr-deref

Fix potential null-ptr-deref in hci_le_big_sync_established_evt().(CVE-2024-36011)

In the Linux kernel, the following vulnerability has been resolved:

virtio_net: Fix napi_skb_cache_put warning

After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear:

 WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0

  __warn+0x12f/0x340
  napi_skb_cache_put+0x82/0x4b0
  napi_skb_cache_put+0x82/0x4b0
  report_bug+0x165/0x370
  handle_bug+0x3d/0x80
  exc_invalid_op+0x1a/0x50
  asm_exc_invalid_op+0x1a/0x20
  __free_old_xmit+0x1c8/0x510
  napi_skb_cache_put+0x82/0x4b0
  __free_old_xmit+0x1c8/0x510
  __free_old_xmit+0x1c8/0x510
  __pfx___free_old_xmit+0x10/0x10

The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case.

To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context.(CVE-2024-43835)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix NULL dereference at band check in starting tx ba session

In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink.

Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz

Code starting with the faulting instruction

0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator ---truncated---(CVE-2024-43911)

In the Linux kernel, the following vulnerability has been resolved:

bonding: fix xfrm real_dev null pointer dereference

We shouldn't set real_dev to NULL because packets can be in transit and xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume real_dev is set.

Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: <TASK> kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80(CVE-2024-44989)

In the Linux kernel, the following vulnerability has been resolved:

igb: cope with large MAX_SKB_FRAGS

Sabrina reports that the igb driver does not cope well with large MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload corruption on TX.

An easy reproducer is to run ssh to connect to the machine. With MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320

The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head.

Address the issue by checking if 2K buffers are insufficient.(CVE-2024-45030)

In the Linux kernel, the following vulnerability has been resolved:

bonding: change ipsec_lock from spin lock to mutex

In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave.

[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] <TASK> [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53

As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.(CVE-2024-46678)

In the Linux kernel, the following vulnerability has been resolved:

fou: Fix null-ptr-deref in GRO.

We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0]

The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou.

When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period.

So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL.

Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers.

[0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) </IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated---(CVE-2024-46763)

In the Linux kernel, the following vulnerability has been resolved:

tcp_bpf: fix return value of tcp_bpf_sendmsg()

When we cork messages in psock->cork, the last message triggers the flushing will result in sending a sk_msg larger than the current message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes negative at least in the following case:

468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES;

Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here.

------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---(CVE-2024-46783)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix smatch static checker warning

adev->gfx.imu.funcs could be NULL(CVE-2024-46835)

In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Set phy->enable_completion only when we wait for it

pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.(CVE-2024-47666)

In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.(CVE-2024-47674)

In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)

In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)

In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().(CVE-2024-50056)

In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.(CVE-2024-50061)

In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)

In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)

In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.(CVE-2024-50115)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix UAF on iso_sock_timeout conn->sk maybe have been unlinked/freed while waiting for iso_conn_lock so this checks if the conn->sk is still valid by checking if it part of iso_sk_list.(CVE-2024-50124)

In the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)

(CVE-2024-50151)

In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device().(CVE-2024-50153)

In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)

In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.(CVE-2024-50193)

In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)

In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-50215)

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.(CVE-2024-50243)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)

In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.(CVE-2024-50250)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26944	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36011	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43835	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43911	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-44989	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-45030	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46678	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46763	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46783	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46835	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47666	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47674	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47723	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47728	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49945	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50056	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50061	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50089	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50099	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50115	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50124	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50138	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50151	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50153	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50180	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50193	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50198	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50202	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50215	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50237	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50242	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50243	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50244	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50245	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50246	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50247	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50250	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "perf-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-55.0.0.58.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-55.0.0.58.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-55.0.0.58.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "perf-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-55.0.0.58.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-55.0.0.58.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-55.0.0.58.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: zoned: fix use-after-free in do_zone_finish()\r\n\r\nShinichiro reported the following use-after-free triggered by the device\nreplace operation in fstests btrfs/070.\r\n\r\n BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0\n ==================================================================\n BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs]\n Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007\r\n\r\n CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G        W          6.8.0-rc5-kts #1\n Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x5b/0x90\n  print_report+0xcf/0x670\n  ? __virt_addr_valid+0x200/0x3e0\n  kasan_report+0xd8/0x110\n  ? do_zone_finish+0x91a/0xb90 [btrfs]\n  ? do_zone_finish+0x91a/0xb90 [btrfs]\n  do_zone_finish+0x91a/0xb90 [btrfs]\n  btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs]\n  ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs]\n  ? btrfs_put_root+0x2d/0x220 [btrfs]\n  ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs]\n  cleaner_kthread+0x21e/0x380 [btrfs]\n  ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]\n  kthread+0x2e3/0x3c0\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x31/0x70\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1b/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 3493983:\n  kasan_save_stack+0x33/0x60\n  kasan_save_track+0x14/0x30\n  __kasan_kmalloc+0xaa/0xb0\n  btrfs_alloc_device+0xb3/0x4e0 [btrfs]\n  device_list_add.constprop.0+0x993/0x1630 [btrfs]\n  btrfs_scan_one_device+0x219/0x3d0 [btrfs]\n  btrfs_control_ioctl+0x26e/0x310 [btrfs]\n  __x64_sys_ioctl+0x134/0x1b0\n  do_syscall_64+0x99/0x190\n  entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n Freed by task 3494056:\n  kasan_save_stack+0x33/0x60\n  kasan_save_track+0x14/0x30\n  kasan_save_free_info+0x3f/0x60\n  poison_slab_object+0x102/0x170\n  __kasan_slab_free+0x32/0x70\n  kfree+0x11b/0x320\n  btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs]\n  btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs]\n  btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs]\n  btrfs_ioctl+0xb27/0x57d0 [btrfs]\n  __x64_sys_ioctl+0x134/0x1b0\n  do_syscall_64+0x99/0x190\n  entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n The buggy address belongs to the object at ffff8881543c8000\n  which belongs to the cache kmalloc-1k of size 1024\n The buggy address is located 96 bytes inside of\n  freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)\r\n\r\n The buggy address belongs to the physical page:\n page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8\n head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)\n page_type: 0xffffffff()\n raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002\n raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\r\n\r\n Memory state around the buggy address:\n  ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                                        ^\n  ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\r\n\r\nThis UAF happens because we\u0026apos;re accessing stale zone information of a\nalready removed btrfs_device in do_zone_finish().\r\n\r\nThe sequence of events is as follows:\r\n\r\nbtrfs_dev_replace_start\n  btrfs_scrub_dev\n   btrfs_dev_replace_finishing\n    btrfs_dev_replace_update_device_in_mapping_tree \u0026lt;-- devices replaced\n    btrfs_rm_dev_replace_free_srcdev\n     btrfs_free_device                              \u0026lt;-- device freed\r\n\r\ncleaner_kthread\n btrfs_delete_unused_bgs\n  btrfs_zone_finish\n   do_zone_finish              \u0026lt;-- refers the freed device\r\n\r\nThe reason for this is that we\u0026apos;re using a\n---truncated---(CVE-2024-26944)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: HCI: Fix potential null-ptr-deref\r\n\r\nFix potential null-ptr-deref in hci_le_big_sync_established_evt().(CVE-2024-36011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvirtio_net: Fix napi_skb_cache_put warning\r\n\r\nAfter the commit bdacf3e34945 (\u0026quot;net: Use nested-BH locking for\nnapi_alloc_cache.\u0026quot;) was merged, the following warning began to appear:\r\n\r\n\t WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0\r\n\r\n\t  __warn+0x12f/0x340\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  report_bug+0x165/0x370\n\t  handle_bug+0x3d/0x80\n\t  exc_invalid_op+0x1a/0x50\n\t  asm_exc_invalid_op+0x1a/0x20\n\t  __free_old_xmit+0x1c8/0x510\n\t  napi_skb_cache_put+0x82/0x4b0\n\t  __free_old_xmit+0x1c8/0x510\n\t  __free_old_xmit+0x1c8/0x510\n\t  __pfx___free_old_xmit+0x10/0x10\r\n\r\nThe issue arises because virtio is assuming it\u0026apos;s running in NAPI context\neven when it\u0026apos;s not, such as in the netpoll case.\r\n\r\nTo resolve this, modify virtnet_poll_tx() to only set NAPI when budget\nis available. Same for virtnet_poll_cleantx(), which always assumed that\nit was in a NAPI context.(CVE-2024-43835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: fix NULL dereference at band check in starting tx ba session\r\n\r\nIn MLD connection, link_data/link_conf are dynamically allocated. They\ndon\u0026apos;t point to vif-\u0026gt;bss_conf. So, there will be no chanreq assigned to\nvif-\u0026gt;bss_conf and then the chan will be NULL. Tweak the code to check\nht_supported/vht_supported/has_he/has_eht on sta deflink.\r\n\r\nCrash log (with rtw89 version under MLO development):\n[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 9890.526102] #PF: supervisor read access in kernel mode\n[ 9890.526105] #PF: error_code(0x0000) - not-present page\n[ 9890.526109] PGD 0 P4D 0\n[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G           OE      6.9.0 #1\n[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018\n[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]\n[ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211\n[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 \u0026lt;83\u0026gt; 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3\nAll code\n========\n   0:\tf7 e8                \timul   %eax\n   2:\td5                   \t(bad)\n   3:\t93                   \txchg   %eax,%ebx\n   4:\t3e ea                \tds (bad)\n   6:\t48 83 c4 28          \tadd    $0x28,%rsp\n   a:\t89 d8                \tmov    %ebx,%eax\n   c:\t5b                   \tpop    %rbx\n   d:\t41 5c                \tpop    %r12\n   f:\t41 5d                \tpop    %r13\n  11:\t41 5e                \tpop    %r14\n  13:\t41 5f                \tpop    %r15\n  15:\t5d                   \tpop    %rbp\n  16:\tc3                   \tretq\n  17:\tcc                   \tint3\n  18:\tcc                   \tint3\n  19:\tcc                   \tint3\n  1a:\tcc                   \tint3\n  1b:\t49 8b 84 24 e0 f1 ff \tmov    -0xe20(%r12),%rax\n  22:\tff\n  23:\t48 8b 80 90 1b 00 00 \tmov    0x1b90(%rax),%rax\n  2a:*\t83 38 03             \tcmpl   $0x3,(%rax)\t\t\u0026lt;-- trapping instruction\n  2d:\t0f 84 37 fe ff ff    \tje     0xfffffffffffffe6a\n  33:\tbb ea ff ff ff       \tmov    $0xffffffea,%ebx\n  38:\teb cc                \tjmp    0x6\n  3a:\t49                   \trex.WB\n  3b:\t8b                   \t.byte 0x8b\n  3c:\t84 24 10             \ttest   %ah,(%rax,%rdx,1)\n  3f:\tf3                   \trepz\r\n\r\nCode starting with the faulting instruction\n===========================================\n   0:\t83 38 03             \tcmpl   $0x3,(%rax)\n   3:\t0f 84 37 fe ff ff    \tje     0xfffffffffffffe40\n   9:\tbb ea ff ff ff       \tmov    $0xffffffea,%ebx\n   e:\teb cc                \tjmp    0xffffffffffffffdc\n  10:\t49                   \trex.WB\n  11:\t8b                   \t.byte 0x8b\n  12:\t84 24 10             \ttest   %ah,(%rax,%rdx,1)\n  15:\tf3                   \trepz\n[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246\n[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8\n[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685\n[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873\n[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70\n[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000\n[ 9890.526313] FS:  0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000\n[ 9890.526316] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0\n[ 9890.526321] Call Trace:\n[ 9890.526324]  \u0026lt;TASK\u0026gt;\n[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)\n[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)\n[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)\n[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator\n---truncated---(CVE-2024-43911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: fix xfrm real_dev null pointer dereference\r\n\r\nWe shouldn\u0026apos;t set real_dev to NULL because packets can be in transit and\nxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume\nreal_dev is set.\r\n\r\n Example trace:\n kernel: BUG: unable to handle page fault for address: 0000000000001030\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: #PF: supervisor write access in kernel mode\n kernel: #PF: error_code(0x0002) - not-present page\n kernel: PGD 0 P4D 0\n kernel: Oops: 0002 [#1] PREEMPT SMP\n kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12\n kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 \u0026lt;83\u0026gt; 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:\n kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60\n kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00\n kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014\n kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000\n kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000\n kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000\n kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel: Call Trace:\n kernel:  \u0026lt;TASK\u0026gt;\n kernel:  ? __die+0x1f/0x60\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:  ? page_fault_oops+0x142/0x4c0\n kernel:  ? do_user_addr_fault+0x65/0x670\n kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel:  ? exc_page_fault+0x7b/0x180\n kernel:  ? asm_exc_page_fault+0x22/0x30\n kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim]\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]\n kernel: bond0: (slave eni0np1): making interface the new active one\n kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding]\n kernel:  xfrm_output+0x61/0x3b0\n kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA\n kernel:  ip_push_pending_frames+0x56/0x80(CVE-2024-44989)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nigb: cope with large MAX_SKB_FRAGS\r\n\r\nSabrina reports that the igb driver does not cope well with large\nMAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload\ncorruption on TX.\r\n\r\nAn easy reproducer is to run ssh to connect to the machine.  With\nMAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails.  This has\nbeen reported originally in\nhttps://bugzilla.redhat.com/show_bug.cgi?id=2265320\r\n\r\nThe root cause of the issue is that the driver does not take into\naccount properly the (possibly large) shared info size when selecting\nthe ring layout, and will try to fit two packets inside the same 4K\npage even when the 1st fraglist will trump over the 2nd head.\r\n\r\nAddress the issue by checking if 2K buffers are insufficient.(CVE-2024-45030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: change ipsec_lock from spin lock to mutex\r\n\r\nIn the cited commit, bond-\u0026gt;ipsec_lock is added to protect ipsec_list,\nhence xdo_dev_state_add and xdo_dev_state_delete are called inside\nthis lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,\n\u0026quot;scheduling while atomic\u0026quot; will be triggered when changing bond\u0026apos;s\nactive slave.\r\n\r\n[  101.055189] BUG: scheduling while atomic: bash/902/0x00000200\n[  101.055726] Modules linked in:\n[  101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1\n[  101.058760] Hardware name:\n[  101.059434] Call Trace:\n[  101.059436]  \u0026lt;TASK\u0026gt;\n[  101.060873]  dump_stack_lvl+0x51/0x60\n[  101.061275]  __schedule_bug+0x4e/0x60\n[  101.061682]  __schedule+0x612/0x7c0\n[  101.062078]  ? __mod_timer+0x25c/0x370\n[  101.062486]  schedule+0x25/0xd0\n[  101.062845]  schedule_timeout+0x77/0xf0\n[  101.063265]  ? asm_common_interrupt+0x22/0x40\n[  101.063724]  ? __bpf_trace_itimer_state+0x10/0x10\n[  101.064215]  __wait_for_common+0x87/0x190\n[  101.064648]  ? usleep_range_state+0x90/0x90\n[  101.065091]  cmd_exec+0x437/0xb20 [mlx5_core]\n[  101.065569]  mlx5_cmd_do+0x1e/0x40 [mlx5_core]\n[  101.066051]  mlx5_cmd_exec+0x18/0x30 [mlx5_core]\n[  101.066552]  mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]\n[  101.067163]  ? bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[  101.067738]  ? kmalloc_trace+0x4d/0x350\n[  101.068156]  mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]\n[  101.068747]  mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]\n[  101.069312]  bond_change_active_slave+0x392/0x900 [bonding]\n[  101.069868]  bond_option_active_slave_set+0x1c2/0x240 [bonding]\n[  101.070454]  __bond_opt_set+0xa6/0x430 [bonding]\n[  101.070935]  __bond_opt_set_notify+0x2f/0x90 [bonding]\n[  101.071453]  bond_opt_tryset_rtnl+0x72/0xb0 [bonding]\n[  101.071965]  bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[  101.072567]  kernfs_fop_write_iter+0x10c/0x1a0\n[  101.073033]  vfs_write+0x2d8/0x400\n[  101.073416]  ? alloc_fd+0x48/0x180\n[  101.073798]  ksys_write+0x5f/0xe0\n[  101.074175]  do_syscall_64+0x52/0x110\n[  101.074576]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\r\n\r\nAs bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called\nfrom bond_change_active_slave, which requires holding the RTNL lock.\nAnd bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state\nxdo_dev_state_add and xdo_dev_state_delete APIs, which are in user\ncontext. So ipsec_lock doesn\u0026apos;t have to be spin lock, change it to\nmutex, and thus the above issue can be resolved.(CVE-2024-46678)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfou: Fix null-ptr-deref in GRO.\r\n\r\nWe observed a null-ptr-deref in fou_gro_receive() while shutting down\na host.  [0]\r\n\r\nThe NULL pointer is sk-\u0026gt;sk_user_data, and the offset 8 is of protocol\nin struct fou.\r\n\r\nWhen fou_release() is called due to netns dismantle or explicit tunnel\nteardown, udp_tunnel_sock_release() sets NULL to sk-\u0026gt;sk_user_data.\nThen, the tunnel socket is destroyed after a single RCU grace period.\r\n\r\nSo, in-flight udp4_gro_receive() could find the socket and execute the\nFOU GRO handler, where sk-\u0026gt;sk_user_data could be NULL.\r\n\r\nLet\u0026apos;s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL\nchecks in FOU GRO handlers.\r\n\r\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0\nSMP PTI\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1\nHardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017\nRIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]\nCode: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 \u0026lt;0f\u0026gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42\nRSP: 0018:ffffa330c0003d08 EFLAGS: 00010297\nRAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010\nRDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08\nRBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002\nR10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400\nR13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0\nFS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? no_context (arch/x86/mm/fault.c:752)\n ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)\n ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)\n ? fou_gro_receive (net/ipv4/fou.c:233) [fou]\n udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)\n udp4_gro_receive (net/ipv4/udp_offload.c:604)\n inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))\n dev_gro_receive (net/core/dev.c:6035 (discriminator 4))\n napi_gro_receive (net/core/dev.c:6170)\n ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]\n ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]\n napi_poll (net/core/dev.c:6847)\n net_rx_action (net/core/dev.c:6917)\n __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)\n asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\n\u0026lt;/IRQ\u0026gt;\n do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)\n irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)\n common_interrupt (arch/x86/kernel/irq.c:239)\n asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)\nRIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)\nCode: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00\nRSP: 0018:ffffffffb5603e58 EFLAGS: 00000246\nRAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900\nRDX: ffff93daee800000 RSI: ffff93d\n---truncated---(CVE-2024-46763)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp_bpf: fix return value of tcp_bpf_sendmsg()\r\n\r\nWhen we cork messages in psock-\u0026gt;cork, the last message triggers the\nflushing will result in sending a sk_msg larger than the current\nmessage size. In this case, in tcp_bpf_send_verdict(), \u0026apos;copied\u0026apos; becomes\nnegative at least in the following case:\r\n\r\n468         case __SK_DROP:\n469         default:\n470                 sk_msg_free_partial(sk, msg, tosend);\n471                 sk_msg_apply_bytes(psock, tosend);\n472                 *copied -= (tosend + delta); // \u0026lt;==== HERE\n473                 return -EACCES;\r\n\r\nTherefore, it could lead to the following BUG with a proper value of\n\u0026apos;copied\u0026apos; (thanks to syzbot). We should not use negative \u0026apos;copied\u0026apos; as a\nreturn value here.\r\n\r\n  ------------[ cut here ]------------\n  kernel BUG at net/socket.c:733!\n  Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0\n  Hardware name: linux,dummy-virt (DT)\n  pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n  pc : sock_sendmsg_nosec net/socket.c:733 [inline]\n  pc : sock_sendmsg_nosec net/socket.c:728 [inline]\n  pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745\n  lr : sock_sendmsg_nosec net/socket.c:730 [inline]\n  lr : __sock_sendmsg+0x54/0x60 net/socket.c:745\n  sp : ffff800088ea3b30\n  x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000\n  x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000\n  x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90\n  x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001\n  x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf\n  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0\n  x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000\n  x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900\n  x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef\n  Call trace:\n   sock_sendmsg_nosec net/socket.c:733 [inline]\n   __sock_sendmsg+0x5c/0x60 net/socket.c:745\n   ____sys_sendmsg+0x274/0x2ac net/socket.c:2597\n   ___sys_sendmsg+0xac/0x100 net/socket.c:2651\n   __sys_sendmsg+0x84/0xe0 net/socket.c:2680\n   __do_sys_sendmsg net/socket.c:2689 [inline]\n   __se_sys_sendmsg net/socket.c:2687 [inline]\n   __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49\n   el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712\n   el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730\n   el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598\n  Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)\n  ---[ end trace 0000000000000000 ]---(CVE-2024-46783)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix smatch static checker warning\r\n\r\nadev-\u0026gt;gfx.imu.funcs could be NULL(CVE-2024-46835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: pm80xx: Set phy-\u0026gt;enable_completion only when we wait for it\r\n\r\npm8001_phy_control() populates the enable_completion pointer with a stack\naddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and\nreturns. The problem arises when a phy control response comes late.  After\n300 ms the pm8001_phy_control() function returns and the passed\nenable_completion stack address is no longer valid. Late phy control\nresponse invokes complete() on a dangling enable_completion pointer which\nleads to a kernel crash.(CVE-2024-47666)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm: avoid leaving partial pfn mappings around in error case  As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a \u0026apos;struct page\u0026apos;.  That\u0026apos;s all very much intentional, but it does mean that it\u0026apos;s easy to mess up the cleanup in case of errors.  Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it\u0026apos;s very easy to do the error handling in the wrong order.  In particular, it\u0026apos;s easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries.  To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.(CVE-2024-47674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix out-of-bounds in dbNextAG() and diAlloc()  In dbNextAG() , there is no check for the case where bmp-\u0026gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount().  And in dbNextAG(), a check for the case where agpref is greater than bmp-\u0026gt;db_numag should be added, so an out-of-bounds exception should be prevented.  Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error  For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here.  Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we\u0026apos;re readding the issue we\u0026apos;re trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/ncsi: Disable the ncsi work before freeing the associated structure  The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c  Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format().  Fix the following smatch errors:  drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: \u0026apos;fmtdesc\u0026apos; dereferencing possible ERR_PTR()  drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: \u0026apos;fmtdesc\u0026apos; dereferencing possible ERR_PTR()  Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().(CVE-2024-50056)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition  In the cdns_i3c_master_probe function, \u0026amp;master-\u0026gt;hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work.  If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master-\u0026gt;base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                      CPU1                                       | cdns_i3c_master_hj cdns_i3c_master_remove               | i3c_master_unregister(\u0026amp;master-\u0026gt;base) | device_unregister(\u0026amp;master-\u0026gt;dev)      | device_release                       | //free master-\u0026gt;base                  |                                      | i3c_master_do_daa(\u0026amp;master-\u0026gt;base)                                      | //use master-\u0026gt;base  Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.(CVE-2024-50061)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  unicode: Don\u0026apos;t special case ignorable code points  We don\u0026apos;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  arm64: probes: Remove broken LDR (literal) uprobe support  The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory.  There are three key problems:  1) The plain C accesses do not have corresponding extable entries, and    thus if they encounter a fault the kernel will treat these as    unintentional accesses to user memory, resulting in a BUG() which    will kill the kernel thread, and likely lead to further issues (e.g.    lockup or panic()).  2) The plain C accesses are subject to HW PAN and SW PAN, and so when    either is in use, any attempt to simulate an access to user memory    will fault. Thus neither simulate_ldr_literal() nor    simulate_ldrsw_literal() can do anything useful when simulating a    user instruction on any system with HW PAN or SW PAN.  3) The plain C accesses are privileged, as they run in kernel context,    and in practice can access a small range of kernel virtual addresses.    The instructions they simulate have a range of +/-1MiB, and since the    simulated instructions must itself be a user instructions in the    TTBR0 address range, these can address the final 1MiB of the TTBR1    acddress range by wrapping downwards from an address in the first    1MiB of the TTBR0 address range.     In contemporary kernels the last 8MiB of TTBR1 address range is    reserved, and accesses to this will always fault, meaning this is no    worse than (1).     Historically, it was theoretically possible for the linear map or    vmemmap to spill into the final 8MiB of the TTBR1 address range, but    in practice this is extremely unlikely to occur as this would    require either:     * Having enough physical memory to fill the entire linear map all the      way to the final 1MiB of the TTBR1 address range.     * Getting unlucky with KASLR randomization of the linear map such      that the populated region happens to overlap with the last 1MiB of      the TTBR address range.     ... and in either case if we were to spill into the final page there    would be larger problems as the final page would alias with error    pointers.  Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes.  Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory  Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn\u0026apos;t enforce 32-byte alignment of nCR3.  In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn\u0026apos;t using guard pages.  Per the APM:    The CR3 register points to the base address of the page-directory-pointer   table. The page-directory-pointer table is aligned on a 32-byte boundary,   with the low 5 address bits 4:0 assumed to be 0.  And the SDM\u0026apos;s much more explicit:    4:0    Ignored  Note, KVM gets this right when loading PDPTRs, it\u0026apos;s only the nSVM flow that is broken.(CVE-2024-50115)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: Fix UAF on iso_sock_timeout  conn-\u0026gt;sk maybe have been unlinked/freed while waiting for iso_conn_lock so this checks if the conn-\u0026gt;sk is still valid by checking if it part of iso_sk_list.(CVE-2024-50124)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Use raw_spinlock_t in ringbuf  The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a \u0026quot;sleep in atomic\u0026quot; warning in the RT variant. This issue is illustrated in the example below:  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [\u0026lt;ffffd33a5c88ea44\u0026gt;] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace:  dump_backtrace+0xac/0x130  show_stack+0x1c/0x30  dump_stack_lvl+0xac/0xe8  dump_stack+0x18/0x30  __might_resched+0x3bc/0x4fc  rt_spin_lock+0x8c/0x1a4  __bpf_ringbuf_reserve+0xc4/0x254  bpf_ringbuf_reserve_dynptr+0x5c/0xdc  bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238  trace_call_bpf+0x238/0x774  perf_call_bpf_enter.isra.0+0x104/0x194  perf_syscall_enter+0x2f8/0x510  trace_sys_enter+0x39c/0x564  syscall_trace_enter+0x220/0x3c0  do_el0_svc+0x138/0x1dc  el0_svc+0x54/0x130  el0t_64_sync_handler+0x134/0x150  el0t_64_sync+0x17c/0x180  Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)\r\n\r\n(CVE-2024-50151)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: target: core: Fix null-ptr-deref in target_alloc_device()  There is a null-ptr-deref issue reported by KASAN:  BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ...  kasan_report+0xb9/0xf0  target_alloc_device+0xbc4/0xbe0 [target_core_mod]  core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]  target_core_init_configfs+0x205/0x420 [target_core_mod]  do_one_initcall+0xdd/0x4e0 ...  entry_SYSCALL_64_after_hwframe+0x76/0x7e  In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev-\u0026gt;transport-\u0026gt;free_device(), but dev-\u0026gt;transport is not initialized at that time, which will lead to a null pointer reference problem.  Fixing this bug by freeing dev with hba-\u0026gt;backend-\u0026gt;ops-\u0026gt;free_device().(CVE-2024-50153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: sisfb: Fix strbuf array overflow  The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \u0026quot;%ux%ux8\u0026quot;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/entry_32: Clear CPU buffers after register restore in NMI return  CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don\u0026apos;t have any sensitive data.  Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.(CVE-2024-50193)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: light: veml6030: fix IIO device retrieval from embedded device  The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client.  dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment.  This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: propagate directory read errors from nilfs_find_entry()  Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2.  The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails.  If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts.  Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry().  The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nvmet-auth: assign dh_key to NULL after kfree_sensitive  ctrl-\u0026gt;dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it\u0026apos;s better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth().  Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-50215)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower  Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix general protection fault in run_is_mapped_full  Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.(CVE-2024-50243)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Additional check in ni_clear()  Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix possible deadlock in mi_read  Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Check if more than chunk-size bytes are written  A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fsdax: dax_unshare_iter needs to copy entire blocks  The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster\u0026apos;s recent fsx changes have exposed.  If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment.  dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page.  This is catastrophic for data integrity when iter-\u0026gt;pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter-\u0026gt;pos.  Hence we corrupt user data by copying it to the wrong place.  If iter-\u0026gt;pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block.  This is catastrophic for data confidentiality because we expose stale pmem contents.  Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks.  We\u0026apos;re not done yet -- there\u0026apos;s no call to invalidate_inode_pages2_range, so programs that have the file range mmap\u0026apos;d will continue accessing the old memory mapping after the file metadata updates have completed.  Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we\u0026apos;re operating on.(CVE-2024-50250)",
  "id": "OESA-2024-2446",
  "modified": "2026-08-06T11:07:55Z",
  "published": "2024-11-22T11:07:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2446"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36011"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43911"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44989"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45030"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46678"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46783"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47666"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47728"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49945"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50056"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50061"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50099"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50115"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50124"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50138"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50151"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50193"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50202"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50215"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50237"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50242"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50243"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50244"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50245"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50246"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50247"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50250"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-26944",
    "CVE-2024-36011",
    "CVE-2024-43835",
    "CVE-2024-43911",
    "CVE-2024-44989",
    "CVE-2024-45030",
    "CVE-2024-46678",
    "CVE-2024-46763",
    "CVE-2024-46783",
    "CVE-2024-46835",
    "CVE-2024-47666",
    "CVE-2024-47674",
    "CVE-2024-47723",
    "CVE-2024-47728",
    "CVE-2024-49945",
    "CVE-2024-50056",
    "CVE-2024-50061",
    "CVE-2024-50089",
    "CVE-2024-50099",
    "CVE-2024-50115",
    "CVE-2024-50124",
    "CVE-2024-50138",
    "CVE-2024-50151",
    "CVE-2024-50153",
    "CVE-2024-50180",
    "CVE-2024-50193",
    "CVE-2024-50198",
    "CVE-2024-50202",
    "CVE-2024-50215",
    "CVE-2024-50237",
    "CVE-2024-50242",
    "CVE-2024-50243",
    "CVE-2024-50244",
    "CVE-2024-50245",
    "CVE-2024-50246",
    "CVE-2024-50247",
    "CVE-2024-50250"
  ]
}

OESA-2025-2885 (CVE-2022-49121)

Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free().(CVE-2022-49121)

In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fc_remote_port_delete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel: <IRQ>kernel: dump_stack+0x66/0x81kernel: __schedule_bug.cold.90+0x5/0x1dkernel: __schedule+0x7af/0x960kernel: schedule+0x28/0x80kernel: schedule_timeout+0x26d/0x3b0kernel: wait_for_completion+0xb4/0x140kernel: ? wake_up_q+0x70/0x70kernel: __wait_rcu_gp+0x12c/0x160kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]kernel: synchronize_sched+0x6c/0x80kernel: ? call_rcu_bh+0x20/0x20kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod]kernel: starget_for_each_device+0x85/0xb0 [scsi_mod]kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod]kernel: scsi_init_io+0x388/0x3d0 [scsi_mod]kernel: device_for_each_child+0x54/0x90kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx]kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]kernel: __handle_irq_event_percpu+0x40/0x180kernel: handle_irq_event_percpu+0x30/0x80kernel: handle_irq_event+0x36/0x60(CVE-2022-49156)

In the Linux kernel, the following vulnerability has been resolved:

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.

Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)

In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on inline_dots inodeAs Wenqing reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=215765It will cause a kernel panic with steps:- mkdir mnt- mount tmp40.img mnt- ls mntfolio_mark_dirty+0x33/0x50f2fs_add_regular_entry+0x541/0xad0 [f2fs]f2fs_add_dentry+0x6c/0xb0 [f2fs]f2fs_do_add_link+0x182/0x230 [f2fs]__recover_dot_dentries+0x2d6/0x470 [f2fs]f2fs_lookup+0x5af/0x6a0 [f2fs]__lookup_slow+0xac/0x200lookup_slow+0x45/0x70walk_component+0x16c/0x250path_lookupat+0x8b/0x1f0filename_lookup+0xef/0x250user_path_at_empty+0x46/0x70vfs_statx+0x98/0x190__do_sys_newlstat+0x41/0x90__x64_sys_newlstat+0x1a/0x30do_syscall_64+0x37/0xb0entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root cause is for special file: e.g. character, block, fifo orsocket file, f2fs doesn t assign address space operations pointer arrayfor mapping->a_ops field, so, in a fuzzed image, if inline_dots flag wastagged in special file, during lookup(), when f2fs runs into__recover_dot_dentries(), it will cause NULL pointer access oncef2fs_add_regular_entry() calls a_ops->set_dirty_page().(CVE-2022-49428)

In the Linux kernel, the following vulnerability has been resolved:arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscallIf a compat process tries to execute an unknown system call above the__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to theoffending process. Information about the error is printed to dmesg incompat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->arm64_show_signal().arm64_show_signal() interprets a non-zero value forcurrent->thread.fault_code as an exception syndrome and displays themessage associated with the ESR_ELx.EC field (bits 31:26).current->thread.fault_code is set in compat_arm_syscall() ->arm64_notify_die() with the bad syscall number instead of a valid ESR_ELxvalue. This means that the ESR_ELx.EC field has the value that the user setfor the syscall number and the kernel can end up printing bogus exceptionmessages*. For example, for the syscall number 0x68000000, which evaluatesto ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:[ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000][ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79[ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which is misleading, as the bad compat syscall has nothing to do withpointer authentication.Stop arm64_show_signal() from printing exception syndrome information byhaving compat_arm_syscall() set the ESR_ELx value to 0, as it has nomeaning for an invalid system call number. The example above now becomes:[ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000][ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80[ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which although shows less information because the syscall number,wrongfully advertised as the ESR value, is missing, it is better thanshowing plainly wrong information. The syscall number can be easilyobtained with strace.*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negativeinteger in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_ENDevaluates to true; the syscall will exit to userspace in this case with theENOSYS error code instead of arm64_notify_die() being called.(CVE-2022-49520)

In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_probe_threshold.While reading sysctl_tcp_probe_threshold, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.(CVE-2022-49595)

In the Linux kernel, the following vulnerability has been resolved:

mmc: core: Fix kernel panic when remove non-standard SDIO card

SDIO tuple is only allocated for standard SDIO card, especially it causes memory corruption issues when the non-standard SDIO card has removed, which is because the card device's reference counter does not increase for it at sdio_init_func(), but all SDIO card device reference counter gets decreased at sdio_release_func().(CVE-2022-50640)

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Perform lockless command completion in abort path

While adding and removing the controller, the following call trace was observed:

WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1 RIP: 0010:dma_free_attrs+0x33/0x50

Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xae

The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held.(CVE-2023-53041)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: install stub fence into potential unused fence pointers

When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.(CVE-2023-53248)

In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835)

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid overflow assignment in link_dp_ctssampling_rate is an uint8_t but is assigned an unsigned int, and thus itcan overflow. As a result, sampling_rate is changed to uint32_t.Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it shouldonly be assigned to a value less or equal than 4.This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)

In the Linux kernel, the following vulnerability has been resolved:wifi: iwlegacy: Clear stale interrupts before resuming deviceiwl4965 fails upon resume from hibernation on my laptop. The reasonseems to be a stale interrupt which isn t being cleared out beforeinterrupts are enabled. We end up with a race beween the resumetrying to bring things back up, and the restart work (queued formthe interrupt handler) trying to bring things down. Eventuallythe whole thing blows up.Fix the problem by clearing out any stale interrupts beforeinterrupts get enabled during resume.Here s a debug log of the indicent:[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000[ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000[ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.[ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload[ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282[ 12.052207] ieee80211 phy0: il4965_mac_start enter[ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff[ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready[ 12.052324] ieee80211 phy0: il_apm_init Init card s basic functions[ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S[ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm[ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm[ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK[ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations[ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up[ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.[ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down[ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout[ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort[ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver[ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared[ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state[ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master[ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.[ 12.058869] ieee80211 phy0: Hardware restart was requested[ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.[ 16.132303] ------------[ cut here ]------------[ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.[ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev[ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143[ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010[ 16.132463] Workqueue: async async_run_entry_fn[ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211][ 16.132501] Code: da 02 00 0---truncated---(CVE-2024-50234)

In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)

In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.(CVE-2025-21776)

In the Linux kernel, the following vulnerability has been resolved:

pinctrl: qcom: msm: mark certain pins as invalid for interrupts

On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: gpiomon -c 0 113 on RB2.

The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs.

This function can be extended if we determine that there are more corner-cases like this.(CVE-2025-38516)

Severity

7.1 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49121	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49156	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49289	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49428	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49520	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49595	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-50640	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-53041	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-53248	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43835	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50016	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50234	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21744	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21776	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38516	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2512.4.0.0356.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2512.4.0.0356.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2512.4.0.0356.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:scsi: pm8001: Fix tag leaks on errorIn pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(),pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing callsto pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd()fails.Similarly, in pm8001_exec_internal_task_abort(), if the chip -\u0026gt;task_abortmethod fails, the tag allocated for the abort request task must befreed. Add the missing call to pm8001_tag_free().(CVE-2022-49121)\n\nIn the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix scheduling while atomicThe driver makes a call into midlayer (fc_remote_port_delete) which can putthe thread to sleep. The thread that originates the call is in interruptcontext. The combination of the two trigger a crash. Schedule the call innon-interrupt context where it is more safe.kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000kernel: Call Trace:kernel:  \u0026lt;IRQ\u0026gt;kernel:  dump_stack+0x66/0x81kernel:  __schedule_bug.cold.90+0x5/0x1dkernel:  __schedule+0x7af/0x960kernel:  schedule+0x28/0x80kernel:  schedule_timeout+0x26d/0x3b0kernel:  wait_for_completion+0xb4/0x140kernel:  ? wake_up_q+0x70/0x70kernel:  __wait_rcu_gp+0x12c/0x160kernel:  ? sdev_evt_alloc+0xc0/0x180 [scsi_mod]kernel:  synchronize_sched+0x6c/0x80kernel:  ? call_rcu_bh+0x20/0x20kernel:  ? __bpf_trace_rcu_invoke_callback+0x10/0x10kernel:  sdev_evt_alloc+0xfd/0x180 [scsi_mod]kernel:  starget_for_each_device+0x85/0xb0 [scsi_mod]kernel:  ? scsi_init_io+0x360/0x3d0 [scsi_mod]kernel:  scsi_init_io+0x388/0x3d0 [scsi_mod]kernel:  device_for_each_child+0x54/0x90kernel:  fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc]kernel:  qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx]kernel:  qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx]kernel:  qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx]kernel:  qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx]kernel:  qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx]kernel:  qla24xx_process_response_queue+0x306/0x400 [qla2xxx]kernel:  qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx]kernel:  __handle_irq_event_percpu+0x40/0x180kernel:  handle_irq_event_percpu+0x30/0x80kernel:  handle_irq_event+0x36/0x60(CVE-2022-49156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuaccess: fix integer overflow on access_ok()\n\nThree architectures check the end of a user access against the\naddress limit without taking a possible overflow into account.\nPassing a negative length or another overflow in here returns\nsuccess when it should not.\n\nUse the most common correct implementation here, which optimizes\nfor a constant \u0026apos;size\u0026apos; argument, and turns the common case into a\nsingle comparison.(CVE-2022-49289)\n\nIn the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on inline_dots inodeAs Wenqing reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=215765It will cause a kernel panic with steps:- mkdir mnt- mount tmp40.img mnt- ls mntfolio_mark_dirty+0x33/0x50f2fs_add_regular_entry+0x541/0xad0 [f2fs]f2fs_add_dentry+0x6c/0xb0 [f2fs]f2fs_do_add_link+0x182/0x230 [f2fs]__recover_dot_dentries+0x2d6/0x470 [f2fs]f2fs_lookup+0x5af/0x6a0 [f2fs]__lookup_slow+0xac/0x200lookup_slow+0x45/0x70walk_component+0x16c/0x250path_lookupat+0x8b/0x1f0filename_lookup+0xef/0x250user_path_at_empty+0x46/0x70vfs_statx+0x98/0x190__do_sys_newlstat+0x41/0x90__x64_sys_newlstat+0x1a/0x30do_syscall_64+0x37/0xb0entry_SYSCALL_64_after_hwframe+0x44/0xaeThe root cause is for special file: e.g. character, block, fifo orsocket file, f2fs doesn t assign address space operations pointer arrayfor mapping-\u0026gt;a_ops field, so, in a fuzzed image, if inline_dots flag wastagged in special file, during lookup(), when f2fs runs into__recover_dot_dentries(), it will cause NULL pointer access oncef2fs_add_regular_entry() calls a_ops-\u0026gt;set_dirty_page().(CVE-2022-49428)\n\nIn the Linux kernel, the following vulnerability has been resolved:arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscallIf a compat process tries to execute an unknown system call above the__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to theoffending process. Information about the error is printed to dmesg incompat_arm_syscall() -\u0026gt; arm64_notify_die() -\u0026gt; arm64_force_sig_fault() -\u0026gt;arm64_show_signal().arm64_show_signal() interprets a non-zero value forcurrent-\u0026gt;thread.fault_code as an exception syndrome and displays themessage associated with the ESR_ELx.EC field (bits 31:26).current-\u0026gt;thread.fault_code is set in compat_arm_syscall() -\u0026gt;arm64_notify_die() with the bad syscall number instead of a valid ESR_ELxvalue. This means that the ESR_ELx.EC field has the value that the user setfor the syscall number and the kernel can end up printing bogus exceptionmessages*. For example, for the syscall number 0x68000000, which evaluatesto ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:[   18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000][   18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79[   18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which is misleading, as the bad compat syscall has nothing to do withpointer authentication.Stop arm64_show_signal() from printing exception syndrome information byhaving compat_arm_syscall() set the ESR_ELx value to 0, as it has nomeaning for an invalid system call number. The example above now becomes:[   19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000][   19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80[   19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)[..]which although shows less information because the syscall number,wrongfully advertised as the ESR value, is missing, it is better thanshowing plainly wrong information. The syscall number can be easilyobtained with strace.*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negativeinteger in compat_arm_syscal() and the condition scno \u0026lt; __ARM_NR_COMPAT_ENDevaluates to true; the syscall will exit to userspace in this case with theENOSYS error code instead of arm64_notify_die() being called.(CVE-2022-49520)\n\nIn the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_probe_threshold.While reading sysctl_tcp_probe_threshold, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.(CVE-2022-49595)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: core: Fix kernel panic when remove non-standard SDIO card\n\nSDIO tuple is only allocated for standard SDIO card, especially it causes\nmemory corruption issues when the non-standard SDIO card has removed, which\nis because the card device\u0026apos;s reference counter does not increase for it at\nsdio_init_func(), but all SDIO card device reference counter gets decreased\nat sdio_release_func().(CVE-2022-50640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Perform lockless command completion in abort path\n\nWhile adding and removing the controller, the following call trace was\nobserved:\n\nWARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50\nCPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1\nRIP: 0010:dma_free_attrs+0x33/0x50\n\nCall Trace:\n   qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx]\n   qla2x00_abort_srb+0x8e/0x250 [qla2xxx]\n   ? ql_dbg+0x70/0x100 [qla2xxx]\n   __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx]\n   qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx]\n   qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx]\n   qla2x00_remove_one+0x364/0x400 [qla2xxx]\n   pci_device_remove+0x36/0xa0\n   __device_release_driver+0x17a/0x230\n   device_release_driver+0x24/0x30\n   pci_stop_bus_device+0x68/0x90\n   pci_stop_and_remove_bus_device_locked+0x16/0x30\n   remove_store+0x75/0x90\n   kernfs_fop_write_iter+0x11c/0x1b0\n   new_sync_write+0x11f/0x1b0\n   vfs_write+0x1eb/0x280\n   ksys_write+0x5f/0xe0\n   do_syscall_64+0x5c/0x80\n   ? do_user_addr_fault+0x1d8/0x680\n   ? do_syscall_64+0x69/0x80\n   ? exc_page_fault+0x62/0x140\n   ? asm_exc_page_fault+0x8/0x30\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe command was completed in the abort path during driver unload with a\nlock held, causing the warning in abort path. Hence complete the command\nwithout any lock held.(CVE-2023-53041)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: install stub fence into potential unused fence pointers\n\nWhen using cpu to update page tables, vm update fences are unused.\nInstall stub fence into these fence pointers instead of NULL\nto avoid NULL dereference when calling dma_fence_wait() on them.(CVE-2023-53248)\n\nIn the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear:  WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0   __warn+0x12f/0x340   napi_skb_cache_put+0x82/0x4b0   napi_skb_cache_put+0x82/0x4b0   report_bug+0x165/0x370   handle_bug+0x3d/0x80   exc_invalid_op+0x1a/0x50   asm_exc_invalid_op+0x1a/0x20   __free_old_xmit+0x1c8/0x510   napi_skb_cache_put+0x82/0x4b0   __free_old_xmit+0x1c8/0x510   __free_old_xmit+0x1c8/0x510   __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid overflow assignment in link_dp_ctssampling_rate is an uint8_t but is assigned an unsigned int, and thus itcan overflow. As a result, sampling_rate is changed to uint32_t.Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it shouldonly be assigned to a value less or equal than 4.This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: iwlegacy: Clear stale interrupts before resuming deviceiwl4965 fails upon resume from hibernation on my laptop. The reasonseems to be a stale interrupt which isn t being cleared out beforeinterrupts are enabled. We end up with a race beween the resumetrying to bring things back up, and the restart work (queued formthe interrupt handler) trying to bring things down. Eventuallythe whole thing blows up.Fix the problem by clearing out any stale interrupts beforeinterrupts get enabled during resume.Here s a debug log of the indicent:[   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000[   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000[   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.[   12.042653] iwl4965 0000:10:00.0: On demand firmware reload[   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282[   12.052207] ieee80211 phy0: il4965_mac_start enter[   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff[   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready[   12.052324] ieee80211 phy0: il_apm_init Init card s basic functions[   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S[   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm[   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm[   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK[   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations[   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up[   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.[   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down[   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout[   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort[   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver[   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared[   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state[   12.058827] ieee80211 phy0: _il_apm_stop_master stop master[   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.[   12.058869] ieee80211 phy0: Hardware restart was requested[   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.[   16.132303] ------------[ cut here ]------------[   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.[   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211][   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev[   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143[   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010[   16.132463] Workqueue: async async_run_entry_fn[   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211][   16.132501] Code: da 02 00 0---truncated---(CVE-2024-50234)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface:  brcmf_detach()    brcmf_remove_interface()      brcmf_del_if()Inside the brcmf_del_if() function the drvr-\u0026gt;if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence:  brcmf_detach()    brcmf_proto_detach()      brcmf_proto_msgbuf_detach()        brcmf_flowring_detach()          brcmf_msgbuf_delete_flowring()            brcmf_msgbuf_remove_flowring()              brcmf_flowring_delete()                brcmf_get_ifp()                brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp-\u0026gt;ndev-\u0026gt;stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)\n\nIn the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: \u0026lt;TASK\u0026gt; ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.(CVE-2025-21776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: qcom: msm: mark certain pins as invalid for interrupts\n\nOn some platforms, the UFS-reset pin has no interrupt logic in TLMM but\nis nevertheless registered as a GPIO in the kernel. This enables the\nuser-space to trigger a BUG() in the pinctrl-msm driver by running, for\nexample: `gpiomon -c 0 113` on RB2.\n\nThe exact culprit is requesting pins whose intr_detection_width setting\nis not 1 or 2 for interrupts. This hits a BUG() in\nmsm_gpio_irq_set_type(). Potentially crashing the kernel due to an\ninvalid request from user-space is not optimal, so let\u0026apos;s go through the\npins and mark those that would fail the check as invalid for the irq chip\nas we should not even register them as available irqs.\n\nThis function can be extended if we determine that there are more\ncorner-cases like this.(CVE-2025-38516)",
  "id": "OESA-2025-2885",
  "modified": "2026-08-06T11:10:01Z",
  "published": "2025-12-30T11:10:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2885"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49121"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49156"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49289"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49428"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49520"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49595"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50640"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53041"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50234"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21776"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38516"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-49121",
    "CVE-2022-49156",
    "CVE-2022-49289",
    "CVE-2022-49428",
    "CVE-2022-49520",
    "CVE-2022-49595",
    "CVE-2022-50640",
    "CVE-2023-53041",
    "CVE-2023-53248",
    "CVE-2024-43835",
    "CVE-2024-50016",
    "CVE-2024-50234",
    "CVE-2025-21744",
    "CVE-2025-21776",
    "CVE-2025-38516"
  ]
}

OESA-2025-2886 (CVE-2022-49426)

Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

iommu/arm-smmu-v3-sva: Fix mm use-after-free

We currently call arm64_mm_context_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit

Always purge mcu skb queues in mt7915_mcu_exit routine even if mt7915_firmware_state fails.(CVE-2023-53466)

printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.(CVE-2024-25741)

In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)</IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)

In the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)

In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)

In the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, directly code the required sequence in xen-asm.S.This is done in preparation of no longer using hypercall page at all,as it has shown to cause problems with speculation mitigations.This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)

In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi s weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)

In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix kmemleak warning for percpu hashmap

Vlad Poenaru reported the following kmemleak issue:

unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr;

Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.

In htab_map_alloc(), we already have

    htab-&gt;elem_size = sizeof(struct htab_elem) +
                      round_up(htab-&gt;map.key_size, 8);
    if (percpu)
            htab-&gt;elem_size += sizeof(void *);
    else
            htab-&gt;elem_size += round_up(htab-&gt;map.value_size, 8);

So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.

The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.(CVE-2025-37807)

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix Preauh_HashValue race condition

If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase.(CVE-2025-38561)

In the Linux kernel, the following vulnerability has been resolved:

padata: Fix pd UAF once and for all

There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.

This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.

In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.

Fix this by getting the next padata before the squeue->serial lock is released.

In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.(CVE-2025-38584)

In the Linux kernel, the following vulnerability has been resolved:

fs: Prevent file descriptor table allocations exceeding INT_MAX

When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:

WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288

This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN.

Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)

Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open

Run a program that uses a high file descriptor: #include <unistd.h> #include <sys/resource.h>

int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }

Observe WARNING in dmesg at mm/slub.c:5027

systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:

The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
The resulting allocations (>8GB) are impractical and will always fail

systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.

While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.

Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.(CVE-2025-39756)

In the Linux kernel, the following vulnerability has been resolved:

i40e: remove read access to debugfs files

The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").

Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.

On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.

We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.

A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.

Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.

In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)

In the Linux kernel, the following vulnerability has been resolved:

ACPI: video: Fix use-after-free in acpi_video_switch_brightness()

The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal.

If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight.

Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed.

rjw: Changelog edit

Severity

8.5 (High)


                    
                      CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49426	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-53466	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-25741	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43835	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46763	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47740	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53138	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53241	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21744	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21806	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-21820	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-37807	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38561	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38584	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39756	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39901	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40211	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-296.0.0.198.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-296.0.0.198.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-v3-sva: Fix mm use-after-free\n\nWe currently call arm64_mm_context_put() without holding a reference to\nthe mm, which can result in use-after-free. Call mmgrab()/mmdrop() to\nensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit\n\nAlways purge mcu skb queues in mt7915_mcu_exit routine even if\nmt7915_firmware_state fails.(CVE-2023-53466)\n\nprinter_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.(CVE-2024-25741)\n\nIn the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear:  WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0   __warn+0x12f/0x340   napi_skb_cache_put+0x82/0x4b0   napi_skb_cache_put+0x82/0x4b0   report_bug+0x165/0x370   handle_bug+0x3d/0x80   exc_invalid_op+0x1a/0x50   asm_exc_invalid_op+0x1a/0x20   __free_old_xmit+0x1c8/0x510   napi_skb_cache_put+0x82/0x4b0   __free_old_xmit+0x1c8/0x510   __free_old_xmit+0x1c8/0x510   __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835)\n\nIn the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host.  [0]The NULL pointer is sk-\u0026gt;sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk-\u0026gt;sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk-\u0026gt;sk_user_data could be NULL.Let s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 \u0026lt;0f\u0026gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: \u0026lt;IRQ\u0026gt; ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\u0026lt;/IRQ\u0026gt; do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)\n\nIn the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can   truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert   changes another process concurrently made to a fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)\n\nIn the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)\n\nIn the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, directly code the required sequence in xen-asm.S.This is done in preparation of no longer using hypercall page at all,as it has shown to cause problems with speculation mitigations.This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface:  brcmf_detach()    brcmf_remove_interface()      brcmf_del_if()Inside the brcmf_del_if() function the drvr-\u0026gt;if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence:  brcmf_detach()    brcmf_proto_detach()      brcmf_proto_msgbuf_detach()        brcmf_flowring_detach()          brcmf_msgbuf_delete_flowring()            brcmf_msgbuf_remove_flowring()              brcmf_flowring_delete()                brcmf_get_ifp()                brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp-\u0026gt;ndev-\u0026gt;stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530   returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48,   next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35   __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows:  sysctl -w net.core.dev_weight=0  ping 127.0.0.1This is because when the napi s weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0                      CPU 1========================== ============================cdns_uart_isr()            printk()  uart_port_lock(port)       console_lock()        cdns_uart_console_write()                               if (!port-\u0026gt;sysrq)                                 uart_port_lock(port)  uart_handle_break()    port-\u0026gt;sysrq = ...  uart_handle_sysrq_char()    printk()      console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port-\u0026gt;sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port-\u0026gt;sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n  unreferenced object 0x606fd7c44ac8 (size 32):\n    backtrace (crc 0):\n      pcpu_alloc_noprof+0x730/0xeb0\n      bpf_map_alloc_percpu+0x69/0xc0\n      prealloc_init+0x9d/0x1b0\n      htab_map_alloc+0x363/0x510\n      map_create+0x215/0x3a0\n      __sys_bpf+0x16b/0x3e0\n      __x64_sys_bpf+0x18/0x20\n      do_syscall_64+0x7b/0x150\n      entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n  *(void __percpu **)(l-\u0026gt;key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won\u0026apos;t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n        htab-\u0026gt;elem_size = sizeof(struct htab_elem) +\n                          round_up(htab-\u0026gt;map.key_size, 8);\n        if (percpu)\n                htab-\u0026gt;elem_size += sizeof(void *);\n        else\n                htab-\u0026gt;elem_size += round_up(htab-\u0026gt;map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0026apos;t cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n  1. Enable CONFIG_DEBUG_KMEMLEAK config\n  2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n     The purpose is to keep map available so kmemleak can be detected.\n  3. run \u0026apos;./test_progs -t for_each/hash_map \u0026amp;\u0026apos; and a kmemleak should be reported.(CVE-2025-37807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Preauh_HashValue race condition\n\nIf client send multiple session setup requests to ksmbd,\nPreauh_HashValue race condition could happen.\nThere is no need to free sess-\u0026gt;Preauh_HashValue at session setup phase.\nIt can be freed together with session at connection termination phase.(CVE-2025-38561)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit.  A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly.  If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u0026gt;serial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u0026gt;serial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.(CVE-2025-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: \u0026gt; 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n   # echo 1073741816 \u0026gt; /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n   #include \u0026lt;unistd.h\u0026gt;\n   #include \u0026lt;sys/resource.h\u0026gt;\n\n   int main() {\n       struct rlimit rlim = {1073741824, 1073741824};\n       setrlimit(RLIMIT_NOFILE, \u0026amp;rlim);\n       dup2(2, 1073741880);  // Triggers the warning\n       return 0;\n   }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel\u0026apos;s allocation functions still enforce INT_MAX as a maximum\n   size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n   inadvertently trigger massive allocations\n3. The resulting allocations (\u0026gt;8GB) are impractical and will always fail\n\nsystemd\u0026apos;s algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical \u0026gt;8GB memory allocation request.(CVE-2025-39756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: video: Fix use-after-free in acpi_video_switch_brightness()\n\nThe switch_brightness_work delayed work accesses device-\u0026gt;brightness\nand device-\u0026gt;backlight, freed by acpi_video_dev_unregister_backlight()\nduring device removal.\n\nIf the work executes after acpi_video_bus_unregister_backlight()\nfrees these resources, it causes a use-after-free when\nacpi_video_switch_brightness() dereferences device-\u0026gt;brightness or\ndevice-\u0026gt;backlight.\n\nFix this by calling cancel_delayed_work_sync() for each device\u0026apos;s\nswitch_brightness_work in acpi_video_bus_remove_notify_handler()\nafter removing the notify handler that queues the work. This ensures\nthe work completes before the memory is freed.\n\n[ rjw: Changelog edit ](CVE-2025-40211)",
  "id": "OESA-2025-2886",
  "modified": "2026-08-06T11:10:01Z",
  "published": "2025-12-30T11:10:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49426"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25741"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43835"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53138"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21744"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21806"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37807"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38561"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38584"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40211"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-49426",
    "CVE-2023-53466",
    "CVE-2024-25741",
    "CVE-2024-43835",
    "CVE-2024-46763",
    "CVE-2024-47740",
    "CVE-2024-53138",
    "CVE-2024-53241",
    "CVE-2025-21744",
    "CVE-2025-21806",
    "CVE-2025-21820",
    "CVE-2025-37807",
    "CVE-2025-38561",
    "CVE-2025-38584",
    "CVE-2025-39756",
    "CVE-2025-39901",
    "CVE-2025-40211"
  ]
}

SUSE-SU-2024:3551-1

Vulnerability from csaf_suse - Published: 2024-10-08 15:03 - Updated: 2026-09-20 17:03

Summary

Security update for the Linux Kernel

Severity

Important

Scope

162 vulnerabilities in this advisory, including CVE-2024-43835.

CVE-2024-43835

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 51 products

Open the full advisory

SUSE-SU-2024:3553-1

Vulnerability from csaf_suse - Published: 2024-10-08 15:10 - Updated: 2026-09-20 17:03

Summary

Security update for the Linux Kernel

Severity

Important

Scope

147 vulnerabilities in this advisory, including CVE-2024-43835.

CVE-2024-43835

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 8 products

Open the full advisory

SUSE-SU-2024:3561-1

Vulnerability from csaf_suse - Published: 2024-10-09 08:45 - Updated: 2026-09-20 17:03

Summary

Security update for the Linux Kernel

Severity

Important

Scope

162 vulnerabilities in this advisory, including CVE-2024-43835.

CVE-2024-43835

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 229 products

Open the full advisory

SUSE-SU-2024:3564-1

Vulnerability from csaf_suse - Published: 2024-10-09 09:09 - Updated: 2026-10-11 11:48

Summary

Security update for the Linux Kernel

Severity

Important

Scope

162 vulnerabilities in this advisory, including CVE-2024-43835.

CVE-2024-43835

5.5 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Recommended: 42 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2024-43835 (GCVE-0-2024-43835)

FKIE_CVE-2024-43835

GHSA-VGJ5-HQJJ-6HCJ

MSRC_CVE-2024-43835

OESA-2024-2446 (CVE-2024-26944)

Code starting with the faulting instruction

OESA-2025-2885 (CVE-2022-49121)

OESA-2025-2886 (CVE-2022-49426)

SUSE-SU-2024:3551-1

SUSE-SU-2024:3553-1

SUSE-SU-2024:3561-1

SUSE-SU-2024:3564-1

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour