Vulnerability-Lookup

CVE-2026-93830 (GCVE-0-2026-93830)

Vulnerability from cvelistv5 – Published: 2026-09-24 16:03 – Updated: 2026-10-03 10:58

Title

net: stmmac: xgmac2: disable RBUE in default RX interrupt mask

Summary

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring. However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE. On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm. RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix. Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions. Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.

Severity

7.5 (High)


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

Assigner

Linux CNA under the mitre root

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

References

7 references

URL	Tags
https://git.kernel.org/stable/c/8c9d57b5dc098b846…
https://git.kernel.org/stable/c/7a10e54e42a8f73a8…
https://git.kernel.org/stable/c/6b3b91433d5f4eae6…
https://git.kernel.org/stable/c/74dbb85a6a254b5fc…
https://git.kernel.org/stable/c/0b1a5d3647ce07c27…
https://git.kernel.org/stable/c/87e2826ed2058747d…
https://git.kernel.org/stable/c/d3265c19b35d036bb…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < 8c9d57b5dc098b84631d0b3559c84c499ea2170a (git) Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < 7a10e54e42a8f73a8d731f5a281fc06bb41b9250 (git) Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < 6b3b91433d5f4eae6865cdaa96f40cd67849e1f6 (git) Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < 74dbb85a6a254b5fc1f265a6cd61b2ba9d9221d7 (git) Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < 0b1a5d3647ce07c27a9fffefc11a8cbf7d7b25ce (git) Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < 87e2826ed2058747ddf014c082569a46bfadd96b (git) Affected: d6ddfacd95c79d43465d4a85dffb1c9beca343a9 , < d3265c19b35d036bba327b36b5366bee76b0157c (git)	guessed
Linux	Linux	Affected: 4.19 Unaffected: 0 , < 4.19 (semver) Unaffected: 5.10.271 , ≤ 5.10.* (semver) Unaffected: 5.15.222 , ≤ 5.15.* (semver) Unaffected: 6.1.189 , ≤ 6.1.* (semver) Unaffected: 6.6.158 , ≤ 6.6.* (semver) Unaffected: 6.12.111 , ≤ 6.12.* (semver) Unaffected: 6.18.53 , ≤ 6.18.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8c9d57b5dc098b84631d0b3559c84c499ea2170a",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            },
            {
              "lessThan": "7a10e54e42a8f73a8d731f5a281fc06bb41b9250",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            },
            {
              "lessThan": "6b3b91433d5f4eae6865cdaa96f40cd67849e1f6",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            },
            {
              "lessThan": "74dbb85a6a254b5fc1f265a6cd61b2ba9d9221d7",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            },
            {
              "lessThan": "0b1a5d3647ce07c27a9fffefc11a8cbf7d7b25ce",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            },
            {
              "lessThan": "87e2826ed2058747ddf014c082569a46bfadd96b",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            },
            {
              "lessThan": "d3265c19b35d036bba327b36b5366bee76b0157c",
              "status": "affected",
              "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.19"
            },
            {
              "lessThan": "4.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.271",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.222",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.189",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.158",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.111",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.53",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.271",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.222",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.189",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.158",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.111",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.53",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "4.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: xgmac2: disable RBUE in default RX interrupt mask\n\nEnabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive\nand can trigger a MAC interrupt storm under heavy RX pressure. When the\nDMA runs out of RX descriptors it fires RBUE continuously until software\nrefills the ring.\n\nHowever, RBUE is redundant: the normal RX completion interrupt (RIE)\nalready triggers NAPI, which processes completed descriptors and refills\nthe ring, causing the DMA to resume. The RBUE handler itself only sets\nhandle_rx - the same outcome as RIE.\n\nOn Agilex5 under heavy RX pressure, the MAC interrupt (which includes\nRBUE) was observed firing 1,821,811,555 times against only 2,618,627\nactual RX completions - a ~695x ratio - confirming the severity of the\nstorm.\n\nRBUE does not provide OOM recovery. If page_pool is exhausted,\nstmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays\nsuspended, and RBUE fires again on the next NAPI completion - a storm\nwith no forward progress. This patch trades that storm for a clean\nstall with the same RX outcome. Proper OOM recovery is a pre-existing\ngap outside the scope of this fix.\n\nNote: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool\ncounter will always read 0 on XGMAC2 devices. This behaviour is already\ninconsistent across DWMAC core versions.\n\nRemove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX\nto prevent the interrupt storm while keeping normal RX handling intact."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - Inbound Ethernet frames (IPv4/IPv6 unicast to the host MAC) are DMA\u0027d into the XGMAC2 RX ring; emptying it asserts XGMAC_RBU. With XGMAC_RBUE in XGMAC_DMA_INT_DEFAULT_RX, stmmac_interrupt/stmmac_msi_intr_rx \u2192 stmmac_napi_check \u2192 dwxgmac2_dma_interrupt runs. XGMAC2 is a 10G IP Ethernet MAC (Agilex5, Tegra MGBE, snps,dwxgmac).\nAC:L - A remote flood is enough: DMA_DEFAULT_RX_SIZE is 512, and Agilex5 under heavy RX already produced 1,821,811,555 MAC IRQs versus 2,618,627 completions. The attacker sets arrival rate; no race or layout is required. The worse stall (page_pool_alloc_pages failure in stmmac_rx_refill) is also GFP_ATOMIC exhaustion from that flood.\nPR:N - dwxgmac2_dma_interrupt runs from the XGMAC DMA hardirq (stmmac_interrupt or stmmac_msi_intr_rx) on received frames before any socket, netfilter verdict, or authentication check.\nUI:N - The attacker sends the frames themselves; stmmac_interrupt/stmmac_msi_intr_rx schedules NAPI via stmmac_napi_check with no local user action.\nS:U - The RBUE storm runs in the host kernel ISR/NAPI (stmmac_interrupt, dwxgmac2_dma_interrupt, stmmac_napi_poll_rx); it does not cross a VM, IOMMU, or sandbox boundary.\nC:N - On XGMAC_RBU, dwxgmac2_dma_interrupt only increments x-\u003erx_buf_unav_irq and returns handle_rx so NAPI runs; it does not read or return kernel memory to the sender.\nI:N - The RBU handler does not write attacker-controlled data into kernel objects; it only sets handle_rx. There is no OOB write, UAF, or control-flow hijack.\nA:H - With XGMAC_RBUE armed, RBU reasserts until stmmac_rx_refill advances the RX tail; if page_pool_alloc_pages fails, stmmac_napi_poll_rx\u0027s napi_complete_done path calls dwxgmac2_enable_dma_irq and the IRQ storms with no forward progress (~695x on Agilex5), livelocking the CPU."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-03T10:58:00.189Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8c9d57b5dc098b84631d0b3559c84c499ea2170a"
        },
        {
          "url": "https://git.kernel.org/stable/c/7a10e54e42a8f73a8d731f5a281fc06bb41b9250"
        },
        {
          "url": "https://git.kernel.org/stable/c/6b3b91433d5f4eae6865cdaa96f40cd67849e1f6"
        },
        {
          "url": "https://git.kernel.org/stable/c/74dbb85a6a254b5fc1f265a6cd61b2ba9d9221d7"
        },
        {
          "url": "https://git.kernel.org/stable/c/0b1a5d3647ce07c27a9fffefc11a8cbf7d7b25ce"
        },
        {
          "url": "https://git.kernel.org/stable/c/87e2826ed2058747ddf014c082569a46bfadd96b"
        },
        {
          "url": "https://git.kernel.org/stable/c/d3265c19b35d036bba327b36b5366bee76b0157c"
        }
      ],
      "title": "net: stmmac: xgmac2: disable RBUE in default RX interrupt mask",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-93830",
    "datePublished": "2026-09-24T16:03:12.818Z",
    "dateReserved": "2026-09-18T17:59:28.793Z",
    "dateUpdated": "2026-10-03T10:58:00.189Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-93830",
      "date": "2026-11-14",
      "epss": "0.0049",
      "percentile": "0.42719"
    },
    "microsoft_vex": {
      "current_release_date": "2026-10-15T02:47:06.000Z",
      "cve": "CVE-2026-93830",
      "id": "msrc_CVE-2026-93830",
      "initial_release_date": "2026-09-28T00:18:06.000Z",
      "product_status:fixed": "1",
      "product_status:known_affected": "1",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "net: stmmac: xgmac2: disable RBUE in default RX interrupt mask",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-93830.json",
      "version": "4"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "8c9d57b5dc098b84631d0b3559c84c499ea2170a",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "7a10e54e42a8f73a8d731f5a281fc06bb41b9250",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6b3b91433d5f4eae6865cdaa96f40cd67849e1f6",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "74dbb85a6a254b5fc1f265a6cd61b2ba9d9221d7",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "0b1a5d3647ce07c27a9fffefc11a8cbf7d7b25ce",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "87e2826ed2058747ddf014c082569a46bfadd96b",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "d3265c19b35d036bba327b36b5366bee76b0157c",
                    "status": "affected",
                    "version": "d6ddfacd95c79d43465d4a85dffb1c9beca343a9",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "4.19"
                  },
                  {
                    "lessThan": "4.19",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.271",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.222",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.189",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.158",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.111",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.53",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: xgmac2: disable RBUE in default RX interrupt mask\n\nEnabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive\nand can trigger a MAC interrupt storm under heavy RX pressure. When the\nDMA runs out of RX descriptors it fires RBUE continuously until software\nrefills the ring.\n\nHowever, RBUE is redundant: the normal RX completion interrupt (RIE)\nalready triggers NAPI, which processes completed descriptors and refills\nthe ring, causing the DMA to resume. The RBUE handler itself only sets\nhandle_rx - the same outcome as RIE.\n\nOn Agilex5 under heavy RX pressure, the MAC interrupt (which includes\nRBUE) was observed firing 1,821,811,555 times against only 2,618,627\nactual RX completions - a ~695x ratio - confirming the severity of the\nstorm.\n\nRBUE does not provide OOM recovery. If page_pool is exhausted,\nstmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays\nsuspended, and RBUE fires again on the next NAPI completion - a storm\nwith no forward progress. This patch trades that storm for a clean\nstall with the same RX outcome. Proper OOM recovery is a pre-existing\ngap outside the scope of this fix.\n\nNote: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool\ncounter will always read 0 on XGMAC2 devices. This behaviour is already\ninconsistent across DWMAC core versions.\n\nRemove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX\nto prevent the interrupt storm while keeping normal RX handling intact."
          }
        ],
        "id": "CVE-2026-93830",
        "lastModified": "2026-10-03T11:17:52.673",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 7.5,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 3.6,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-09-24T17:17:16.740",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/0b1a5d3647ce07c27a9fffefc11a8cbf7d7b25ce"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6b3b91433d5f4eae6865cdaa96f40cd67849e1f6"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/74dbb85a6a254b5fc1f265a6cd61b2ba9d9221d7"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/7a10e54e42a8f73a8d731f5a281fc06bb41b9250"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/87e2826ed2058747ddf014c082569a46bfadd96b"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/8c9d57b5dc098b84631d0b3559c84c499ea2170a"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/d3265c19b35d036bba327b36b5366bee76b0157c"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-11-06T02:12:36+00:00",
      "cve": "CVE-2026-93830",
      "id": "CVE-2026-93830",
      "initial_release_date": "2026-09-24T00:00:00+00:00",
      "product_status:known_affected": "161",
      "product_status:known_not_affected": "42",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: net: stmmac: xgmac2: disable RBUE in default RX interrupt mask",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-93830.json",
      "version": "3"
    }
  }
}

GHSA-QH7Q-28PC-C4HV

Vulnerability from github – Published: 2026-09-24 18:31 – Updated: 2026-10-03 12:31

Details

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

net: stmmac: xgmac2: disable RBUE in default RX interrupt mask

Enabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive and can trigger a MAC interrupt storm under heavy RX pressure. When the DMA runs out of RX descriptors it fires RBUE continuously until software refills the ring.

However, RBUE is redundant: the normal RX completion interrupt (RIE) already triggers NAPI, which processes completed descriptors and refills the ring, causing the DMA to resume. The RBUE handler itself only sets handle_rx - the same outcome as RIE.

On Agilex5 under heavy RX pressure, the MAC interrupt (which includes RBUE) was observed firing 1,821,811,555 times against only 2,618,627 actual RX completions - a ~695x ratio - confirming the severity of the storm.

RBUE does not provide OOM recovery. If page_pool is exhausted, stmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays suspended, and RBUE fires again on the next NAPI completion - a storm with no forward progress. This patch trades that storm for a clean stall with the same RX outcome. Proper OOM recovery is a pre-existing gap outside the scope of this fix.

Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions.

Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-93830"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T17:17:16Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: xgmac2: disable RBUE in default RX interrupt mask\n\nEnabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive\nand can trigger a MAC interrupt storm under heavy RX pressure. When the\nDMA runs out of RX descriptors it fires RBUE continuously until software\nrefills the ring.\n\nHowever, RBUE is redundant: the normal RX completion interrupt (RIE)\nalready triggers NAPI, which processes completed descriptors and refills\nthe ring, causing the DMA to resume. The RBUE handler itself only sets\nhandle_rx - the same outcome as RIE.\n\nOn Agilex5 under heavy RX pressure, the MAC interrupt (which includes\nRBUE) was observed firing 1,821,811,555 times against only 2,618,627\nactual RX completions - a ~695x ratio - confirming the severity of the\nstorm.\n\nRBUE does not provide OOM recovery. If page_pool is exhausted,\nstmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays\nsuspended, and RBUE fires again on the next NAPI completion - a storm\nwith no forward progress. This patch trades that storm for a clean\nstall with the same RX outcome. Proper OOM recovery is a pre-existing\ngap outside the scope of this fix.\n\nNote: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool\ncounter will always read 0 on XGMAC2 devices. This behaviour is already\ninconsistent across DWMAC core versions.\n\nRemove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX\nto prevent the interrupt storm while keeping normal RX handling intact.",
  "id": "GHSA-qh7q-28pc-c4hv",
  "modified": "2026-10-03T12:31:11Z",
  "published": "2026-09-24T18:31:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93830"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b1a5d3647ce07c27a9fffefc11a8cbf7d7b25ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6b3b91433d5f4eae6865cdaa96f40cd67849e1f6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/74dbb85a6a254b5fc1f265a6cd61b2ba9d9221d7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7a10e54e42a8f73a8d731f5a281fc06bb41b9250"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87e2826ed2058747ddf014c082569a46bfadd96b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8c9d57b5dc098b84631d0b3559c84c499ea2170a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d3265c19b35d036bba327b36b5366bee76b0157c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

MSRC_CVE-2026-93830

Vulnerability from csaf_microsoft - Published: 2026-09-28 00:18 - Updated: 2026-10-15 02:47

Summary

net: stmmac: xgmac2: disable RBUE in default RX interrupt mask

Scope

1 vulnerability in this advisory, including CVE-2026-93830.

CVE-2026-93830

7.5 (High)


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

Fixed: 1 product Known affected: 1 product

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

Open the full advisory

OESA-2026-4718 (CVE-2026-64585)

Vulnerability from osv_openeuler – Published: 2026-11-04 13:54 – Updated: 2026-11-04 13:54 – 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:

can: esd_usb: kill anchored URBs before freeing netdevs

esd_usb_disconnect() frees each CAN netdev with free_candev() inside its per-netdev loop and only calls unlink_all_urbs(dev) afterwards. The per-netdev private data (struct esd_usb_net_priv) is embedded in the net_device allocation returned by alloc_candev(), so once free_candev() has run, dev->nets[i] points to freed memory. unlink_all_urbs() then dereferences the freed dev->nets[i] to kill the per-netdev TX anchor (usb_kill_anchored_urbs(&priv->tx_submitted)), clear active_tx_jobs, and reset priv->tx_contexts[].

Reorder the teardown so the anchored URBs are killed before the netdevs are freed, matching other CAN/USB drivers in the same directory such as ems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then free: unregister the netdevs first (which stops their TX queues), call unlink_all_urbs(dev) once, then free the netdevs.

This issue was found by an in-house static analysis tool.(CVE-2026-64585)

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

ocfs2: avoid moving extents to occupied clusters

For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group.

The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated.

When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run.

Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.(CVE-2026-72164)

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

ntfs: fix off-by-one in mapping pairs decoding bounds checks

In ntfs_mapping_pairs_decompress(), attr_end points one byte past the end of the attribute record:

attr_end = (u8 *)attr + le32_to_cpu(attr-&gt;length);

The two bounds checks validating that mapping pair data bytes fit within the attribute use strict greater-than (>), which allows a one-byte out-of-bounds read when the data extends exactly to attr_end:

b = *buf & 0xf; if (b) { if (unlikely(buf + b > attr_end)) // off-by-one goto io_error; for (deltaxcn = (s8)buf[b--]; b; b--) deltaxcn = (deltaxcn << 8) + buf[b]; }

When buf + b == attr_end, the check evaluates to false and buf[b] reads one byte past the valid attribute boundary. The same pattern appears in the LCN delta bytes check.

Fix both checks to use >= so that buf[b] at exactly attr_end is correctly rejected as out of bounds.(CVE-2026-72210)

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

ASoC: codecs: hdac_hdmi: Validate written enum value

hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range.

An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.(CVE-2026-74295)

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

net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()

The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message.

The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation.

The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.(CVE-2026-74719)

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

vsock/virtio: flush works in dependency order

virtio_vsock_remove() stops the virtqueues and then flushes each work item before freeing the enclosing virtio_vsock. The current order does not account for dependencies between those items: tx_work may queue send_pkt_work, and send_pkt_work may queue rx_work.

In particular, send_pkt_work can set restart_rx and release tx_lock. The remove path can then stop the queues and flush rx_work before send_pkt_work queues it. Although the later send_pkt_work flush waits for that producer to finish, nothing waits for the newly queued rx_work, so kfree(vsock) can race with it.

KASAN reported:

BUG: KASAN: slab-use-after-free in virtio_transport_rx_work+0x487/0x4b0 Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47 Workqueue: virtio_vsock virtio_transport_rx_work Call Trace: virtio_transport_rx_work+0x487/0x4b0 process_one_work+0x688/0x1120 worker_thread+0x45b/0xd10 Allocated by task 1: virtio_vsock_probe+0xef/0x6b0 Freed by task 84: kfree+0x131/0x3c0 virtio_vsock_remove+0xd1/0x100

Flush the works in producer-to-consumer order. virtio_vsock_vqs_del() has already disabled the queue callbacks and cleared the run flags, so after tx_work and send_pkt_work are drained, no source remains that can queue rx_work after its flush.(CVE-2026-80932)

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

net/smc: stop killed, freed and out_of_sync sharing a byte

The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two:

u8  killed : 1;
u8  freed : 1;
u8  out_of_sync : 1;

They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock().

Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes.(CVE-2026-80980)

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

sctp: fix stream->outcnt underflow on duplicate RECONF responses

A cached RECONF chunk may contain more than one request parameter. A duplicate response can therefore find and process the same ADD_OUT request again while another parameter is still outstanding, rolling back outcnt twice and possibly underflowing it.

Track outstanding request types as bits and clear each bit after its first response. Later responses for the same request are then ignored.(CVE-2026-89476)

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

fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init

ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them.

mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation.

Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII.

The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN.

BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)(CVE-2026-89785)

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

ext4: fix out-of-bounds read in ext4_read_inline_dir()

ext4_read_inline_dir() can read a dirent header past the end of its inline buffer, triggering a slab-out-of-bounds read during getdents64():

BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry Read of size 2 at addr ffff88800f3dd23c by task exploit/148 ... __ext4_check_dir_entry ext4_read_inline_dir iterate_dir

The dirent payload lives in a buffer of exactly inline_size bytes:

dir_buf = kmalloc(inline_size, GFP_NOFS);

but iteration runs in a position space extra_offset bytes larger (extra_size = extra_offset + inline_size) so the synthetic "." and ".." land at their block-dir offsets. A dirent is formed at "dir_buf + pos - extra_offset", yet the ext4_check_dir_entry() length argument uses the larger extra_size. A position whose dirent header would extend past extra_size is therefore accepted, and the rescan loop's rec_len probe and ext4_check_dir_entry() dereference de->rec_len before the entry is rejected.

Reject a position whose minimum-size dirent header would not fit within extra_size before forming de, in both the rescan and main loops, and pass inline_size rather than extra_size to ext4_check_dir_entry() so the length check matches the physical buffer.(CVE-2026-89786)

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

KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save

MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths.

Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.(CVE-2026-89912)

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

KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU

When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on.

For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1)

The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will not request KVM_REQ_TLB_FLUSH).

Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().(CVE-2026-89929)

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

mtd: afs: validate v2 image info bounds

The AFS v2 parser uses footer[8] to locate the image information block inside the current erase block, then uses the image information region_count to walk entries from a fixed local array. The footer offset and region count come from flash contents and are not checked against the erase block or the local image-info array before use.

Reject v2 entries whose image information offset would underflow the erase block calculation, and reject region counts that cannot fit in the local image-info array before walking region entries.(CVE-2026-89954)

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

ALSA: mtpav: shut down output timer before card teardown

snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state.

snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer.

A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned.

Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released.(CVE-2026-90116)

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

NFSv4: remove callback IDR entry on client allocation failure

nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it finishes setting up the client. If any later initialization step fails, the error path frees the nfs_client directly with nfs_free_client(). That bypasses nfs_put_client(), which is where the callback IDR entry is removed during normal teardown.

A failed allocation can therefore leave cb_ident_idr pointing at a freed nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the stale pointer and take a reference to it.

Make the callback IDR removal helper callable by the allocation failure path, and remove the callback identifier before freeing the client.

This was found by a local static-analysis checker for publish-before-free lifetime bugs and confirmed by manual inspection.(CVE-2026-90151)

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

ASoC: xilinx: formatter_pcm: fix stream_data leak on open error

In xlnx_formatter_pcm_open(), stream_data is allocated and adata->play_stream or adata->capture_stream is assigned early. If a later step, such as snd_pcm_hw_constraint_step() or snd_pcm_hw_constraint_integer(), fails, the function returns the error immediately. ALSA does not call the close callback when open fails, so stream_data is leaked and the stream pointer is left dangling, pointing to a substream that ALSA frees. A later interrupt would then call snd_pcm_period_elapsed() on the freed substream.

Free stream_data and clear the stream pointer on the error paths.(CVE-2026-90214)

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

csky: Fix a4/a5 restoration in syscall trace path

The syscall trace path reloads syscall arguments from pt_regs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid.

The current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since those offsets are relative to the original pt_regs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments.

This is visible with mmap2(), which takes six arguments. A small PTRACE_SYSCALL reproducer opens a file and maps one page with:

mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0)

Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0.

Fix the trace path by loading a4/a5 from pt_regs before changing sp.

Tested on: ck860f, linux-4.19.15, C-SKY abiv2(CVE-2026-93167)

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

wifi: cfg80211: validate assoc response length before status and IE access

cfg80211_rx_assoc_resp() initialises the status and response-IE fields of cfg80211_connect_resp_params from the management frame before proving that the frame is long enough for those offsets. S1G and regular association responses also have different IE offsets, but the S1G path only patched resp_ie after the unsafe initialiser had already run.

Defer resp_ie, resp_ie_len, and status to after the link-iteration loop. Use a bool to remember whether the frame is S1G, then validate the appropriate minimum length and set all three fields in a single if/else block. Funnel short-frame and SME-reject cleanup through a shared free_bss label for the abandon paths.(CVE-2026-93806)

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

net: stmmac: xgmac2: disable RBUE in default RX interrupt mask

Note: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool counter will always read 0 on XGMAC2 devices. This behaviour is already inconsistent across DWMAC core versions.

Remove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX to prevent the interrupt storm while keeping normal RX handling intact.(CVE-2026-93830)

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

RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz()

Several corner cases, especially important on 32 bits:

umem->iova is u64, the function argument should pass in u64 or iova will be truncated
Check that the length is not too large for the iova
Check that lengths > 4G don't overflow the GENMASK(CVE-2026-97421)

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

genetlink: pin family module during policy dump

The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state. A dump may be split across multiple skbs and remain pending after the initial request.

Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner. The target family can consequently be unregistered and its module unloaded while a policy dump is pending. Advancing the dump then dereferences policy memory from the unloaded module.

Take a reference to the target family's module when the dump starts. Drop it from the error and done paths. This matches the lifetime for which the dump context retains the family and policy pointers.(CVE-2026-97901)

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

smb: client: fix potential OOB read in smb3_enum_snapshots()

If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply.

Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len.

Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read.(CVE-2026-98169)

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

wifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length

mwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a beacon/probe-response RSN or WPA information element and then walks that many 4-byte OUIs, comparing each with memcmp(). The count comes straight from the (attacker-supplied) IE and is never checked against the element's own length, and the callers admit the element on element_id alone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted RSN/WPA IE with a large pairwise count therefore makes the walk read up to 255 * 4 bytes past the element -- an out-of-bounds read of the kmemdup()'d beacon buffer, reachable from any AP whose beacon/probe response is processed during scan-result parsing.

Pass the number of IE bytes available at the OUI list and bound the walk to the element. Keep the length signed and reject a negative value before any unsigned arithmetic, so a small or zero IE length cannot underflow to a large size_t and defeat the bound.

Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-98186)

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

wifi: brcmsmac: fix UAF in brcms_free_timer()

brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of().

Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed.(CVE-2026-98196)

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

xfrm: save input state data before secpath resets

xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state.

Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol.

If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol.

Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.(CVE-2026-98229)

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

swiotlb: use the adjusted address for the highmem page lookup

swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it.

Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero.

The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt().

Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does.(CVE-2026-98254)

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

exec: Cleanup POSIX timers right after de_thread()

A per-thread CPU timer holds a reference to the PID of the thread it is attached to and, while it is armed, its node is queued in that thread's posix_cputimers. The task is looked up by that PID.

When a non-leader thread exec()s, de_thread() changes which task owns that PID. pid_task(timer->it.cpu.pid, PIDTYPE_PID) then returns NULL, but the node is still queued on tsk, which is alive. timer_lock_sighand() takes a failed lookup to mean that the node is already dequeued, so it has nothing to undo.

begin_new_exec() calls posix_cpu_timers_exit(me) right after exec_task_namespaces() and that removes the leftover node, so the state normally stays invisible. But bprm->point_of_no_return is set before de_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or exec_task_namespaces() fails, the task dies before it gets there. exit_itimers() then frees the k_itimer while its node is still queued, and reaping tsk later erases that freed node from the rbtree.

In short:

  the non-leader thread B           the parent

timer_create(CLOCK_THREAD_CPUTIME_ID) timer_settime() arm_timer() // the node is queued on B execve() de_thread(B) exchange_tids(B, leader) // B's PID now belongs to the leader release_task(leader) __exit_signal(leader) posix_cpu_timers_exit(leader) // cleans leader's queue, not B's __unhash_process(leader) // that PID has no task anymore exec_mmap() mmap_read_lock_killable(old_mm) kill(B, SIGKILL) // -EINTR get_signal() do_exit() exit_itimers() posix_timer_delete() posix_cpu_timer_del() posix_timer_unhash_and_free() // freed while still queued wait4() release_task(B) posix_cpu_timers_exit(B) cleanup_timerqueue() timerqueue_del() // use-after-free

Move the POSIX timer cleanup right after de_thread() before any of the later failure conditions brings the task into do_exit().

tglx: Move the cleanup right after de_thread()

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

wifi: cfg80211: don't filter by BSS type when removing stale entries

When an assoc AP switches to a channel that already has a BSS entry, cfg80211_update_assoc_bss_entry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree.

The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211_rehash_bss() then ran into it:

WARN_ON(!cmp)

Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison.(CVE-2026-98339)

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

wifi: cfg80211: don't free driver-owned scan requests

When an interface goes down while a scan is running, cfg80211 completes the scan towards userspace and frees the scan request. However, the driver can be convinced that it owns the request, since the cancellation is (intended to be) asynchronous.

The WARN_ON() in the netdev notifier was meant to catch this, but it's not actually avoidable, so it triggers and we get a UAF in scan_done().

There doesn't seem to be a great way around it, so just track that the driver is still convinced it owns the request, and then just free it on completion if it was already cancelled. Also remove the warnings since they can trigger in the intended architecture.(CVE-2026-98341)

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

xfrm: hold net_device reference under RCU in bundle creation

xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer.

BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860 xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640 ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0

Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references.(CVE-2026-98364)

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

xen/netfront: drop RX packets with a short Ethernet header

handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN.

If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead.

Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.(CVE-2026-98375)

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

smb: client: use finish_no_open() for non-regular inodes

An O_CREAT open can find an existing symlink or another non-regular inode. cifs_atomic_open() calls finish_open() on it and attaches a cifsFileInfo. Symlink inodes have no CIFS release operation, so the dentry reference held by cifsFileInfo is leaked. FMODE_OPENED also prevents the VFS from following the symlink.

Track whether cifs_do_create() returned an open server handle. For non-regular inodes, close the handle if present, remove the pending open, and call finish_no_open() so the VFS can continue the lookup. Do not set FMODE_CREATED unless a regular file was opened. For O_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS's -EFTYPE check.

Defer closing a legacy POSIX handle on a non-regular inode until after inode lookup. This avoids closing it again if lookup fails.(CVE-2026-98451)

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

smb: client: fix create context out-of-bounds reads

smb2_parse_contexts() validates the complete create-context area but does not limit each record to its Next field before dispatching it. A malformed chain can therefore expose bytes beyond the current context to a handler. The QFid handler also used a full response-structure cast although it only reads DiskFileId.

The SMB2/SMB3 lease parsers made the same layout assumption: they read LeaseState and LeaseFlags at canonical offsets rather than at DataOffset. A valid non-canonical DataOffset could therefore yield unrelated in-bounds data, while a short DataLength was still accepted.

Limit each context to its Next value, reject offsets before the context header, and reject malformed chains. Bound the name range by the current context and do not dispatch a known handler when DataLength is zero. Read the QFid DiskFileId only when the context data covers that field. Parse the lease context from DataOffset and require DataLength to match the v1 or v2 lease_context size used by ksmbd. A size mismatch skips lease parsing without failing the open.(CVE-2026-98454)

Severity

9.8 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/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-2026-64585	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72164	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72210	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74295	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74719	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-80932	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-80980	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89476	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89785	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89786	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89912	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89929	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89954	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90116	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90151	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90214	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93167	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93806	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93830	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-97421	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-97901	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98169	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98186	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98196	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98229	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98254	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98260	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98339	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98341	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98364	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98375	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98451	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-98454	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-340.0.0.241.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-340.0.0.241.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-340.0.0.241.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\ncan: esd_usb: kill anchored URBs before freeing netdevs\n\nesd_usb_disconnect() frees each CAN netdev with free_candev() inside\nits per-netdev loop and only calls unlink_all_urbs(dev) afterwards.\nThe per-netdev private data (struct esd_usb_net_priv) is embedded in\nthe net_device allocation returned by alloc_candev(), so once\nfree_candev() has run, dev-\u0026gt;nets[i] points to freed memory.\nunlink_all_urbs() then dereferences the freed dev-\u0026gt;nets[i] to kill the\nper-netdev TX anchor (usb_kill_anchored_urbs(\u0026amp;priv-\u0026gt;tx_submitted)),\nclear active_tx_jobs, and reset priv-\u0026gt;tx_contexts[].\n\nReorder the teardown so the anchored URBs are killed before the netdevs\nare freed, matching other CAN/USB drivers in the same directory such as\nems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then\nfree: unregister the netdevs first (which stops their TX queues), call\nunlink_all_urbs(dev) once, then free the netdevs.\n\nThis issue was found by an in-house static analysis tool.(CVE-2026-64585)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: avoid moving extents to occupied clusters\n\nFor non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical\nme_goal.  ocfs2_move_extent() initializes new_phys_cpos from that goal and\nexpects ocfs2_probe_alloc_group() to replace it with a free run in the\ntarget block group.\n\nThe probe currently leaves *phys_cpos unchanged if the scan reaches the\nend of the group without finding a free run.  An occupied goal at the last\nbit can therefore survive the probe and be passed to\n__ocfs2_move_extent(), which copies file data into a cluster still owned\nby another inode before the bitmap is updated.\n\nWhen the probe does find a free run, it also subtracts move_len from the\nending bit.  The start of an N-bit run ending at i is i - N + 1, so the\ncurrent calculation can report the bit immediately before the free run.\n\nClear *phys_cpos before scanning and use the correct free-run start. \nCallers already treat a zero result as -ENOSPC, so failed probes no longer\ncontinue with an occupied caller-controlled goal.(CVE-2026-72164)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: fix off-by-one in mapping pairs decoding bounds checks\n\nIn ntfs_mapping_pairs_decompress(), attr_end points one byte past the\nend of the attribute record:\n\n    attr_end = (u8 *)attr + le32_to_cpu(attr-\u0026gt;length);\n\nThe two bounds checks validating that mapping pair data bytes fit within\nthe attribute use strict greater-than (\u0026gt;), which allows a one-byte\nout-of-bounds read when the data extends exactly to attr_end:\n\n  b = *buf \u0026amp; 0xf;\n  if (b) {\n      if (unlikely(buf + b \u0026gt; attr_end))   // off-by-one\n          goto io_error;\n      for (deltaxcn = (s8)buf[b--]; b; b--)\n          deltaxcn = (deltaxcn \u0026lt;\u0026lt; 8) + buf[b];\n  }\n\nWhen buf + b == attr_end, the check evaluates to false and buf[b] reads\none byte past the valid attribute boundary. The same pattern appears in\nthe LCN delta bytes check.\n\nFix both checks to use \u0026gt;= so that buf[b] at exactly attr_end is\ncorrectly rejected as out of bounds.(CVE-2026-72210)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: codecs: hdac_hdmi: Validate written enum value\n\nhdac_hdmi_set_pin_port_mux() uses the written enum value to index the\ntexts array before calling snd_soc_dapm_put_enum_double(), which validates\nthat the value is within the enum item range.\n\nAn out-of-range value can therefore make the driver read past the texts\narray before the helper rejects the write. Move the lookup after the helper\nhas accepted the value.(CVE-2026-74295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()\n\nThe SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in\nsmc_llc_event_handler() stores an incoming qentry into the local LLC flow\nwithout first checking whether a qentry is already pending. If a malicious or\nbuggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is\nactive and flow-\u0026gt;qentry is already set, smc_llc_flow_qentry_set() overwrites the\npointer without freeing the previous allocation, leaking one kmalloc-96 object\nper spurious message.\n\nThe sibling SMC_LLC_DELETE_LINK branch already has the correct !flow-\u0026gt;qentry\nguard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a\nduplicate message when qentry is already occupied falls through to break and is\nfreed by the kfree(qentry) at the out: label, rather than silently leaking the\nexisting allocation.\n\nThe response direction (smc_llc_rx_response()) is unaffected: it already guards\nwith flow-\u0026gt;qentry at the equivalent site and drops duplicate responses\ncorrectly.(CVE-2026-74719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: flush works in dependency order\n\nvirtio_vsock_remove() stops the virtqueues and then flushes each work\nitem before freeing the enclosing virtio_vsock.  The current order does\nnot account for dependencies between those items: tx_work may queue\nsend_pkt_work, and send_pkt_work may queue rx_work.\n\nIn particular, send_pkt_work can set restart_rx and release tx_lock.\nThe remove path can then stop the queues and flush rx_work before\nsend_pkt_work queues it.  Although the later send_pkt_work flush waits\nfor that producer to finish, nothing waits for the newly queued rx_work,\nso kfree(vsock) can race with it.\n\nKASAN reported:\n\n  BUG: KASAN: slab-use-after-free in\n  virtio_transport_rx_work+0x487/0x4b0\n  Read of size 8 at addr ffff888114c2b008 by task kworker/1:1/47\n  Workqueue: virtio_vsock virtio_transport_rx_work\n  Call Trace:\n   virtio_transport_rx_work+0x487/0x4b0\n   process_one_work+0x688/0x1120\n   worker_thread+0x45b/0xd10\n  Allocated by task 1:\n   virtio_vsock_probe+0xef/0x6b0\n  Freed by task 84:\n   kfree+0x131/0x3c0\n   virtio_vsock_remove+0xd1/0x100\n\nFlush the works in producer-to-consumer order.  virtio_vsock_vqs_del()\nhas already disabled the queue callbacks and cleared the run flags, so\nafter tx_work and send_pkt_work are drained, no source remains that can\nqueue rx_work after its flush.(CVE-2026-80932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: stop killed, freed and out_of_sync sharing a byte\n\nThe three connection state flags are single-bit bitfields, so they occupy\none byte of struct smc_connection and every store to one is a\nread-modify-write of the other two:\n\n    u8  killed : 1;\n    u8  freed : 1;\n    u8  out_of_sync : 1;\n\nThey are not written under a common lock. smc_cdc_msg_validate() sets\nout_of_sync from the receive tasklet, while smc_conn_kill() sets killed\nfrom process context under lock_sock(), and the receive path does not defer\nto the backlog when the socket is owned -- smc_cdc_msg_recv() takes only\nbh_lock_sock().\n\nGive each flag its own byte so a store no longer touches its neighbours.\nAll readers test them as booleans and are unchanged. struct smc_connection\ngrows by two bytes.(CVE-2026-80980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix stream-\u0026gt;outcnt underflow on duplicate RECONF responses\n\nA cached RECONF chunk may contain more than one request parameter.  A\nduplicate response can therefore find and process the same ADD_OUT request\nagain while another parameter is still outstanding, rolling back outcnt\ntwice and possibly underflowing it.\n\nTrack outstanding request types as bits and clear each bit after its first\nresponse.  Later responses for the same request are then ignored.(CVE-2026-89476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init\n\nntfs_reparse_init() and ntfs_objid_init() parse the index root of the\n$Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes\nnamed $R and $O). They read its type and rule fields through\nresident_data(), which does not check that the resident attribute is\nlarge enough to hold them.\n\nmi_enum_attr() accepts a resident attribute with data_off == asize and\ndata_size == 0. For such an attribute placed last in its MFT record,\nresident_data() returns a pointer to the end of the record_size buffer,\nso reading root-\u0026gt;type / root-\u0026gt;rule reads past the allocation.\n\nUse resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when\nit returns NULL, as ntfs_security_init() already does for $SDH / $SII.\n\nThe attribute is only parsed while mounting a crafted image, so this\nneeds CAP_SYS_ADMIN.\n\n BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306)\n Read of size 4 at addr ffff88801219dc00 by task mount\n  ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306)\n  ntfs_fill_super (fs/ntfs3/super.c:1604)\n  get_tree_bdev_flags (fs/super.c:1703)\n  vfs_get_tree (fs/super.c:1758)\n  path_mount (fs/namespace.c:4131)\n  __x64_sys_mount (fs/namespace.c:4360)(CVE-2026-89785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix out-of-bounds read in ext4_read_inline_dir()\n\next4_read_inline_dir() can read a dirent header past the end of its inline\nbuffer, triggering a slab-out-of-bounds read during getdents64():\n\n  BUG: KASAN: slab-out-of-bounds in __ext4_check_dir_entry\n  Read of size 2 at addr ffff88800f3dd23c by task exploit/148\n   ...\n   __ext4_check_dir_entry\n   ext4_read_inline_dir\n   iterate_dir\n\nThe dirent payload lives in a buffer of exactly inline_size bytes:\n\n\tdir_buf = kmalloc(inline_size, GFP_NOFS);\n\nbut iteration runs in a position space extra_offset bytes larger\n(extra_size = extra_offset + inline_size) so the synthetic \u0026quot;.\u0026quot; and \u0026quot;..\u0026quot;\nland at their block-dir offsets. A dirent is formed at \u0026quot;dir_buf + pos -\nextra_offset\u0026quot;, yet the ext4_check_dir_entry() length argument uses the\nlarger extra_size. A position whose dirent header would extend past\nextra_size is therefore accepted, and the rescan loop\u0026apos;s rec_len probe and\next4_check_dir_entry() dereference de-\u0026gt;rec_len before the entry is rejected.\n\nReject a position whose minimum-size dirent header would not fit within\nextra_size before forming de, in both the rescan and main loops, and pass\ninline_size rather than extra_size to ext4_check_dir_entry() so the length\ncheck matches the physical buffer.(CVE-2026-89786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: vgic-its: Don\u0026apos;t dereference a NULL collection on ITT save\n\nMAPC with V=0 drops ite-\u0026gt;collection but leaves the ITE on the device\u0026apos;s\nITT list, and vgic_its_save_ite() dereferences it unconditionally. A\nguest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the\nhost when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it.\nThat sequence is UNPREDICTABLE per the architecture, but KVM already\nhandles the resulting state in the translate, MOVI and DISCARD paths.\n\nSave a zeroed entry, which vgic_its_restore_ite() reads back as\ninvalid. Skipping the ITE instead would leave the ITT slot holding\nwhatever is in guest memory, and restore rejects an entry naming a\ncollection the restored collection table does not have.(CVE-2026-89912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nVM: Ensure INVVPID is emulated on the correct physical CPU\n\nWhen emulating INVVPID, KVM executes INVVPID on the physical CPU using\nvpid02 (instead of the L1 assigned VPID), after doing some validations\non the operands. However, it is possible that the physical CPU KVM\nexecutes INVVPID on is different from the CPU L2 is running on.\n\nFor example, in the following scenario:\n- L2 runs on CPU #1 and exits to L1 (vmx-\u0026gt;nested.vmcs02.cpu=1)\n- L1 migrates to CPU #2 and executes INVVPID\n- KVM executes INVVPID on CPU #2\n- L1 migrates back to CPU #1 and runs L2 (vmx-\u0026gt;nested.vmcs02.cpu=1)\n\nThe TLB entries on CPU #1 are never invalidated, because INVVPID was\nexecuted on CPU #2, and vmcs02 never ran on a different pCPU (i.e.\nvmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH).\n\nEnsure that INVVPID is being executed on the same pCPU that L2 last ran\non, and if not, fallback to clearing last_vpid=0 to trigger a full VPID\nflush on the next nested VM-Enter (as KVM will detect L1 using a\ndifferent VPID for L2). If L2 ends up running on a different pCPU, KVM\nwill flush the TLB anyway through vmx_vcpu_load_vmcs().(CVE-2026-89929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmtd: afs: validate v2 image info bounds\n\nThe AFS v2 parser uses footer[8] to locate the image information block\ninside the current erase block, then uses the image information\nregion_count to walk entries from a fixed local array. The footer offset\nand region count come from flash contents and are not checked against the\nerase block or the local image-info array before use.\n\nReject v2 entries whose image information offset would underflow the\nerase block calculation, and reject region counts that cannot fit in the\nlocal image-info array before walking region entries.(CVE-2026-89954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: mtpav: shut down output timer before card teardown\n\nsnd_mtpav_output_timer() rearms chip-\u0026gt;timer while holding\nchip-\u0026gt;spinlock and accesses the card-private mtpav state.\n\nsnd_mtpav_free() currently takes the same lock and calls\ntimer_delete() when the timer is active. This only removes a\npending timer; it does not wait for a callback that is already\nrunning and does not prevent the callback from rearming the timer.\n\nA callback running on another CPU can therefore continue after\nsnd_mtpav_free() releases the lock and access the card-private\nstate while the card is being torn down. It can also rearm the\ntimer after timer_delete() has returned.\n\nCall timer_shutdown_sync() without holding chip-\u0026gt;spinlock. This\nwaits for any running callback to finish and prevents further\nrearming before the card-private mtpav state is released.(CVE-2026-90116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: remove callback IDR entry on client allocation failure\n\nnfs4_alloc_client() allocates an NFSv4.0 callback identifier before it\nfinishes setting up the client. If any later initialization step fails,\nthe error path frees the nfs_client directly with nfs_free_client(). That\nbypasses nfs_put_client(), which is where the callback IDR entry is\nremoved during normal teardown.\n\nA failed allocation can therefore leave cb_ident_idr pointing at a freed\nnfs_client. A later NFSv4.0 callback lookup by cb_ident would find the\nstale pointer and take a reference to it.\n\nMake the callback IDR removal helper callable by the allocation failure\npath, and remove the callback identifier before freeing the client.\n\nThis was found by a local static-analysis checker for publish-before-free\nlifetime bugs and confirmed by manual inspection.(CVE-2026-90151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: xilinx: formatter_pcm: fix stream_data leak on open error\n\nIn xlnx_formatter_pcm_open(), stream_data is allocated and\nadata-\u0026gt;play_stream or adata-\u0026gt;capture_stream is assigned early.  If a\nlater step, such as snd_pcm_hw_constraint_step() or\nsnd_pcm_hw_constraint_integer(), fails, the function returns the error\nimmediately.  ALSA does not call the close callback when open fails, so\nstream_data is leaked and the stream pointer is left dangling, pointing\nto a substream that ALSA frees.  A later interrupt would then call\nsnd_pcm_period_elapsed() on the freed substream.\n\nFree stream_data and clear the stream pointer on the error paths.(CVE-2026-90214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncsky: Fix a4/a5 restoration in syscall trace path\n\nThe syscall trace path reloads syscall arguments from pt_regs before\ncalling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall\narguments are prepared as stack arguments before invoking syscallid.\n\nThe current code adjusts sp before loading LSAVE_A4 and LSAVE_A5. Since\nthose offsets are relative to the original pt_regs base, loading them\nafter changing sp fetches the wrong slots. As a result, traced syscalls\nthat use the 5th or 6th argument may receive corrupted arguments.\n\nThis is visible with mmap2(), which takes six arguments. A small\nPTRACE_SYSCALL reproducer opens a file and maps one page with:\n\n  mmap(NULL, 4096, PROT_READ | PROT_EXEC, MAP_PRIVATE, fd, 0)\n\nBefore the fix, the traced child fails the mmap and exits with 12.\nAfter the fix, the mapping succeeds and the child exits with 0.\n\nFix the trace path by loading a4/a5 from pt_regs before changing sp.\n\nTested on: ck860f, linux-4.19.15, C-SKY abiv2(CVE-2026-93167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: validate assoc response length before status and IE access\n\ncfg80211_rx_assoc_resp() initialises the status and response-IE fields\nof cfg80211_connect_resp_params from the management frame before\nproving that the frame is long enough for those offsets. S1G and\nregular association responses also have different IE offsets, but the\nS1G path only patched resp_ie after the unsafe initialiser had already\nrun.\n\nDefer resp_ie, resp_ie_len, and status to after the link-iteration\nloop. Use a bool to remember whether the frame is S1G, then validate\nthe appropriate minimum length and set all three fields in a single\nif/else block. Funnel short-frame and SME-reject cleanup through a\nshared free_bss label for the abandon paths.(CVE-2026-93806)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: xgmac2: disable RBUE in default RX interrupt mask\n\nEnabling the RX Buffer Unavailable (RBUE) interrupt is counterproductive\nand can trigger a MAC interrupt storm under heavy RX pressure. When the\nDMA runs out of RX descriptors it fires RBUE continuously until software\nrefills the ring.\n\nHowever, RBUE is redundant: the normal RX completion interrupt (RIE)\nalready triggers NAPI, which processes completed descriptors and refills\nthe ring, causing the DMA to resume. The RBUE handler itself only sets\nhandle_rx - the same outcome as RIE.\n\nOn Agilex5 under heavy RX pressure, the MAC interrupt (which includes\nRBUE) was observed firing 1,821,811,555 times against only 2,618,627\nactual RX completions - a ~695x ratio - confirming the severity of the\nstorm.\n\nRBUE does not provide OOM recovery. If page_pool is exhausted,\nstmmac_rx_refill() cannot advance the DMA tail pointer, the DMA stays\nsuspended, and RBUE fires again on the next NAPI completion - a storm\nwith no forward progress. This patch trades that storm for a clean\nstall with the same RX outcome. Proper OOM recovery is a pre-existing\ngap outside the scope of this fix.\n\nNote: as a consequence of disabling RBUE, the rx_buf_unav_irq ethtool\ncounter will always read 0 on XGMAC2 devices. This behaviour is already\ninconsistent across DWMAC core versions.\n\nRemove RBUE from XGMAC_DMA_INT_DEFAULT_EN and XGMAC_DMA_INT_DEFAULT_RX\nto prevent the interrupt storm while keeping normal RX handling intact.(CVE-2026-93830)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz()\n\nSeveral corner cases, especially important on 32 bits:\n\n- umem-\u0026gt;iova is u64, the function argument should pass in u64 or\n  iova will be truncated\n- Check that the length is not too large for the iova\n- Check that lengths \u0026gt; 4G don\u0026apos;t overflow the GENMASK(CVE-2026-97421)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngenetlink: pin family module during policy dump\n\nThe generic netlink controller\u0026apos;s policy dump keeps pointers to the target\nfamily\u0026apos;s operation and policy tables in its callback state.  A dump may be\nsplit across multiple skbs and remain pending after the initial request.\n\nNetlink pins the module which owns the dump callback, but in this case\nthat is the controller\u0026apos;s owner rather than the target family\u0026apos;s owner.  The\ntarget family can consequently be unregistered and its module unloaded\nwhile a policy dump is pending.  Advancing the dump then dereferences\npolicy memory from the unloaded module.\n\nTake a reference to the target family\u0026apos;s module when the dump starts.\nDrop it from the error and done paths.  This matches the lifetime for which\nthe dump context retains the family and policy pointers.(CVE-2026-97901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential OOB read in smb3_enum_snapshots()\n\nIf snapshot_array_size is smaller than GMT_TOKEN_SIZE,\nsmb3_enum_snapshots() sets ret_data_len to\nsizeof(struct smb_snapshot_array) without verifying the actual length\nof the server\u0026apos;s reply.\n\nBecause SMB2_ioctl() places no lower bound on the server-supplied\nOutputCount and allocates retbuf to exactly that length, a short reply\nresults in ret_data_len exceeding the size of retbuf. The subsequent\ncopy_to_user() then reads past the end of retbuf, leaking adjacent slab\nmemory to userspace.  The subsequent clamp check is ineffective as it\nonly reduces ret_data_len.\n\nFix this by rejecting replies shorter than\nsizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set\nto the 12-byte struct size rather than the 16-byte\nMIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes\nis exactly what copy_to_user() attempts to read.(CVE-2026-98169)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: bound the pairwise-cipher OUI walk to the IE length\n\nmwifiex_search_oui_in_ie() reads a pairwise-cipher (PTK) count from a\nbeacon/probe-response RSN or WPA information element and then walks that\nmany 4-byte OUIs, comparing each with memcmp(). The count comes straight\nfrom the (attacker-supplied) IE and is never checked against the\nelement\u0026apos;s own length, and the callers admit the element on element_id\nalone (has_ieee_hdr() / has_vendor_hdr(), no length check). A crafted\nRSN/WPA IE with a large pairwise count therefore makes the walk read up\nto 255 * 4 bytes past the element -- an out-of-bounds read of the\nkmemdup()\u0026apos;d beacon buffer, reachable from any AP whose beacon/probe\nresponse is processed during scan-result parsing.\n\nPass the number of IE bytes available at the OUI list and bound the walk\nto the element. Keep the length signed and reject a negative value\nbefore any unsigned arithmetic, so a small or zero IE length cannot\nunderflow to a large size_t and defeat the bound.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-98186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmsmac: fix UAF in brcms_free_timer()\n\nbrcms_free_timer() calls brcms_del_timer() which uses the non-synchronous\ncancel_delayed_work() to cancel the timer\u0026apos;s underlying delayed work.  If\nthe work callback (_brcms_timer) is already running, cancel_delayed_work()\nreturns false without waiting, and brcms_free_timer() proceeds to kfree(t)\nwhile the callback still accesses t through container_of().\n\nAdd an explicit cancel_delayed_work_sync() after brcms_del_timer() to\nguarantee that any in-flight callback has completed before the timer\nstructure is freed.(CVE-2026-98196)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: save input state data before secpath resets\n\nxfrm_input() stores the current xfrm_state in the skb secpath while it\ncontinues receive-side processing. Some input paths can reset that secpath\nbefore xfrm_input() has finished dereferencing the state.\n\nReceive callback users such as VTI and XFRM interfaces can reset the\nsecpath. The VTI receive path does so before checking whether the packet\ncrosses network namespaces, while the XFRM interface path does so only for\ncross-network-namespace packets. The XFRM_MAX_DEPTH error path can also\nreset the secpath before the final drop callback reports the current\nstate\u0026apos;s protocol.\n\nIf secpath_reset() drops the last state reference while the state is\nconcurrently deleted, xfrm_input() can still dereference the freed state\nwhen selecting transport_finish() or reporting the drop callback protocol.\n\nSave the state protocol on the stack while the state is still valid,\nand use the already saved address family for transport_finish(). A larval\nXFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This\npreserves the existing drop-path fallback while avoiding the post-reset\nstate dereferences without adding an extra state reference to every\nreceived packet.(CVE-2026-98229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: use the adjusted address for the highmem page lookup\n\nswiotlb_bounce() reads the page frame number from the slot\u0026apos;s recorded\norig_addr, then advances orig_addr by tlb_offset to reach the address\nthe caller asked about. The highmem branch mixes the two: the offset\nwithin the page comes from the adjusted address, the page from the value\nbefore it.\n\nOnce the adjustment crosses a page boundary the pair no longer describes\none location, and the whole copy lands one page below the intended one\nfor a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE\nwrites the device data over the wrong page and leaves the intended one\nstale, DMA_TO_DEVICE feeds the device from a page the mapping may not\ncover. Partial syncs through dma_sync_single_range_for_*() are what make\ntlb_offset non-zero.\n\nThe branch test is picked the same way, so a slot recorded in lowmem can\nbe adjusted into highmem and the lowmem path then hands a highmem\naddress to phys_to_virt().\n\nTake both from orig_addr once it is final and keep pfn in the branch\nthat uses it. PhysHighMem() asks the question straight from the address,\nas dma-debug already does.(CVE-2026-98254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexec: Cleanup POSIX timers right after de_thread()\n\nA per-thread CPU timer holds a reference to the PID of the thread it is\nattached to and, while it is armed, its node is queued in that thread\u0026apos;s\nposix_cputimers. The task is looked up by that PID.\n\nWhen a non-leader thread exec()s, de_thread() changes which task owns\nthat PID. pid_task(timer-\u0026gt;it.cpu.pid, PIDTYPE_PID) then returns NULL,\nbut the node is still queued on tsk, which is alive. timer_lock_sighand()\ntakes a failed lookup to mean that the node is already dequeued, so it\nhas nothing to undo.\n\nbegin_new_exec() calls posix_cpu_timers_exit(me) right after\nexec_task_namespaces() and that removes the leftover node, so the state\nnormally stays invisible. But bprm-\u0026gt;point_of_no_return is set before\nde_thread(), so if unshare_files(), set_mm_exe_file(), exec_mmap() or\nexec_task_namespaces() fails, the task dies before it gets there.\nexit_itimers() then frees the k_itimer while its node is still queued,\nand reaping tsk later erases that freed node from the rbtree.\n\nIn short:\n\n      the non-leader thread B           the parent\n\n  timer_create(CLOCK_THREAD_CPUTIME_ID)\n  timer_settime()\n    arm_timer()            // the node is queued on B\n  execve()\n    de_thread(B)\n      exchange_tids(B, leader)  // B\u0026apos;s PID now belongs to the leader\n      release_task(leader)\n        __exit_signal(leader)\n          posix_cpu_timers_exit(leader)  // cleans leader\u0026apos;s queue, not B\u0026apos;s\n          __unhash_process(leader)  // that PID has no task anymore\n    exec_mmap()\n      mmap_read_lock_killable(old_mm)\n                                kill(B, SIGKILL)\n      // -EINTR\n  get_signal()\n    do_exit()\n      exit_itimers()\n        posix_timer_delete()\n          posix_cpu_timer_del()\n        posix_timer_unhash_and_free()  // freed while still queued\n                                wait4()\n                                  release_task(B)\n                                    posix_cpu_timers_exit(B)\n                                      cleanup_timerqueue()\n                                        timerqueue_del()  // use-after-free\n\nMove the POSIX timer cleanup right after de_thread() before any of the\nlater failure conditions brings the task into do_exit().\n\n[ tglx: Move the cleanup right after de_thread() ](CVE-2026-98260)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: don\u0026apos;t filter by BSS type when removing stale entries\n\nWhen an assoc AP switches to a channel that already has a BSS entry,\ncfg80211_update_assoc_bss_entry() removes that entry before rehashing\nthe real one, since the two would otherwise collide in the BSS rbtree.\n\nThe lookup for that entry also required it to match the connection\u0026apos;s BSS\ntype, so an entry advertising e.g. the IBSS capability bit was left in\nplace, and the following cfg80211_rehash_bss() then ran into it:\n\n  WARN_ON(!cmp)\n\nChanging the type shouldn\u0026apos;t really happen, but can be triggered by a\nrogue AP/device, so drop the check and remove any entries matching\nthe comparison.(CVE-2026-98339)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: don\u0026apos;t free driver-owned scan requests\n\nWhen an interface goes down while a scan is running, cfg80211 completes\nthe scan towards userspace and frees the scan request. However, the\ndriver can be convinced that it owns the request, since the cancellation\nis (intended to be) asynchronous.\n\nThe WARN_ON() in the netdev notifier was meant to catch this, but it\u0026apos;s\nnot actually avoidable, so it triggers and we get a UAF in scan_done().\n\nThere doesn\u0026apos;t seem to be a great way around it, so just track that the\ndriver is still convinced it owns the request, and then just free it on\ncompletion if it was already cancelled. Also remove the warnings since\nthey can trigger in the intended architecture.(CVE-2026-98341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold net_device reference under RCU in bundle creation\n\nxfrm_bundle_create() and xfrm_create_dummy_bundle() read dst-\u0026gt;dev into\na local pointer without taking a device reference, then pass it to\nxfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst-\u0026gt;dev via\ndst_dev_put() and frees the old net_device, causing a use-after-free\nwhen xfrm6_fill_dst() later dereferences the stale dev pointer.\n\n  BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860\n  (net/ipv6/xfrm6_policy.c:86 netdev_hold())\n  Read of size 8 at addr ffff8880142fe588 by task exploit/153\n  Call Trace:\n   xfrm6_fill_dst+0x82c/0x860\n   xfrm_resolve_and_create_bundle+0x21d4/0x2bd0\n   xfrm_lookup_with_ifid+0x485/0x1640\n   ip6_dst_lookup_flow+0x19b/0x1e0\n   udpv6_sendmsg+0x1443/0x2dd0\n\nFix this by reading dst-\u0026gt;dev via dst_dev_rcu() and keeping the RCU\nread-side critical section active until xfrm_fill_dst() has taken the\nrequired device references.(CVE-2026-98364)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/netfront: drop RX packets with a short Ethernet header\n\nhandle_incoming_queue() pulls pull_to bytes into the head before\ncalling eth_type_trans().  pull_to is the length of the first RX slot,\ncapped at RX_COPY_THRESHOLD, and that length comes from the backend.\nNothing checks it against ETH_HLEN.\n\nIf the first slot is shorter than ETH_HLEN and more slots follow, the\nhead ends up shorter than an Ethernet header while skb-\u0026gt;len is longer,\nand eth_type_trans() BUG()s in __skb_pull().  If the whole packet is\nshorter than ETH_HLEN, eth_type_trans() reads the header past the end\nof the data instead.\n\nPull at least ETH_HLEN, and drop the packet if that fails, which also\ndrops packets too short to hold an Ethernet header.  This also checks\nthe return value of the pull, which was ignored.(CVE-2026-98375)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: use finish_no_open() for non-regular inodes\n\nAn O_CREAT open can find an existing symlink or another non-regular\ninode. cifs_atomic_open() calls finish_open() on it and attaches a\ncifsFileInfo. Symlink inodes have no CIFS release operation, so the\ndentry reference held by cifsFileInfo is leaked. FMODE_OPENED also\nprevents the VFS from following the symlink.\n\nTrack whether cifs_do_create() returned an open server handle. For\nnon-regular inodes, close the handle if present, remove the pending\nopen, and call finish_no_open() so the VFS can continue the lookup.\nDo not set FMODE_CREATED unless a regular file was opened. For\nO_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS\u0026apos;s\n-EFTYPE check.\n\nDefer closing a legacy POSIX handle on a non-regular inode until\nafter inode lookup. This avoids closing it again if lookup fails.(CVE-2026-98451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix create context out-of-bounds reads\n\nsmb2_parse_contexts() validates the complete create-context area but\ndoes not limit each record to its Next field before dispatching it.  A\nmalformed chain can therefore expose bytes beyond the current context to\na handler.  The QFid handler also used a full response-structure cast\nalthough it only reads DiskFileId.\n\nThe SMB2/SMB3 lease parsers made the same layout assumption: they read\nLeaseState and LeaseFlags at canonical offsets rather than at\nDataOffset.  A valid non-canonical DataOffset could therefore yield\nunrelated in-bounds data, while a short DataLength was still accepted.\n\nLimit each context to its Next value, reject offsets before the context\nheader, and reject malformed chains.  Bound the name range by the current\ncontext and do not dispatch a known handler when DataLength is zero.  Read\nthe QFid DiskFileId only when the context data covers that field.  Parse the\nlease context from DataOffset and require DataLength to match the v1 or v2\nlease_context size used by ksmbd.  A size mismatch skips lease parsing\nwithout failing the open.(CVE-2026-98454)",
  "id": "OESA-2026-4718",
  "modified": "2026-11-04T13:54:51Z",
  "published": "2026-11-04T13:54:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4718"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64585"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72164"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72210"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74719"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80980"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89785"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89786"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89912"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90151"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90214"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93167"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93806"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93830"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97421"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98169"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98186"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98196"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98229"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98254"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98260"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98339"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98341"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98364"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98375"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98451"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98454"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-64585",
    "CVE-2026-72164",
    "CVE-2026-72210",
    "CVE-2026-74295",
    "CVE-2026-74719",
    "CVE-2026-80932",
    "CVE-2026-80980",
    "CVE-2026-89476",
    "CVE-2026-89785",
    "CVE-2026-89786",
    "CVE-2026-89912",
    "CVE-2026-89929",
    "CVE-2026-89954",
    "CVE-2026-90116",
    "CVE-2026-90151",
    "CVE-2026-90214",
    "CVE-2026-93167",
    "CVE-2026-93806",
    "CVE-2026-93830",
    "CVE-2026-97421",
    "CVE-2026-97901",
    "CVE-2026-98169",
    "CVE-2026-98186",
    "CVE-2026-98196",
    "CVE-2026-98229",
    "CVE-2026-98254",
    "CVE-2026-98260",
    "CVE-2026-98339",
    "CVE-2026-98341",
    "CVE-2026-98364",
    "CVE-2026-98375",
    "CVE-2026-98451",
    "CVE-2026-98454"
  ]
}

OPENSUSE-SU-2026:22266-1

Vulnerability from csaf_opensuse - Published: 2026-11-09 17:28 - Updated: 2026-11-13 19:21

Summary

Security update for the Linux Kernel

Severity

Important

Scope

1356 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 136 products

Open the full advisory

OPENSUSE-SU-2026:22307-1

Vulnerability from csaf_opensuse - Published: 2026-11-09 11:39 - Updated: 2026-11-13 19:21

Summary

Security update for the Linux Kernel

Severity

Important

Scope

1390 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 12 products

Open the full advisory

OPENSUSE-SU-2026:22309-1

Vulnerability from csaf_opensuse - Published: 2026-11-09 18:11 - Updated: 2026-11-13 19:22

Summary

Security update for the Linux Kernel

Severity

Important

Scope

2819 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 136 products

Open the full advisory

SUSE-SU-2026:24550-1

Vulnerability from csaf_suse - Published: 2026-11-03 19:25 - Updated: 2026-11-06 11:24

Summary

Security update for the Linux Kernel

Severity

Important

Scope

1056 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 11 products

Open the full advisory

SUSE-SU-2026:24619-1

Vulnerability from csaf_suse - Published: 2026-11-03 18:30 - Updated: 2026-11-11 19:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

1056 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 17 products

Open the full advisory

SUSE-SU-2026:24643-1

Vulnerability from csaf_suse - Published: 2026-11-09 15:48 - Updated: 2026-11-11 19:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

1356 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 28 products

Open the full advisory

SUSE-SU-2026:24648-1

Vulnerability from csaf_suse - Published: 2026-11-09 15:25 - Updated: 2026-11-11 19:14

Summary

Security update for the Linux Kernel

Severity

Important

Scope

1356 vulnerabilities in this advisory, including CVE-2026-93830.

CVE-2026-93830

4.7 (Medium)


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

Recommended: 8 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

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

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-2026-93830 (GCVE-0-2026-93830)

OESA-2026-4718 (CVE-2026-64585)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour