CVE-2026-31414 (GCVE-0-2026-31414)

Vulnerability from cvelistv5 – Published: 2026-04-13 13:21 – Updated: 2026-10-19 18:35

Title

netfilter: nf_conntrack_expect: use expect->helper

Summary

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe. Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.

Severity

9.8 (Critical)


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

SSVC

Exploitation: none Automatable: yes Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-16 15:09 UTC

CWE

CWE-476 - NULL Pointer Dereference

Assigner

Linux CNA under the mitre root

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

References

9 references

URL	Tags
https://git.kernel.org/stable/c/847cb7fe26c5ce5dc…
https://git.kernel.org/stable/c/e7ccaa0a62a8ff2be…
https://git.kernel.org/stable/c/4bd1b3d839172724b…
https://git.kernel.org/stable/c/b53294bff19e56ada…
https://git.kernel.org/stable/c/3dfd3f7712b5a800f…
https://git.kernel.org/stable/c/f01794106042ee27e…
https://cert-portal.siemens.com/productcert/html/…
https://cert-portal.siemens.com/productcert/html/…
https://cert-portal.siemens.com/productcert/html/…

Impacted products

11 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: ea781f197d6a835cbb93a0bf88ee1696296ed8aa , < 847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781 (git) Affected: ea781f197d6a835cbb93a0bf88ee1696296ed8aa , < e7ccaa0a62a8ff2be5d521299ce79390c318d306 (git) Affected: ea781f197d6a835cbb93a0bf88ee1696296ed8aa , < 4bd1b3d839172724b33d8d02c5a4ff6a1c775417 (git) Affected: ea781f197d6a835cbb93a0bf88ee1696296ed8aa , < b53294bff19e56ada2f230ceb8b1ffde61cc3817 (git) Affected: ea781f197d6a835cbb93a0bf88ee1696296ed8aa , < 3dfd3f7712b5a800f2ba632179e9b738076a51f0 (git) Affected: ea781f197d6a835cbb93a0bf88ee1696296ed8aa , < f01794106042ee27e54af6fdf5b319a2fe3df94d (git)	guessed
Linux	Linux	Affected: 2.6.30 Unaffected: 0 , < 2.6.30 (semver) Unaffected: 6.1.168 , ≤ 6.1.* (semver) Unaffected: 6.6.134 , ≤ 6.6.* (semver) Unaffected: 6.12.81 , ≤ 6.12.* (semver) Unaffected: 6.18.22 , ≤ 6.18.* (semver) Unaffected: 6.19.12 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix)	guessed
Siemens	SIMATIC S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.5 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.7 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP	Affected: V3.1.5 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP	Affected: V3.1.7 , < * (custom)	guessed
Siemens	SIPLUS S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIPLUS S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.5 , < * (custom)	guessed
Siemens	SIPLUS S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.7 , < * (custom)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "affected": [
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.5",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.7",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.5",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.7",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.5",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.7",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.5",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.7",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.6",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.5",
                "versionType": "custom"
              }
            ]
          },
          {
            "defaultStatus": "unknown",
            "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
            "vendor": "Siemens",
            "versions": [
              {
                "lessThan": "*",
                "status": "affected",
                "version": "V3.1.7",
                "versionType": "custom"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-15T01:15:50.079Z",
          "orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
          "shortName": "siemens-SADP"
        },
        "references": [
          {
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
          },
          {
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
          },
          {
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
          }
        ],
        "x_adpType": "supplier"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-31414",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-16T15:09:06.034181Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-476",
                "description": "CWE-476 NULL Pointer Dereference",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-19T18:35:47.389Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/netfilter/nf_conntrack_expect.c",
            "net/netfilter/nf_conntrack_helper.c",
            "net/netfilter/nf_conntrack_netlink.c",
            "net/netfilter/nf_conntrack_sip.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781",
              "status": "affected",
              "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
              "versionType": "git"
            },
            {
              "lessThan": "e7ccaa0a62a8ff2be5d521299ce79390c318d306",
              "status": "affected",
              "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
              "versionType": "git"
            },
            {
              "lessThan": "4bd1b3d839172724b33d8d02c5a4ff6a1c775417",
              "status": "affected",
              "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
              "versionType": "git"
            },
            {
              "lessThan": "b53294bff19e56ada2f230ceb8b1ffde61cc3817",
              "status": "affected",
              "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
              "versionType": "git"
            },
            {
              "lessThan": "3dfd3f7712b5a800f2ba632179e9b738076a51f0",
              "status": "affected",
              "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
              "versionType": "git"
            },
            {
              "lessThan": "f01794106042ee27e54af6fdf5b319a2fe3df94d",
              "status": "affected",
              "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/netfilter/nf_conntrack_expect.c",
            "net/netfilter/nf_conntrack_helper.c",
            "net/netfilter/nf_conntrack_netlink.c",
            "net/netfilter/nf_conntrack_sip.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.30"
            },
            {
              "lessThan": "2.6.30",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.168",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.134",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.81",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.22",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.19.*",
              "status": "unaffected",
              "version": "6.19.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.168",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.134",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.81",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.22",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19.12",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0",
                  "versionStartIncluding": "2.6.30",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u003ehelper\n\nUse expect-\u003ehelper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u003emaster-\u003ehelper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The vulnerable helper lookup is reachable from packet-processing paths such as the SIP conntrack helper when network traffic creates and collides with expectations. A remote peer can drive SIP/SDP traffic through a reasonably configured firewall/router using this helper.\nAC:L - The race/lifetime window can be exercised by repeatedly creating and tearing down related conntrack expectations, which the attacker can influence through controlled traffic. No rare, attacker-uncontrolled condition is required beyond the affected helper being enabled.\nPR:N - The network packet path does not require local credentials or capabilities. Although ctnetlink and proc dump paths are local and capability-gated, the SIP helper path gives a no-privilege remote trigger.\nUI:N - Exploitation does not require a victim user to perform an action. The attacker only needs to send crafted traffic or local netlink/proc requests in the relevant scenario.\nS:U - The vulnerability is in the kernel networking subsystem and impacts kernel resources under the same security authority. It is not a VM escape, IOMMU bypass, or cross-scope isolation break by itself.\nC:H - The bug is a stale use of the master conntrack/helper state, allowing kernel heap use-after-free reads through helper pointers. Under the required conservative scoring rule, this can expose arbitrary kernel memory.\nI:H - Use-after-free in kernel heap objects can be shaped with heap spraying and may be leveraged beyond the immediate stale read. Under the required conservative scoring rule, kernel memory corruption is treated as high integrity impact.\nA:H - Invalid or attacker-shaped stale helper pointers can cause kernel oops or panic during packet processing, netlink dumps, event delivery, or proc reads. This provides a high availability impact."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:22:20.834Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781"
        },
        {
          "url": "https://git.kernel.org/stable/c/e7ccaa0a62a8ff2be5d521299ce79390c318d306"
        },
        {
          "url": "https://git.kernel.org/stable/c/4bd1b3d839172724b33d8d02c5a4ff6a1c775417"
        },
        {
          "url": "https://git.kernel.org/stable/c/b53294bff19e56ada2f230ceb8b1ffde61cc3817"
        },
        {
          "url": "https://git.kernel.org/stable/c/3dfd3f7712b5a800f2ba632179e9b738076a51f0"
        },
        {
          "url": "https://git.kernel.org/stable/c/f01794106042ee27e54af6fdf5b319a2fe3df94d"
        }
      ],
      "title": "netfilter: nf_conntrack_expect: use expect-\u003ehelper",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-31414",
    "datePublished": "2026-04-13T13:21:02.592Z",
    "dateReserved": "2026-03-09T15:48:24.087Z",
    "dateUpdated": "2026-10-19T18:35:47.389Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-31414",
      "date": "2026-11-01",
      "epss": "0.00559",
      "percentile": "0.46572"
    },
    "microsoft_vex": {
      "current_release_date": "2026-04-29T14:55:55.000Z",
      "cve": "CVE-2026-31414",
      "id": "msrc_CVE-2026-31414",
      "initial_release_date": "2026-04-02T00:00:00.000Z",
      "product_status:fixed": "1",
      "product_status:known_affected": "1",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "netfilter: nf_conntrack_expect: use expect-\u003ehelper",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-31414.json",
      "version": "3"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "net/netfilter/nf_conntrack_expect.c",
                  "net/netfilter/nf_conntrack_helper.c",
                  "net/netfilter/nf_conntrack_netlink.c",
                  "net/netfilter/nf_conntrack_sip.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781",
                    "status": "affected",
                    "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "e7ccaa0a62a8ff2be5d521299ce79390c318d306",
                    "status": "affected",
                    "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "4bd1b3d839172724b33d8d02c5a4ff6a1c775417",
                    "status": "affected",
                    "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "b53294bff19e56ada2f230ceb8b1ffde61cc3817",
                    "status": "affected",
                    "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "3dfd3f7712b5a800f2ba632179e9b738076a51f0",
                    "status": "affected",
                    "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "f01794106042ee27e54af6fdf5b319a2fe3df94d",
                    "status": "affected",
                    "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "net/netfilter/nf_conntrack_expect.c",
                  "net/netfilter/nf_conntrack_helper.c",
                  "net/netfilter/nf_conntrack_netlink.c",
                  "net/netfilter/nf_conntrack_sip.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "2.6.30"
                  },
                  {
                    "lessThan": "2.6.30",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.168",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.134",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.81",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.22",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.19.*",
                    "status": "unaffected",
                    "version": "6.19.12",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.0",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          },
          {
            "affectedData": [
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              }
            ],
            "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "FA3F529A-7902-49EA-972B-CF381C3A0208",
                    "versionEndExcluding": "6.1.168",
                    "versionStartIncluding": "2.6.30",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "F56F925B-BAF8-4F4B-B62F-1496AF19A307",
                    "versionEndExcluding": "6.6.134",
                    "versionStartIncluding": "6.2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "6EF80433-B33B-43C5-8E64-0FA7B8DCE1BC",
                    "versionEndExcluding": "6.12.81",
                    "versionStartIncluding": "6.7",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "C9DF8BCE-36D3-475D-9D21-19E4F02F9029",
                    "versionEndExcluding": "6.18.22",
                    "versionStartIncluding": "6.13",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "0A2B9540-02D5-41B4-B16A-82AF66FD4F36",
                    "versionEndExcluding": "6.19.12",
                    "versionStartIncluding": "6.19",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*",
                    "matchCriteriaId": "F253B622-8837-4245-BCE5-A7BF8FC76A16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*",
                    "matchCriteriaId": "4AE85AD8-4641-4E7C-A2F4-305E2CD9EE64",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*",
                    "matchCriteriaId": "F666C8D8-6538-46D4-B318-87610DE64C34",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*",
                    "matchCriteriaId": "02259FDA-961B-47BC-AE7F-93D7EC6E90C2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*",
                    "matchCriteriaId": "58A9FEFF-C040-420D-8F0A-BFDAAA1DF258",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*",
                    "matchCriteriaId": "1D2315C0-D46F-4F85-9754-F9E5E11374A6",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u003ehelper\n\nUse expect-\u003ehelper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u003emaster-\u003ehelper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb."
          }
        ],
        "id": "CVE-2026-31414",
        "lastModified": "2026-10-19T19:17:52.430",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 9.8,
                "baseSeverity": "CRITICAL",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-31414",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-16T15:09:06.034181Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-04-13T14:16:10.537",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/3dfd3f7712b5a800f2ba632179e9b738076a51f0"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/4bd1b3d839172724b33d8d02c5a4ff6a1c775417"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/b53294bff19e56ada2f230ceb8b1ffde61cc3817"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/e7ccaa0a62a8ff2be5d521299ce79390c318d306"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/f01794106042ee27e54af6fdf5b319a2fe3df94d"
          },
          {
            "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
          },
          {
            "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
          },
          {
            "source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
            "url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "NVD-CWE-noinfo"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          },
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-476"
              }
            ],
            "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-02T17:13:32+00:00",
      "cve": "CVE-2026-31414",
      "id": "CVE-2026-31414",
      "initial_release_date": "2026-04-13T00:00:00+00:00",
      "product_status:known_affected": "274",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: Linux kernel (netfilter): Denial of Service via unsafe connection tracking helper operations",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31414.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "affected": [
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.6",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.5",
                    "versionType": "custom"
                  }
                ]
              },
              {
                "defaultStatus": "unknown",
                "product": "SIPLUS S7-1500 CPU 1518-4 PN/DP MFP",
                "vendor": "Siemens",
                "versions": [
                  {
                    "lessThan": "*",
                    "status": "affected",
                    "version": "V3.1.7",
                    "versionType": "custom"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-15T01:15:50.079Z",
              "orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
              "shortName": "siemens-SADP"
            },
            "references": [
              {
                "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
              },
              {
                "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
              },
              {
                "url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
              }
            ],
            "x_adpType": "supplier"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-31414",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-16T15:09:06.034181Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "problemTypes": [
              {
                "descriptions": [
                  {
                    "cweId": "CWE-476",
                    "description": "CWE-476 NULL Pointer Dereference",
                    "lang": "en",
                    "type": "CWE"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-16T15:09:06.635Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "net/netfilter/nf_conntrack_expect.c",
                "net/netfilter/nf_conntrack_helper.c",
                "net/netfilter/nf_conntrack_netlink.c",
                "net/netfilter/nf_conntrack_sip.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781",
                  "status": "affected",
                  "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                  "versionType": "git"
                },
                {
                  "lessThan": "e7ccaa0a62a8ff2be5d521299ce79390c318d306",
                  "status": "affected",
                  "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                  "versionType": "git"
                },
                {
                  "lessThan": "4bd1b3d839172724b33d8d02c5a4ff6a1c775417",
                  "status": "affected",
                  "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                  "versionType": "git"
                },
                {
                  "lessThan": "b53294bff19e56ada2f230ceb8b1ffde61cc3817",
                  "status": "affected",
                  "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                  "versionType": "git"
                },
                {
                  "lessThan": "3dfd3f7712b5a800f2ba632179e9b738076a51f0",
                  "status": "affected",
                  "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                  "versionType": "git"
                },
                {
                  "lessThan": "f01794106042ee27e54af6fdf5b319a2fe3df94d",
                  "status": "affected",
                  "version": "ea781f197d6a835cbb93a0bf88ee1696296ed8aa",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "net/netfilter/nf_conntrack_expect.c",
                "net/netfilter/nf_conntrack_helper.c",
                "net/netfilter/nf_conntrack_netlink.c",
                "net/netfilter/nf_conntrack_sip.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "2.6.30"
                },
                {
                  "lessThan": "2.6.30",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.168",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.134",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.12.*",
                  "status": "unaffected",
                  "version": "6.12.81",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.18.*",
                  "status": "unaffected",
                  "version": "6.18.22",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.19.*",
                  "status": "unaffected",
                  "version": "6.19.12",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "7.0",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.1.168",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.134",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.12.81",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.18.22",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.19.12",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "7.0",
                      "versionStartIncluding": "2.6.30",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u003ehelper\n\nUse expect-\u003ehelper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u003emaster-\u003ehelper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "baseScore": 9.8,
                "baseSeverity": "CRITICAL",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "AV:N - The vulnerable helper lookup is reachable from packet-processing paths such as the SIP conntrack helper when network traffic creates and collides with expectations. A remote peer can drive SIP/SDP traffic through a reasonably configured firewall/router using this helper.\nAC:L - The race/lifetime window can be exercised by repeatedly creating and tearing down related conntrack expectations, which the attacker can influence through controlled traffic. No rare, attacker-uncontrolled condition is required beyond the affected helper being enabled.\nPR:N - The network packet path does not require local credentials or capabilities. Although ctnetlink and proc dump paths are local and capability-gated, the SIP helper path gives a no-privilege remote trigger.\nUI:N - Exploitation does not require a victim user to perform an action. The attacker only needs to send crafted traffic or local netlink/proc requests in the relevant scenario.\nS:U - The vulnerability is in the kernel networking subsystem and impacts kernel resources under the same security authority. It is not a VM escape, IOMMU bypass, or cross-scope isolation break by itself.\nC:H - The bug is a stale use of the master conntrack/helper state, allowing kernel heap use-after-free reads through helper pointers. Under the required conservative scoring rule, this can expose arbitrary kernel memory.\nI:H - Use-after-free in kernel heap objects can be shaped with heap spraying and may be leveraged beyond the immediate stale read. Under the required conservative scoring rule, kernel memory corruption is treated as high integrity impact.\nA:H - Invalid or attacker-shaped stale helper pointers can cause kernel oops or panic during packet processing, netlink dumps, event delivery, or proc reads. This provides a high availability impact."
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-08-05T12:22:20.834Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781"
            },
            {
              "url": "https://git.kernel.org/stable/c/e7ccaa0a62a8ff2be5d521299ce79390c318d306"
            },
            {
              "url": "https://git.kernel.org/stable/c/4bd1b3d839172724b33d8d02c5a4ff6a1c775417"
            },
            {
              "url": "https://git.kernel.org/stable/c/b53294bff19e56ada2f230ceb8b1ffde61cc3817"
            },
            {
              "url": "https://git.kernel.org/stable/c/3dfd3f7712b5a800f2ba632179e9b738076a51f0"
            },
            {
              "url": "https://git.kernel.org/stable/c/f01794106042ee27e54af6fdf5b319a2fe3df94d"
            }
          ],
          "title": "netfilter: nf_conntrack_expect: use expect-\u003ehelper",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2026-31414",
        "datePublished": "2026-04-13T13:21:02.592Z",
        "dateReserved": "2026-03-09T15:48:24.087Z",
        "dateUpdated": "2026-10-19T18:35:47.389Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-79R8-QX2R-F755

Vulnerability from github – Published: 2026-04-13 15:31 – Updated: 2026-10-15 03:35

Details

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

netfilter: nf_conntrack_expect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.

Severity

9.8 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-31414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-13T14:16:10Z",
    "severity": "CRITICAL"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u003ehelper\n\nUse expect-\u003ehelper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u003emaster-\u003ehelper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.",
  "id": "GHSA-79r8-qx2r-f755",
  "modified": "2026-10-15T03:35:32Z",
  "published": "2026-04-13T15:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3dfd3f7712b5a800f2ba632179e9b738076a51f0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4bd1b3d839172724b33d8d02c5a4ff6a1c775417"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/847cb7fe26c5ce5dce0d1a41fac1ea488b7f1781"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b53294bff19e56ada2f230ceb8b1ffde61cc3817"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e7ccaa0a62a8ff2be5d521299ce79390c318d306"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f01794106042ee27e54af6fdf5b319a2fe3df94d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

ICSA-26-209-04

Vulnerability from csaf_cisa - Published: 2026-07-14 00:00 - Updated: 2026-07-28 06:00

Summary

Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP

Scope

352 vulnerabilities in this advisory, including CVE-2026-31414.

CVE-2026-31414

9.8 (Critical)


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

Known affected: 5 products

Open the full advisory

ICSA-26-295-11

Vulnerability from csaf_cisa - Published: 2026-10-13 00:00 - Updated: 2026-10-22 06:00

Summary

Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP

Scope

428 vulnerabilities in this advisory, including CVE-2026-31414.

CVE-2026-31414

9.8 (Critical)


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

Known affected: 5 products

Open the full advisory

MSRC_CVE-2026-31414

Vulnerability from csaf_microsoft - Published: 2026-04-02 00:00 - Updated: 2026-04-29 14:55

Summary

netfilter: nf_conntrack_expect: use expect->helper

Scope

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

CVE-2026-31414

Fixed: 1 product Known affected: 1 product

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

Open the full advisory

OESA-2026-2869 (CVE-2025-10263)

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

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)

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

smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)

In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ...

It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);(CVE-2025-39932)

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

riscv: Sanitize syscall table indexing under speculation

The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.(CVE-2025-71203)

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

nvme-fc: release admin tagset if init fails

nvme_fabrics creates an NVMe/FC controller in following path:

nvmf_dev_write()
  -&gt; nvmf_create_ctrl()
    -&gt; nvme_fc_create_ctrl()
      -&gt; nvme_fc_init_ctrl()

nvme_fc_init_ctrl() allocates the admin blk-mq resources right after nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the fail_ctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.

Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call nvme_remove_admin_tag_set() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)

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

arm64: io: Extract user memory type in ioremap_prot()

The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN:

Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().(CVE-2026-23346)

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

ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz

The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom.

This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100.

Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not.

Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.(CVE-2026-23377)

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

netfilter: nf_conntrack_expect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

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

ksmbd: fix OOB write in QUERY_INFO for compound requests

When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning.(CVE-2026-31432)

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

dmaengine: idxd: Fix leaking event log memory

During the device remove process, the device is reset, causing the configuration registers to go back to their default state, which is zero. As the driver is checking if the event log support was enabled before deallocating, it will fail if a reset happened before.

Do not check if the support was enabled, the check for 'idxd->evl' being valid (only allocated if the HW capability is available) is enough.(CVE-2026-31440)

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

dmaengine: idxd: Fix crash when the event log is disabled

If reporting errors to the event log is not supported by the hardware, and an error that causes Function Level Reset (FLR) is received, the driver will try to restore the event log even if it was not allocated.

Also, only try to free the event log if it was properly allocated.(CVE-2026-31443)

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

xfs: avoid dereferencing log items after push callbacks

After xfsaild_push_item() calls iop_push(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after iop_push() returns.

Fix this by capturing the log item type, flags, and LSN before calling xfsaild_push_item(), and introducing a new xfs_ail_push_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer.(CVE-2026-31453)

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

mm/huge_memory: fix folio isn't locked in softleaf_to_folio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows:

CPU0                                             CPU1

deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages

In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags.

This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page().

[(CVE-2026-31466)

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

net: openvswitch: Avoid releasing netdev before teardown completes

The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdev_destroy() callback can proceed immediately to the call_rcu() invocation if the IFF_OVS_DATAPATH flag is already cleared on the netdev.

The ovs_netdev_detach_dev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdev_destroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:

[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0 [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch] [ 998.394009] ? __die_body.cold+0x8/0x12 [ 998.394016] ? die_addr+0x3c/0x60 [ 998.394027] ? exc_general_protection+0x16d/0x390 [ 998.394042] ? asm_exc_general_protection+0x26/0x30 [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0 [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch] [ 998.394092] dp_device_event+0x41/0x80 [openvswitch] [ 998.394102] notifier_call_chain+0x5a/0xd0 [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60 [ 998.394110] rtnl_dellink+0x169/0x3e0 [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0 [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0 [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 998.394132] netlink_rcv_skb+0x50/0x100 [ 998.394138] netlink_unicast+0x292/0x3f0 [ 998.394141] netlink_sendmsg+0x21b/0x470 [ 998.394145] ____sys_sendmsg+0x39d/0x3d0 [ 998.394149] ___sys_sendmsg+0x9a/0xe0 [ 998.394156] __sys_sendmsg+0x7a/0xd0 [ 998.394160] do_syscall_64+0x7f/0x170 [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---(CVE-2026-31508)

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

wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.

syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]

The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs.

aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls.

aql_disable does not need to track inc/dec.

Let's use static_branch_enable() and static_branch_disable().

[0]: val == 0 WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288 Modules linked in: CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full) Tainted: [U]=USER, [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026 RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311 Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 <0f> 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00 RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4 RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98 FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline] __static_key_slow_dec kernel/jump_label.c:321 [inline] static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336 aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343 short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383 vfs_write+0x2aa/0x1070 fs/read_write.c:684 ksys_pwrite64 fs/read_write.c:793 [inline] __do_sys_pwrite64 fs/read_write.c:801 [inline] __se_sys_pwrite64 fs/read_write.c:798 [inline] __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f530cf9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012 RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010 RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978 </TASK>(CVE-2026-31551)

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

nvmet: move async event work off nvmet-wq

For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)

nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)

B. Full pre-work chain (RDMA CM path): nvmet_rdma_cm_handler() nvmet_rdma_queue_disconnect() __nvmet_rdma_queue_disconnect() queue_work(nvmet_wq, &queue->release_work) process_one_work() lock((wq_completion)nvmet-wq) <--------- 1st nvmet_rdma_release_queue_work()

C. Recursive path (same worker): nvmet_rdma_release_queue_work() nvmet_rdma_free_queue() nvmet_sq_destroy() nvmet_ctrl_put() nvmet_ctrl_free() flush_work(&ctrl->async_event_work) __flush_work() touch_wq_lockdep_map() lock((wq_completion)nvmet-wq) <--------- 2nd

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N

kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660

3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660 #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660 #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530

Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma] Call Trace: __flush_work+0x268/0x530 nvmet_ctrl_free+0x140/0x310 [nvmet] nvmet_cq_put+0x74/0x90 [nvmet] nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma] nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma] process_one_work+0x206/0x660 worker_thread+0x184/0x320 kthread+0x10c/0x240 ret_from_fork+0x319/0x390

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.(CVE-2026-31557)

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

bcache: fix cached_dev.sb_bio use-after-free and crash

In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:

[6888366.280350] Call Trace:
[6888366.280452]  blk_update_request+0x14e/0x370
[6888366.280561]  blk_mq_end_request+0x1a/0x130
[6888366.280671]  rbd_img_handle_request+0x1a0/0x1b0 [rbd]
[6888366.280792]  rbd_obj_handle_request+0x32/0x40 [rbd]
[6888366.280903]  __complete_request+0x22/0x70 [libceph]
[6888366.281032]  osd_dispatch+0x15e/0xb40 [libceph]
[6888366.281164]  ? inet_recvmsg+0x5b/0xd0
[6888366.281272]  ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]
[6888366.281405]  ceph_con_process_message+0x79/0x140 [libceph]
[6888366.281534]  ceph_con_v1_try_read+0x5d7/0xf30 [libceph]
[6888366.281661]  ceph_con_workfn+0x329/0x680 [libceph]

After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped.

Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.

This patch hopes to wait for sb_write to complete in cached_dev_free.

It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.(CVE-2026-31580)

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

xfrm: hold dev ref until after transport_finish NF_HOOK

After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown.

Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.(CVE-2026-31663)

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

xfrm: clear trailing padding in build_polexpire()

build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire.

The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents.

Add the missing memset_after() call, matching build_expire().(CVE-2026-31664)

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

netfilter: xt_multiport: validate range encoding in checkentry

ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule.

Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start.(CVE-2026-31681)

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

ksmbd: validate owner of durable handle on reconnect

Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.

According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durable_owner structure to ksmbd_file to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner() to validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)

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

usb: gadget: f_ecm: Fix net_device lifecycle with device_move

The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:

console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory

Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.

To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.(CVE-2026-31725)

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

Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists

hci_cmd_sync_queue_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources.

Change the function to return -EEXIST if queue item already exists.

Modify all callsites to handle that.(CVE-2026-43022)

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

netfilter: ctnetlink: ignore explicit helper on new expectations

Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation.

This was uncovered when validating CTA_EXPECT_CLASS via different helper provided by userspace than the existing master conntrack helper:

BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nf_ct_expect_related_report+0x2479/0x27c0 ctnetlink_create_expect+0x22b/0x3b0 ctnetlink_new_expect+0x4bd/0x5c0 nfnetlink_rcv_msg+0x67a/0x950 netlink_rcv_skb+0x120/0x350

Allowing to read kernel memory bytes off the expectation boundary.

CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace via netlink dump.(CVE-2026-43025)

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

netfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent

ctnetlink_alloc_expect() allocates expectations from a non-zeroing slab cache via nf_ct_expect_alloc(). When CTA_EXPECT_NAT is not present in the netlink message, saved_addr and saved_proto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlink_exp_dump_expect(), which checks these fields to decide whether to emit CTA_EXPECT_NAT.

The safe sibling nf_ct_expect_init(), used by the packet path, explicitly zeroes these fields.

Zero saved_addr, saved_proto and dir in the else branch, guarded by IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTA_EXPECT_NAT, and observing that the ctnetlink dump emits a spurious CTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)

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

xfrm: Wait for RCU readers during policy netns exit

xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.

The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory.

Fix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)

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

netfilter: ctnetlink: ensure safe access to master conntrack

Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid.

To access exp->master safely:

Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away.
Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.

This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section.

The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect().

However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct.

The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL.

For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master.

While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.(CVE-2026-43116)

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

dlm: validate length in dlm_search_rsb_tree

The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree().

Add length validation to prevent potential buffer overflow.(CVE-2026-43125)

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

ntfs3: fix circular locking dependency in run_unpack_ex

Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock.

The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone().

This creates an AB-BA deadlock.

Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock.(CVE-2026-43127)

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

iommu/amd: serialize sequence allocation under concurrent TLB invalidations

With concurrent TLB invalidations, completion wait randomly gets timed out because cmd_sem_val was incremented outside the IOMMU spinlock, allowing CMD_COMPL_WAIT commands to be queued out of sequence and breaking the ordering assumption in wait_on_sem(). Move the cmd_sem_val increment under iommu->lock so completion sequence allocation is serialized with command queuing. And remove the unnecessary return.(CVE-2026-43220)

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

smb: client: prevent races in ->query_interfaces()

It was possible for two query interface works to be concurrently trying to update the interfaces.

Prevent this by checking and updating iface_last_update under iface_lock.(CVE-2026-43239)

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

md raid: fix hang when stopping arrays with metadata through dm-raid

When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.

This occurs when:

A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)
The top-level RAID device is then removed

Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.

Fix:

Prevent bitmap flushing when md_stop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O
Still allow write-intent bitmap flushing when called from dm-raid suspend context

This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.

This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above.(CVE-2026-43309)

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

spi: spidev: fix lock inversion between spi_lock and buf_lock

The spidev driver previously used two mutexes, spi_lock and buf_lock, but acquired them in different orders depending on the code path:

write()/read(): buf_lock -> spi_lock ioctl(): spi_lock -> buf_lock

This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:

WARNING: possible circular locking dependency detected spidev_ioctl() -> mutex_lock(&spidev->buf_lock) spidev_sync_write() -> mutex_lock(&spidev->spi_lock) *** DEADLOCK ***

The issue is reproducible with a simple userspace program that performs write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from separate threads on the same spidev file descriptor.

Fix this by simplifying the locking model and removing the lock inversion entirely. spidev_sync() no longer performs any locking, and all callers serialize access using spi_lock.

buf_lock is removed since its functionality is fully covered by spi_lock, eliminating the possibility of lock ordering issues.

This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.(CVE-2026-43319)

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

sched/fair: Fix zero_vruntime tracking fix

John reported that stress-ng-yield could make his machine unhappy and managed to bisect it to commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking").

The combination of yield and that commit was specific enough to hypothesize the following scenario:

Suppose we have 2 runnable tasks, both doing yield. Then one will be eligible and one will not be, because the average position must be in between these two entities.

Therefore, the runnable task will be eligible, and be promoted a full slice (all the tasks do is yield after all). This causes it to jump over the other task and now the other task is eligible and current is no longer. So we schedule.

Since we are runnable, there is no {de,en}queue. All we have is the __{en,de}queue_entity() from {put_prev,set_next}_task(). But per the fingered commit, those two no longer move zero_vruntime.

All that moves zero_vruntime are tick and full {de,en}queue.

This means, that if the two tasks playing leapfrog can reach the critical speed to reach the overflow point inside one tick's worth of time, we're up a creek.

Additionally, when multiple cgroups are involved, there is no guarantee the tick will in fact hit every cgroup in a timely manner. Statistically speaking it will, but that same statistics does not rule out the possibility of one cgroup not getting a tick for a significant amount of time -- however unlikely.

Therefore, just like with the yield() case, force an update at the end of every slice. This ensures the update is never more than a single slice behind and the whole thing is within 2 lag bounds as per the comment on entity_key().(CVE-2026-43323)

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

smb: client: require a full NFS mode SID before reading mode bits

parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits.

That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE.

Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)

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

e1000/e1000e: Fix leak in DMA error cleanup

If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb.

Because count is incremented after a successful mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping would leak.

In these commits, a faulty while condition caused an infinite loop in dma_error: Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000e driver") Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver")

Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") fixed the infinite loop, but introduced the off-by-one error.

This issue may still exist in the igbvf driver, but I did not address it in this patch.(CVE-2026-43445)

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

nvme-pci: Fix race bug in nvme_poll_irqdisable()

In the following scenario, pdev can be disabled between (1) and (3) by (2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() will return MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2). This causes IRQ warning because it tries to enable INTx IRQ that has never been disabled before.

To fix this, save IRQ number into a local variable and ensure disable_irq() and enable_irq() operate on the same IRQ number. Even if pci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and enable_irq() on a stale IRQ number is still valid and safe, and the depth accounting reamins balanced.

task 1: nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)

task 2: nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)

crash log:

------------[ cut here ]------------ Unbalanced enable for IRQ 10 WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26 Modules linked in: CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_timeout_work RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753 Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9 RSP: 0018:ffffc900001bf550 EFLAGS: 00010046 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90 RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0 RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000 R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293 FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0 Call Trace: <TASK> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> irq event stamp: 74478 hardirqs last enabled at (74477): [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline] hardirqs last enabled at (74477): [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202 hardirqs last disabled at (74478): [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (74478): [<ffffffffb57207b5>] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162 softirqs last enabled at (74304): [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c:656 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c:496 [inline] softirqs last enabled at (74304): [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120 ---truncated---(CVE-2026-43448)

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

netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation

Ulrich reports a regression with nfqueue:

If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skb_clone happening via skb_gso_segment().

Move the check so that its peformed vs. the aggregated packet.

Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.

For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.

While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.

This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.

Next patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)

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

KVM: SVM: Add missing save/restore handling of LBR MSRs

MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken.

Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled. Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state().

Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore.

Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop).

sean: guard with lbrv checks, massage changelog

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

x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache

Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.(CVE-2026-46174)

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

netfilter: nft_inner: Fix IPv6 inner_thoff desync

In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2.

For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.(CVE-2026-46244)

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

tap: free page on error paths in tap_get_user_xdp()

tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk.

Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)

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

tun: free page on short-frame rejection in tun_xdp_one()

tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk.

A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.(CVE-2026-46321)

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

tun: free page on build_skb failure in tun_xdp_one()

When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk.

Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.(CVE-2026-46322)

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

net: gro: don't merge zcopy skbs

skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag.

When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.

When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.(CVE-2026-46323)

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

Revert "net/smc: Introduce TCP ULP support"

This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.

As reported by Al Viro, the TCP ULP support for SMC is fundamentally broken. The implementation attempts to convert an active TCP socket into an SMC socket by modifying the underlying struct file, dentry, and inode in-place, which violates core VFS invariants that assume these structures are immutable for an open file, creating a risk of use after free errors and general system instability.

Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely.(CVE-2026-46330)

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-2025-10263	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39932	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71203	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23261	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23346	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23377	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31414	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31432	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31440	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31443	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31453	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31466	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31508	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31551	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31557	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31580	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31663	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31664	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31681	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31717	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31725	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43022	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43025	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43026	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43091	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43116	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43125	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43127	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43220	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43239	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43309	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43319	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43323	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43350	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43445	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43448	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45859	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46014	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46174	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46244	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46320	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46321	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46322	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46323	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46330	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-devel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-extra-modules-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-headers-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-source-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-tools-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "perf-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "python3-perf-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.3.17.150.oe2403sp3.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-devel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-extra-modules-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-headers-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-source-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-tools-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "perf-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "python3-perf-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.3.17.150.oe2403sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm C1-Ultra, C1-Premium, Neoverse V3 \u0026amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 \u0026amp; X1C, Cortex-A710, Cortex-A78, A78AE \u0026amp; A78C, Cortex-A77, Cortex-A76 \u0026amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(\u0026amp;info-\u0026gt;post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [    T138]  process_one_work+0x629/0xf80\n[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info-\u0026gt;workqueue, \u0026amp;info-\u0026gt;post_send_credits_work);(CVE-2025-39932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sanitize syscall table indexing under speculation\n\nThe syscall number is a user-controlled value used to index into the\nsyscall table. Use array_index_nospec() to clamp this value after the\nbounds check to prevent speculative out-of-bounds access and subsequent\ndata leakage via cache side channels.(CVE-2025-71203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: release admin tagset if init fails\n\nnvme_fabrics creates an NVMe/FC controller in following path:\n\n    nvmf_dev_write()\n      -\u0026gt; nvmf_create_ctrl()\n        -\u0026gt; nvme_fc_create_ctrl()\n          -\u0026gt; nvme_fc_init_ctrl()\n\nnvme_fc_init_ctrl() allocates the admin blk-mq resources right after\nnvme_add_ctrl() succeeds.  If any of the subsequent steps fail (changing\nthe controller state, scheduling connect work, etc.), we jump to the\nfail_ctrl path, which tears down the controller references but never\nfrees the admin queue/tag set.  The leaked blk-mq allocations match the\nkmemleak report seen during blktests nvme/fc.\n\nCheck ctrl-\u0026gt;ctrl.admin_tagset in the fail_ctrl path and call\nnvme_remove_admin_tag_set() when it is set so that all admin queue\nallocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: io: Extract user memory type in ioremap_prot()\n\nThe only caller of ioremap_prot() outside of the generic ioremap()\nimplementation is generic_access_phys(), which passes a \u0026apos;pgprot_t\u0026apos; value\ndetermined from the user mapping of the target \u0026apos;pfn\u0026apos; being accessed by\nthe kernel. On arm64, the \u0026apos;pgprot_t\u0026apos; contains all of the non-address\nbits from the pte, including the permission controls, and so we end up\nreturning a new user mapping from ioremap_prot() which faults when\naccessed from the kernel on systems with PAN:\n\n  | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000\n  | ...\n  | Call trace:\n  |   __memcpy_fromio+0x80/0xf8\n  |   generic_access_phys+0x20c/0x2b8\n  |   __access_remote_vm+0x46c/0x5b8\n  |   access_remote_vm+0x18/0x30\n  |   environ_read+0x238/0x3e8\n  |   vfs_read+0xe4/0x2b0\n  |   ksys_read+0xcc/0x178\n  |   __arm64_sys_read+0x4c/0x68\n\nExtract only the memory type from the user \u0026apos;pgprot_t\u0026apos; in ioremap_prot()\nand assert that we\u0026apos;re being passed a user mapping, to protect us against\nany changes in future that may require additional handling. To avoid\nfalsely flagging users of ioremap(), provide our own ioremap() macro\nwhich simply wraps __ioremap_prot().(CVE-2026-23346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz\n\nThe only user of frag_size field in XDP RxQ info is\nbpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead\nof DMA write size. Different assumptions in ice driver configuration lead\nto negative tailroom.\n\nThis allows to trigger kernel panic, when using\nXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to\n6912 and the requested offset to a huge value, e.g.\nXSK_UMEM__MAX_FRAME_SIZE * 100.\n\nDue to other quirks of the ZC configuration in ice, panic is not observed\nin ZC mode, but tailroom growing still fails when it should not.\n\nUse fill queue buffer truesize instead of DMA write size in XDP RxQ info.\nFix ZC mode too by using the new helper.(CVE-2026-23377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u0026gt;helper\n\nUse expect-\u0026gt;helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u0026gt;master-\u0026gt;helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix OOB write in QUERY_INFO for compound requests\n\nWhen a compound request such as READ + QUERY_INFO(Security) is received,\nand the first command (READ) consumes most of the response buffer,\nksmbd could write beyond the allocated buffer while building a security\ndescriptor.\n\nThe root cause was that smb2_get_info_sec() checked buffer space using\nppntsd_size from xattr, while build_sec_desc() often synthesized a\nsignificantly larger descriptor from POSIX ACLs.\n\nThis patch introduces smb_acl_sec_desc_scratch_len() to accurately\ncompute the final descriptor size beforehand, performs proper buffer\nchecking with smb2_calc_max_out_buf_len(), and uses exact-sized\nallocation + iov pinning.(CVE-2026-31432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix leaking event log memory\n\nDuring the device remove process, the device is reset, causing the\nconfiguration registers to go back to their default state, which is\nzero. As the driver is checking if the event log support was enabled\nbefore deallocating, it will fail if a reset happened before.\n\nDo not check if the support was enabled, the check for \u0026apos;idxd-\u0026gt;evl\u0026apos;\nbeing valid (only allocated if the HW capability is available) is\nenough.(CVE-2026-31440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix crash when the event log is disabled\n\nIf reporting errors to the event log is not supported by the hardware,\nand an error that causes Function Level Reset (FLR) is received, the\ndriver will try to restore the event log even if it was not allocated.\n\nAlso, only try to free the event log if it was properly allocated.(CVE-2026-31443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix folio isn\u0026apos;t locked in softleaf_to_folio()\n\nOn arm64 server, we found folio that get from migration entry isn\u0026apos;t locked\nin softleaf_to_folio().  This issue triggers when mTHP splitting and\nzap_nonpresent_ptes() races, and the root cause is lack of memory barrier\nin softleaf_to_folio().  The race is as follows:\n\n\tCPU0                                             CPU1\n\ndeferred_split_scan()                              zap_nonpresent_ptes()\n  lock folio\n  split_folio()\n    unmap_folio()\n      change ptes to migration entries\n    __split_folio_to_order()                         softleaf_to_folio()\n      set flags(including PG_locked) for tail pages    folio = pfn_folio(softleaf_to_pfn(entry))\n      smp_wmb()                                        VM_WARN_ON_ONCE(!folio_test_locked(folio))\n      prep_compound_page() for tail pages\n\nIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages\nare visible before the tail page becomes non-compound.  smp_wmb() should\nbe paired with smp_rmb() in softleaf_to_folio(), which is missed.  As a\nresult, if zap_nonpresent_ptes() accesses migration entry that stores tail\npfn, softleaf_to_folio() may see the updated compound_head of tail page\nbefore page-\u0026gt;flags.\n\nThis issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()\nbecause of the race between folio split and zap_nonpresent_ptes()\nleading to a folio incorrectly undergoing modification without a folio\nlock being held.\n\nThis is a BUG_ON() before commit 93976a20345b (\u0026quot;mm: eliminate further\nswapops predicates\u0026quot;), which in merged in v6.19-rc1.\n\nTo fix it, add missing smp_rmb() if the softleaf entry is migration entry\nin softleaf_to_folio() and softleaf_to_page().\n\n[(CVE-2026-31466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Avoid releasing netdev before teardown completes\n\nThe patch cited in the Fixes tag below changed the teardown code for\nOVS ports to no longer unconditionally take the RTNL. After this change,\nthe netdev_destroy() callback can proceed immediately to the call_rcu()\ninvocation if the IFF_OVS_DATAPATH flag is already cleared on the\nnetdev.\n\nThe ovs_netdev_detach_dev() function clears the flag before completing\nthe unregistration, and if it gets preempted after clearing the flag (as\ncan happen on an -rt kernel), netdev_destroy() can complete and the\ndevice can be freed before the unregistration completes. This leads to a\nsplat like:\n\n[  998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI\n[  998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT\n[  998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025\n[  998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0\n[  998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 \u0026lt;48\u0026gt; 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90\n[  998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246\n[  998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000\n[  998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05\n[  998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000\n[  998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006\n[  998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000\n[  998.393931] FS:  00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000\n[  998.393936] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0\n[  998.393944] PKRU: 55555554\n[  998.393946] Call Trace:\n[  998.393949]  \u0026lt;TASK\u0026gt;\n[  998.393952]  ? show_trace_log_lvl+0x1b0/0x2f0\n[  998.393961]  ? show_trace_log_lvl+0x1b0/0x2f0\n[  998.393975]  ? dp_device_event+0x41/0x80 [openvswitch]\n[  998.394009]  ? __die_body.cold+0x8/0x12\n[  998.394016]  ? die_addr+0x3c/0x60\n[  998.394027]  ? exc_general_protection+0x16d/0x390\n[  998.394042]  ? asm_exc_general_protection+0x26/0x30\n[  998.394058]  ? dev_set_promiscuity+0x8d/0xa0\n[  998.394066]  ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]\n[  998.394092]  dp_device_event+0x41/0x80 [openvswitch]\n[  998.394102]  notifier_call_chain+0x5a/0xd0\n[  998.394106]  unregister_netdevice_many_notify+0x51b/0xa60\n[  998.394110]  rtnl_dellink+0x169/0x3e0\n[  998.394121]  ? rt_mutex_slowlock.constprop.0+0x95/0xd0\n[  998.394125]  rtnetlink_rcv_msg+0x142/0x3f0\n[  998.394128]  ? avc_has_perm_noaudit+0x69/0xf0\n[  998.394130]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[  998.394132]  netlink_rcv_skb+0x50/0x100\n[  998.394138]  netlink_unicast+0x292/0x3f0\n[  998.394141]  netlink_sendmsg+0x21b/0x470\n[  998.394145]  ____sys_sendmsg+0x39d/0x3d0\n[  998.394149]  ___sys_sendmsg+0x9a/0xe0\n[  998.394156]  __sys_sendmsg+0x7a/0xd0\n[  998.394160]  do_syscall_64+0x7f/0x170\n[  998.394162]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  998.394165] RIP: 0033:0x7fad61bf4724\n[  998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\n[  998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[  998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724\n[  998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003\n[  998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f\n[  998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2\n---truncated---(CVE-2026-31508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix static_branch_dec() underflow for aql_disable.\n\nsyzbot reported static_branch_dec() underflow in aql_enable_write(). [0]\n\nThe problem is that aql_enable_write() does not serialise concurrent\nwrite()s to the debugfs.\n\naql_enable_write() checks static_key_false(\u0026amp;aql_disable.key) and\nlater calls static_branch_inc() or static_branch_dec(), but the\nstate may change between the two calls.\n\naql_disable does not need to track inc/dec.\n\nLet\u0026apos;s use static_branch_enable() and static_branch_disable().\n\n[0]:\nval == 0\nWARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288\nModules linked in:\nCPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G     U       L      syzkaller #0 PREEMPT(full)\nTainted: [U]=USER, [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026\nRIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311\nCode: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 \u0026lt;0f\u0026gt; 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00\nRSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4\nRDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000\nRBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a\nR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98\nFS:  00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline]\n __static_key_slow_dec kernel/jump_label.c:321 [inline]\n static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336\n aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343\n short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383\n vfs_write+0x2aa/0x1070 fs/read_write.c:684\n ksys_pwrite64 fs/read_write.c:793 [inline]\n __do_sys_pwrite64 fs/read_write.c:801 [inline]\n __se_sys_pwrite64 fs/read_write.c:798 [inline]\n __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f530cf9aeb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012\nRAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010\nRBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000\nR10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978\n \u0026lt;/TASK\u0026gt;(CVE-2026-31551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: move async event work off nvmet-wq\n\nFor target nvmet_ctrl_free() flushes ctrl-\u0026gt;async_event_work.\nIf nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue\ncompletion for the same worker:-\n\nA. Async event work queued on nvmet-wq (prior to disconnect):\n  nvmet_execute_async_event()\n     queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\n  nvmet_add_async_event()\n     queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\nB. Full pre-work chain (RDMA CM path):\n  nvmet_rdma_cm_handler()\n     nvmet_rdma_queue_disconnect()\n       __nvmet_rdma_queue_disconnect()\n         queue_work(nvmet_wq, \u0026amp;queue-\u0026gt;release_work)\n           process_one_work()\n             lock((wq_completion)nvmet-wq)  \u0026lt;--------- 1st\n             nvmet_rdma_release_queue_work()\n\nC. Recursive path (same worker):\n  nvmet_rdma_release_queue_work()\n     nvmet_rdma_free_queue()\n       nvmet_sq_destroy()\n         nvmet_ctrl_put()\n           nvmet_ctrl_free()\n             flush_work(\u0026amp;ctrl-\u0026gt;async_event_work)\n               __flush_work()\n                 touch_wq_lockdep_map()\n                 lock((wq_completion)nvmet-wq) \u0026lt;--------- 2nd\n\nLockdep splat:\n\n  ============================================\n  WARNING: possible recursive locking detected\n  6.19.0-rc3nvme+ #14 Tainted: G                 N\n  --------------------------------------------\n  kworker/u192:42/44933 is trying to acquire lock:\n  ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n\n  but task is already holding lock:\n  ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n\n  3 locks held by kworker/u192:42/44933:\n   #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n   #1: ffffc9000e6cbe28 ((work_completion)(\u0026amp;queue-\u0026gt;release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660\n   #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530\n\n  Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]\n  Call Trace:\n   __flush_work+0x268/0x530\n   nvmet_ctrl_free+0x140/0x310 [nvmet]\n   nvmet_cq_put+0x74/0x90 [nvmet]\n   nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]\n   nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]\n   process_one_work+0x206/0x660\n   worker_thread+0x184/0x320\n   kthread+0x10c/0x240\n   ret_from_fork+0x319/0x390\n\nMove async event work to a dedicated nvmet-aen-wq to avoid reentrant\nflush on nvmet-wq.(CVE-2026-31557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix cached_dev.sb_bio use-after-free and crash\n\nIn our production environment, we have received multiple crash reports\nregarding libceph, which have caught our attention:\n\n```\n[6888366.280350] Call Trace:\n[6888366.280452]  blk_update_request+0x14e/0x370\n[6888366.280561]  blk_mq_end_request+0x1a/0x130\n[6888366.280671]  rbd_img_handle_request+0x1a0/0x1b0 [rbd]\n[6888366.280792]  rbd_obj_handle_request+0x32/0x40 [rbd]\n[6888366.280903]  __complete_request+0x22/0x70 [libceph]\n[6888366.281032]  osd_dispatch+0x15e/0xb40 [libceph]\n[6888366.281164]  ? inet_recvmsg+0x5b/0xd0\n[6888366.281272]  ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]\n[6888366.281405]  ceph_con_process_message+0x79/0x140 [libceph]\n[6888366.281534]  ceph_con_v1_try_read+0x5d7/0xf30 [libceph]\n[6888366.281661]  ceph_con_workfn+0x329/0x680 [libceph]\n```\n\nAfter analyzing the coredump file, we found that the address of\ndc-\u0026gt;sb_bio has been freed. We know that cached_dev is only freed when it\nis stopped.\n\nSince sb_bio is a part of struct cached_dev, rather than an alloc every\ntime.  If the device is stopped while writing to the superblock, the\nreleased address will be accessed at endio.\n\nThis patch hopes to wait for sb_write to complete in cached_dev_free.\n\nIt should be noted that we analyzed the cause of the problem, then tell\nall details to the QWEN and adopted the modifications it made.(CVE-2026-31580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u0026gt;dev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set.(CVE-2026-31663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: clear trailing padding in build_polexpire()\n\nbuild_expire() clears the trailing padding bytes of struct\nxfrm_user_expire after setting the hard field via memset_after(),\nbut the analogous function build_polexpire() does not do this for\nstruct xfrm_user_polexpire.\n\nThe padding bytes after the __u8 hard field are left\nuninitialized from the heap allocation, and are then sent to\nuserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,\nleaking kernel heap memory contents.\n\nAdd the missing memset_after() call, matching build_expire().(CVE-2026-31664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_multiport: validate range encoding in checkentry\n\nports_match_v1() treats any non-zero pflags entry as the start of a\nport range and unconditionally consumes the next ports[] element as\nthe range end.\n\nThe checkentry path currently validates protocol, flags and count, but\nit does not validate the range encoding itself. As a result, malformed\nrules can mark the last slot as a range start or place two range starts\nback to back, leaving ports_match_v1() to step past the last valid\nports[] element while interpreting the rule.\n\nReject malformed multiport v1 rules in checkentry by validating that\neach range start has a following element and that the following element\nis not itself marked as another range start.(CVE-2026-31681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate owner of durable handle on reconnect\n\nCurrently, ksmbd does not verify if the user attempting to reconnect\nto a durable handle is the same user who originally opened the file.\nThis allows any authenticated user to hijack an orphaned durable handle\nby predicting or brute-forcing the persistent ID.\n\nAccording to MS-SMB2, the server MUST verify that the SecurityContext\nof the reconnect request matches the SecurityContext associated with\nthe existing open.\nAdd a durable_owner structure to ksmbd_file to store the original opener\u0026apos;s\nUID, GID, and account name. and catpure the owner information when a file\nhandle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner()\nto validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ecm: Fix net_device lifecycle with device_move\n\nThe net_device is allocated during function instance creation and\nregistered during the bind phase with the gadget device as its sysfs\nparent. When the function unbinds, the parent device is destroyed, but\nthe net_device survives, resulting in dangling sysfs symlinks:\n\n  console:/ # ls -l /sys/class/net/usb0\n  lrwxrwxrwx ... /sys/class/net/usb0 -\u0026gt;\n  /sys/devices/platform/.../gadget.0/net/usb0\n  console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0\n  ls: .../gadget.0/net/usb0: No such file or directory\n\nUse device_move() to reparent the net_device between the gadget device\ntree and /sys/devices/virtual across bind and unbind cycles. During the\nfinal unbind, calling device_move(NULL) moves the net_device to the\nvirtual device tree before the gadget device is destroyed. On rebinding,\ndevice_move() reparents the device back under the new gadget, ensuring\nproper sysfs topology and power management ordering.\n\nTo maintain compatibility with legacy composite drivers (e.g., multi.c),\nthe bound flag is used to indicate whether the network device is shared\nand pre-registered during the legacy driver\u0026apos;s bind phase.(CVE-2026-31725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists\n\nhci_cmd_sync_queue_once() needs to indicate whether a queue item was\nadded, so caller can know if callbacks are called, so it can avoid\nleaking resources.\n\nChange the function to return -EEXIST if queue item already exists.\n\nModify all callsites to handle that.(CVE-2026-43022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ignore explicit helper on new expectations\n\nUse the existing master conntrack helper, anything else is not really\nsupported and it just makes validation more complicated, so just ignore\nwhat helper userspace suggests for this expectation.\n\nThis was uncovered when validating CTA_EXPECT_CLASS via different helper\nprovided by userspace than the existing master conntrack helper:\n\n  BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0\n  Read of size 4 at addr ffff8880043fe408 by task poc/102\n  Call Trace:\n   nf_ct_expect_related_report+0x2479/0x27c0\n   ctnetlink_create_expect+0x22b/0x3b0\n   ctnetlink_new_expect+0x4bd/0x5c0\n   nfnetlink_rcv_msg+0x67a/0x950\n   netlink_rcv_skb+0x120/0x350\n\nAllowing to read kernel memory bytes off the expectation boundary.\n\nCTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace\nvia netlink dump.(CVE-2026-43025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent\n\nctnetlink_alloc_expect() allocates expectations from a non-zeroing\nslab cache via nf_ct_expect_alloc().  When CTA_EXPECT_NAT is not\npresent in the netlink message, saved_addr and saved_proto are\nnever initialized.  Stale data from a previous slab occupant can\nthen be dumped to userspace by ctnetlink_exp_dump_expect(), which\nchecks these fields to decide whether to emit CTA_EXPECT_NAT.\n\nThe safe sibling nf_ct_expect_init(), used by the packet path,\nexplicitly zeroes these fields.\n\nZero saved_addr, saved_proto and dir in the else branch, guarded\nby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when\nNAT is enabled.\n\nConfirmed by priming the expect slab with NAT-bearing expectations,\nfreeing them, creating a new expectation without CTA_EXPECT_NAT,\nand observing that the ctnetlink dump emits a spurious\nCTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Wait for RCU readers during policy netns exit\n\nxfrm_policy_fini() frees the policy_bydst hash tables after flushing the\npolicy work items and deleting all policies, but it does not wait for\nconcurrent RCU readers to leave their read-side critical sections first.\n\nThe policy_bydst tables are published via rcu_assign_pointer() and are\nlooked up through rcu_dereference_check(), so netns teardown must also\nwait for an RCU grace period before freeing the table memory.\n\nFix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ensure safe access to master conntrack\n\nHolding reference on the expectation is not sufficient, the master\nconntrack object can just go away, making exp-\u0026gt;master invalid.\n\nTo access exp-\u0026gt;master safely:\n\n- Grab the nf_conntrack_expect_lock, this gets serialized with\n  clean_from_lists() which also holds this lock when the master\n  conntrack goes away.\n\n- Hold reference on master conntrack via nf_conntrack_find_get().\n  Not so easy since the master tuple to look up for the master conntrack\n  is not available in the existing problematic paths.\n\nThis patch goes for extending the nf_conntrack_expect_lock section\nto address this issue for simplicity, in the cases that are described\nbelow this is just slightly extending the lock section.\n\nThe add expectation command already holds a reference to the master\nconntrack from ctnetlink_create_expect().\n\nHowever, the delete expectation command needs to grab the spinlock\nbefore looking up for the expectation. Expand the existing spinlock\nsection to address this to cover the expectation lookup. Note that,\nthe nf_ct_expect_iterate_net() calls already grabs the spinlock while\niterating over the expectation table, which is correct.\n\nThe get expectation command needs to grab the spinlock to ensure master\nconntrack does not go away. This also expands the existing spinlock\nsection to cover the expectation lookup too. I needed to move the\nnetlink skb allocation out of the spinlock to keep it GFP_KERNEL.\n\nFor the expectation events, the IPEXP_DESTROY event is already delivered\nunder the spinlock, just move the delivery of IPEXP_NEW under the\nspinlock too because the master conntrack event cache is reached through\nexp-\u0026gt;master.\n\nWhile at it, add lockdep notations to help identify what codepaths need\nto grab the spinlock.(CVE-2026-43116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: validate length in dlm_search_rsb_tree\n\nThe len parameter in dlm_dump_rsb_name() is not validated and comes\nfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it can\ncause out-of-bounds write in dlm_search_rsb_tree().\n\nAdd length validation to prevent potential buffer overflow.(CVE-2026-43125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u0026gt;rw_lock\n(sbi-\u0026gt;used.bitmap) and ni-\u0026gt;file.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u0026gt;file.run_lock then wnd-\u0026gt;rw_lock.\n2. run_unpack_ex() takes wnd-\u0026gt;rw_lock then tries to acquire\n   ni-\u0026gt;file.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u0026gt;rw_lock.(CVE-2026-43127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: serialize sequence allocation under concurrent TLB invalidations\n\nWith concurrent TLB invalidations, completion wait randomly gets timed out\nbecause cmd_sem_val was incremented outside the IOMMU spinlock, allowing\nCMD_COMPL_WAIT commands to be queued out of sequence and breaking the\nordering assumption in wait_on_sem().\nMove the cmd_sem_val increment under iommu-\u0026gt;lock so completion sequence\nallocation is serialized with command queuing.\nAnd remove the unnecessary return.(CVE-2026-43220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: prevent races in -\u0026gt;query_interfaces()\n\nIt was possible for two query interface works to be concurrently trying\nto update the interfaces.\n\nPrevent this by checking and updating iface_last_update under\niface_lock.(CVE-2026-43239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd raid: fix hang when stopping arrays with metadata through dm-raid\n\nWhen using device-mapper\u0026apos;s dm-raid target, stopping a RAID array can cause\nthe system to hang under specific conditions.\n\nThis occurs when:\n\n- A dm-raid managed device tree is suspended from top to bottom\n   (the top-level RAID device is suspended first, followed by its\n    underlying metadata and data devices)\n\n- The top-level RAID device is then removed\n\nRemoving the top-level device triggers a hang in the following sequence:\nthe dm-raid destructor calls md_stop(), which tries to flush the\nwrite-intent bitmap by writing to the metadata sub-devices. However, these\ndevices are already suspended, making them unable to complete the write-intent\noperations and causing an indefinite block.\n\nFix:\n\n- Prevent bitmap flushing when md_stop() is called from dm-raid\ndestructor context\n  and avoid a quiescing/unquescing cycle which could also cause I/O\n\n- Still allow write-intent bitmap flushing when called from dm-raid\nsuspend context\n\nThis ensures that RAID array teardown can complete successfully even when the\nunderlying devices are in a suspended state.\n\nThis second patch uses md_is_rdwr() to distinguish between suspend and\ndestructor paths as elaborated on above.(CVE-2026-43309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: spidev: fix lock inversion between spi_lock and buf_lock\n\nThe spidev driver previously used two mutexes, spi_lock and buf_lock,\nbut acquired them in different orders depending on the code path:\n\n  write()/read(): buf_lock -\u0026gt; spi_lock\n  ioctl():       spi_lock -\u0026gt; buf_lock\n\nThis AB-BA locking pattern triggers lockdep warnings and can\ncause real deadlocks:\n\n  WARNING: possible circular locking dependency detected\n  spidev_ioctl() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;buf_lock)\n  spidev_sync_write() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;spi_lock)\n  *** DEADLOCK ***\n\nThe issue is reproducible with a simple userspace program that\nperforms write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from\nseparate threads on the same spidev file descriptor.\n\nFix this by simplifying the locking model and removing the lock\ninversion entirely. spidev_sync() no longer performs any locking,\nand all callers serialize access using spi_lock.\n\nbuf_lock is removed since its functionality is fully covered by\nspi_lock, eliminating the possibility of lock ordering issues.\n\nThis removes the lock inversion and prevents deadlocks without\nchanging userspace ABI or behaviour.(CVE-2026-43319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Fix zero_vruntime tracking fix\n\nJohn reported that stress-ng-yield could make his machine unhappy and\nmanaged to bisect it to commit b3d99f43c72b (\u0026quot;sched/fair: Fix\nzero_vruntime tracking\u0026quot;).\n\nThe combination of yield and that commit was specific enough to\nhypothesize the following scenario:\n\nSuppose we have 2 runnable tasks, both doing yield. Then one will be\neligible and one will not be, because the average position must be in\nbetween these two entities.\n\nTherefore, the runnable task will be eligible, and be promoted a full\nslice (all the tasks do is yield after all). This causes it to jump over\nthe other task and now the other task is eligible and current is no\nlonger. So we schedule.\n\nSince we are runnable, there is no {de,en}queue. All we have is the\n__{en,de}queue_entity() from {put_prev,set_next}_task(). But per the\nfingered commit, those two no longer move zero_vruntime.\n\nAll that moves zero_vruntime are tick and full {de,en}queue.\n\nThis means, that if the two tasks playing leapfrog can reach the\ncritical speed to reach the overflow point inside one tick\u0026apos;s worth of\ntime, we\u0026apos;re up a creek.\n\nAdditionally, when multiple cgroups are involved, there is no guarantee\nthe tick will in fact hit every cgroup in a timely manner. Statistically\nspeaking it will, but that same statistics does not rule out the\npossibility of one cgroup not getting a tick for a significant amount of\ntime -- however unlikely.\n\nTherefore, just like with the yield() case, force an update at the end\nof every slice. This ensures the update is never more than a single\nslice behind and the whole thing is within 2 lag bounds as per the\ncomment on entity_key().(CVE-2026-43323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities.  A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth \u0026gt;= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000/e1000e: Fix leak in DMA error cleanup\n\nIf an error is encountered while mapping TX buffers, the driver should\nunmap any buffers already mapped for that skb.\n\nBecause count is incremented after a successful mapping, it will always\nmatch the correct number of unmappings needed when dma_error is reached.\nDecrementing count before the while loop in dma_error causes an\noff-by-one error. If any mapping was successful before an unsuccessful\nmapping, exactly one DMA mapping would leak.\n\nIn these commits, a faulty while condition caused an infinite loop in\ndma_error:\nCommit 03b1320dfcee (\u0026quot;e1000e: remove use of skb_dma_map from e1000e\ndriver\u0026quot;)\nCommit 602c0554d7b0 (\u0026quot;e1000: remove use of skb_dma_map from e1000 driver\u0026quot;)\n\nCommit c1fa347f20f1 (\u0026quot;e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of\nunsigned in *_tx_map()\u0026quot;) fixed the infinite loop, but introduced the\noff-by-one error.\n\nThis issue may still exist in the igbvf driver, but I did not address it\nin this patch.(CVE-2026-43445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: Fix race bug in nvme_poll_irqdisable()\n\nIn the following scenario, pdev can be disabled between (1) and (3) by\n(2). This sets pdev-\u0026gt;msix_enabled = 0. Then, pci_irq_vector() will\nreturn MSI-X IRQ(\u0026gt;15) for (1) whereas return INTx IRQ(\u0026lt;=15) for (2).\nThis causes IRQ warning because it tries to enable INTx IRQ that has\nnever been disabled before.\n\nTo fix this, save IRQ number into a local variable and ensure\ndisable_irq() and enable_irq() operate on the same IRQ number.  Even if\npci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and\nenable_irq() on a stale IRQ number is still valid and safe, and the\ndepth accounting reamins balanced.\n\ntask 1:\nnvme_poll_irqdisable()\n  disable_irq(pci_irq_vector(pdev, nvmeq-\u0026gt;cq_vector)) ...(1)\n  enable_irq(pci_irq_vector(pdev, nvmeq-\u0026gt;cq_vector))  ...(3)\n\ntask 2:\nnvme_reset_work()\n  nvme_dev_disable()\n    pdev-\u0026gt;msix_enable = 0;  ...(2)\n\ncrash log:\n\n------------[ cut here ]------------\nUnbalanced enable for IRQ 10\nWARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26\nModules linked in:\nCPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753\nCode: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c \u0026lt;67\u0026gt; 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9\nRSP: 0018:ffffc900001bf550 EFLAGS: 00010046\nRAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90\nRDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0\nRBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000\nR13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293\nFS:  0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n enable_irq+0x121/0x1e0 kernel/irq/manage.c:797\n nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494\n nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744\n blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]\n blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721\n bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292\n __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]\n sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]\n bt_for_each block/blk-mq-tag.c:324 [inline]\n blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536\n blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763\n process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqueue.c:3340 [inline]\n worker_thread+0x65c/0xe60 kernel/workqueue.c:3421\n kthread+0x41a/0x930 kernel/kthread.c:463\n ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n \u0026lt;/TASK\u0026gt;\nirq event stamp: 74478\nhardirqs last  enabled at (74477): [\u0026lt;ffffffffb5720a9c\u0026gt;] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]\nhardirqs last  enabled at (74477): [\u0026lt;ffffffffb5720a9c\u0026gt;] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202\nhardirqs last disabled at (74478): [\u0026lt;ffffffffb57207b5\u0026gt;] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\nhardirqs last disabled at (74478): [\u0026lt;ffffffffb57207b5\u0026gt;] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162\nsoftirqs last  enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] __do_softirq kernel/softirq.c:656 [inline]\nsoftirqs last  enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] invoke_softirq kernel/softirq.c:496 [inline]\nsoftirqs last  enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] __irq_exit_rcu+0xdc/0x120\n---truncated---(CVE-2026-43448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation\n\nUlrich reports a regression with nfqueue:\n\nIf an application did not set the \u0026apos;F_GSO\u0026apos; capability flag and a gso\npacket with an unconfirmed nf_conn entry is received all packets are\nnow dropped instead of queued, because the check happens after\nskb_gso_segment().  In that case, we did have exclusive ownership\nof the skb and its associated conntrack entry.  The elevated use\ncount is due to skb_clone happening via skb_gso_segment().\n\nMove the check so that its peformed vs. the aggregated packet.\n\nThen, annotate the individual segments except the first one so we\ncan do a 2nd check at reinject time.\n\nFor the normal case, where userspace does in-order reinjects, this avoids\npacket drops: first reinjected segment continues traversal and confirms\nentry, remaining segments observe the confirmed entry.\n\nWhile at it, simplify nf_ct_drop_unconfirmed(): We only care about\nunconfirmed entries with a refcnt \u0026gt; 1, there is no need to special-case\ndying entries.\n\nThis only happens with UDP.  With TCP, the only unconfirmed packet will\nbe the TCP SYN, those aren\u0026apos;t aggregated by GRO.\n\nNext patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Add missing save/restore handling of LBR MSRs\n\nMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by\nKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So\nsave/restore is completely broken.\n\nFix it by adding the MSRs to msrs_to_save_base, and allowing writes to\nLBR MSRs from userspace only (as they are read-only MSRs) if LBR\nvirtualization is enabled.  Additionally, to correctly restore L1\u0026apos;s LBRs\nwhile L2 is running, make sure the LBRs are copied from the captured\nVMCB01 save area in svm_copy_vmrun_state().\n\nNote, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn\u0026apos;t\nreported as an MSR to save/restore.\n\nNote #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already\nhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 (\u0026quot;KVM:\nIgnore DEBUGCTL MSRs with no effect\u0026quot;) (kvm_do_msr_access() will morph the\nunsupported userspace write into a nop).\n\n[sean: guard with lbrv checks, massage changelog](CVE-2026-46014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Prevent improper isolation of shared resources in Zen2\u0026apos;s op cache\n\nMake sure resources are not improperly shared in the op cache and\ncause instruction corruption this way.(CVE-2026-46174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: Fix IPv6 inner_thoff desync\n\nIn nft_inner_parse_l2l3(), when processing inner IPv6 packets,\nipv6_find_hdr() correctly computes the transport header offset\ntraversing all extension headers, but the result is immediately\noverwritten with nhoff + sizeof(_ip6h) (40 bytes), which only\naccounts for the IPv6 base header. This creates a desync between\ninner_thoff (wrong \u2014 points to extension header start) and l4proto\n(correct \u2014 e.g., IPPROTO_TCP), enabling transport header forgery\nand potential firewall bypass. This issue affects stable versions\nfrom Linux 6.2.\n\nFor comparison, the normal (non-inner) IPv6 path correctly\npreserves ipv6_find_hdr()\u0026apos;s result. Removing the incorrect overwrite\nensures that ipv6_find_hdr()\u0026apos;s calculated transport header offset is\npreserved, thereby fixing the desynchronization.(CVE-2026-46244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntap: free page on error paths in tap_get_user_xdp()\n\ntap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,\nand returns -ENOMEM when build_skb() fails. Both paths jump to the err\nlabel without freeing the page that vhost_net_build_xdp() allocated for\nthe frame. tap_sendmsg() discards the per-buffer return value and always\nreturns 0, so vhost_tx_batch() takes the success path and never frees\nthe page; each rejected frame in a batch leaks one page-frag chunk.\n\nFree the page on both error paths, before the skb is built. This is the\ntap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on short-frame rejection in tun_xdp_one()\n\ntun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without\nfreeing the page that vhost_net_build_xdp() allocated for it.\ntun_sendmsg() discards that -EINVAL and still returns total_len, so\nvhost_tx_batch() takes the success path and never frees the page; each\nshort frame in a batch leaks one page-frag chunk.\n\nA local process that can open /dev/net/tun and /dev/vhost-net can hit\nthis path: it attaches a tun/tap device as the vhost-net backend and\nfeeds TX descriptors whose length minus the virtio-net header is below\nETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a\ntight submission loop exhausts host memory and triggers an OOM panic.\nFree the page before returning -EINVAL, matching the XDP-program error\npath in the same function.(CVE-2026-46321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on build_skb failure in tun_xdp_one()\n\nWhen build_skb() fails in tun_xdp_one(), the function sets ret to\n-ENOMEM and jumps to the out label, which returns without freeing the\npage that vhost_net_build_xdp() allocated for the frame. As with the\nshort-frame rejection path, tun_sendmsg() discards the per-buffer error\nand still returns total_len, so vhost_tx_batch() takes the success path\nand never frees the page. Each build_skb() failure in a batch leaks one\npage-frag chunk.\n\nFree the page before taking the error path, matching the put_page() the\nother error exits of tun_xdp_one() already perform.(CVE-2026-46322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: don\u0026apos;t merge zcopy skbs\n\nskb_gro_receive() can currently copy frags between the source and GRO\nskb, without checking the zerocopy status, and in particular the\nSKBFL_MANAGED_FRAG_REFS flag.\n\nWhen SKBFL_MANAGED_FRAG_REFS is set, the skb doesn\u0026apos;t hold a reference\non the pages in shinfo-\u0026gt;frags. Appending those frags to another skb\u0026apos;s\nfrags without fixing up the page refcount can lead to UAF.\n\nWhen either the last skb in the GRO chain (the one we would append\nfrags to) or the source skb is zerocopy, don\u0026apos;t merge the skbs.(CVE-2026-46323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;net/smc: Introduce TCP ULP support\u0026quot;\n\nThis reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.\n\nAs reported by Al Viro, the TCP ULP support for SMC is fundamentally\nbroken. The implementation attempts to convert an active TCP socket\ninto an SMC socket by modifying the underlying `struct file`, dentry,\nand inode in-place, which violates core VFS invariants that assume\nthese structures are immutable for an open file, creating a risk of\nuse after free errors and general system instability.\n\nGiven the severity of this design flaw and the fact that cleaner\nalternatives (e.g., LD_PRELOAD, BPF) exist for legacy application\ntransparency, the correct course of action is to remove this feature\nentirely.(CVE-2026-46330)",
  "id": "OESA-2026-2869",
  "modified": "2026-08-06T11:11:46Z",
  "published": "2026-07-06T11:11:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2869"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10263"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71203"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23261"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23346"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23377"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31432"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31440"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31443"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31508"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31551"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31557"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31580"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31663"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31717"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43026"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43127"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43239"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43323"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43350"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43445"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43448"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46174"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46244"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46320"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46321"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46323"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46330"
    }
  ],
  "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-2025-10263",
    "CVE-2025-39932",
    "CVE-2025-71203",
    "CVE-2026-23261",
    "CVE-2026-23346",
    "CVE-2026-23377",
    "CVE-2026-31414",
    "CVE-2026-31432",
    "CVE-2026-31440",
    "CVE-2026-31443",
    "CVE-2026-31453",
    "CVE-2026-31466",
    "CVE-2026-31508",
    "CVE-2026-31551",
    "CVE-2026-31557",
    "CVE-2026-31580",
    "CVE-2026-31663",
    "CVE-2026-31664",
    "CVE-2026-31681",
    "CVE-2026-31717",
    "CVE-2026-31725",
    "CVE-2026-43022",
    "CVE-2026-43025",
    "CVE-2026-43026",
    "CVE-2026-43091",
    "CVE-2026-43116",
    "CVE-2026-43125",
    "CVE-2026-43127",
    "CVE-2026-43220",
    "CVE-2026-43239",
    "CVE-2026-43309",
    "CVE-2026-43319",
    "CVE-2026-43323",
    "CVE-2026-43350",
    "CVE-2026-43445",
    "CVE-2026-43448",
    "CVE-2026-45859",
    "CVE-2026-46014",
    "CVE-2026-46174",
    "CVE-2026-46244",
    "CVE-2026-46320",
    "CVE-2026-46321",
    "CVE-2026-46322",
    "CVE-2026-46323",
    "CVE-2026-46330"
  ]
}

OESA-2026-2871 (CVE-2026-31414)

Vulnerability from osv_openeuler – Published: 2026-07-06 11:11 – Updated: 2026-08-06 11:11 – 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:

netfilter: nf_conntrack_expect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

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

xfs: avoid dereferencing log items after push callbacks

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

xfs: stop reclaim before pushing AIL during unmount

The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes.

Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.(CVE-2026-31455)

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

fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath

When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.(CVE-2026-43112)

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

xfs: remove xfs_attr_leaf_hasname

The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values.

Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read.(CVE-2026-43153)

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

xfs: fix freemap adjustments when adding xattrs to leaf blocks

xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:

ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));

Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.

At the start of xfs_attr3_leaf_add_work, the freemap looks like this:

i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520

where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440

Important note: 388 is not aligned with the entries array element size of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.

How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with:

376 bytes in use by the entries array
freemap[0] has [base = 376, size = 8]
freemap[1] has [base = 388, size = 1500]
the space between 376 and 388 is free, but the freemap stopped tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space.

The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0.(CVE-2026-43158)

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

smb: client: require a full NFS mode SID before reading mode bits

parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits.

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

xfs: fix undersized l_iclog_roundoff values

If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors...

XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount

...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this...

meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0

...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.(CVE-2026-43365)

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock.

If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.(CVE-2026-46135)

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

scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()

target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered.

Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.(CVE-2026-46149)

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

sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL

The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf().

While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.

sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *).

Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer.

Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive.

The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for.(CVE-2026-46227)

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

fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.

When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)

The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.

Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.

Lockdep splat:

WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock

Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); <Interrupt> lock(&dev->event_lock);

*** DEADLOCK ***(CVE-2026-52946)

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

HID: usbhid: fix deadlock in hid_post_reset()

You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.(CVE-2026-53037)

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

Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp

l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it.

Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().(CVE-2026-53071)

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-31414	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31453	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31455	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43112	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43153	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43158	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43350	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43365	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46135	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46149	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46227	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-52946	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53037	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53071	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-321.0.0.223.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-321.0.0.223.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-321.0.0.223.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\nnetfilter: nf_conntrack_expect: use expect-\u0026gt;helper\n\nUse expect-\u0026gt;helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u0026gt;master-\u0026gt;helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: stop reclaim before pushing AIL during unmount\n\nThe unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while\nbackground reclaim and inodegc are still running. This is broken\nindependently of any use-after-free issues - background reclaim and\ninodegc should not be running while the AIL is being pushed during\nunmount, as inodegc can dirty and insert inodes into the AIL during the\nflush, and background reclaim can race to abort and free dirty inodes.\n\nReorder xfs_unmount_flush_inodes() to stop inodegc and cancel background\nreclaim before pushing the AIL. Stop inodegc before cancelling\nm_reclaim_work because the inodegc worker can re-queue m_reclaim_work\nvia xfs_inodegc_set_reclaimable.(CVE-2026-31455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath\n\nWhen cifs_sanitize_prepath is called with an empty string or a string\ncontaining only delimiters (e.g., \u0026quot;/\u0026quot;), the current logic attempts to\ncheck *(cursor2 - 1) before cursor2 has advanced. This results in an\nout-of-bounds read.\n\nThis patch adds an early exit check after stripping prepended\ndelimiters. If no path content remains, the function returns NULL.\n\nThe bug was identified via manual audit and verified using a\nstandalone test case compiled with AddressSanitizer, which\ntriggered a SEGV on affected inputs.(CVE-2026-43112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: remove xfs_attr_leaf_hasname\n\nThe calling convention of xfs_attr_leaf_hasname() is problematic, because\nit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer\nwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a\nnon-NULL buffer pointer for an already released buffer when\nxfs_attr3_leaf_lookup_int fails with other error values.\n\nFix this by simply open coding xfs_attr_leaf_hasname in the callers, so\nthat the buffer release code is done by each caller of\nxfs_attr3_leaf_read.(CVE-2026-43153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix freemap adjustments when adding xattrs to leaf blocks\n\nxfs/592 and xfs/794 both trip this assertion in the leaf block freemap\nadjustment code after ~20 minutes of running on my test VMs:\n\n ASSERT(ichdr-\u0026gt;firstused \u0026gt;= ichdr-\u0026gt;count * sizeof(xfs_attr_leaf_entry_t)\n\t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf));\n\nUpon enabling quite a lot more debugging code, I narrowed this down to\nfsstress trying to set a local extended attribute with namelen=3 and\nvaluelen=71.  This results in an entry size of 80 bytes.\n\nAt the start of xfs_attr3_leaf_add_work, the freemap looks like this:\n\ni 0 base 448 size 0 rhs 448 count 46\ni 1 base 388 size 132 rhs 448 count 46\ni 2 base 2120 size 4 rhs 448 count 46\nfirstused = 520\n\nwhere \u0026quot;rhs\u0026quot; is the first byte past the end of the leaf entry array.\nThis is inconsistent -- the entries array ends at byte 448, but\nfreemap[1] says there\u0026apos;s free space starting at byte 388!\n\nBy the end of the function, the freemap is in worse shape:\n\ni 0 base 456 size 0 rhs 456 count 47\ni 1 base 388 size 52 rhs 456 count 47\ni 2 base 2120 size 4 rhs 456 count 47\nfirstused = 440\n\nImportant note: 388 is not aligned with the entries array element size\nof 8 bytes.\n\nBased on the incorrect freemap, the name area starts at byte 440, which\nis below the end of the entries array!  That\u0026apos;s why the assertion\ntriggers and the filesystem shuts down.\n\nHow did we end up here?  First, recall from the previous patch that the\nfreemap array in an xattr leaf block is not intended to be a\ncomprehensive map of all free space in the leaf block.  In other words,\nit\u0026apos;s perfectly legal to have a leaf block with:\n\n * 376 bytes in use by the entries array\n * freemap[0] has [base = 376, size = 8]\n * freemap[1] has [base = 388, size = 1500]\n * the space between 376 and 388 is free, but the freemap stopped\n   tracking that some time ago\n\nIf we add one xattr, the entries array grows to 384 bytes, and\nfreemap[0] becomes [base = 384, size = 0].  So far, so good.  But if we\nadd a second xattr, the entries array grows to 392 bytes, and freemap[0]\ngets pushed up to [base = 392, size = 0].  This is bad, because\nfreemap[1] hasn\u0026apos;t been updated, and now the entries array and the free\nspace claim the same space.\n\nThe fix here is to adjust all freemap entries so that none of them\ncollide with the entries array.  Note that this fix relies on commit\n2a2b5932db6758 (\u0026quot;xfs: fix attr leaf header freemap.size underflow\u0026quot;) and\nthe previous patch that resets zero length freemap entries to have\nbase = 0.(CVE-2026-43158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities.  A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth \u0026gt;= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix undersized l_iclog_roundoff values\n\nIf the superblock doesn\u0026apos;t list a log stripe unit, we set the incore log\nroundoff value to 512.  This leads to corrupt logs and unmountable\nfilesystems in generic/617 on a disk with 4k physical sectors...\n\nXFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c\nXFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.\nXFS (sda1): failed to locate log tail\nXFS (sda1): log mount/recovery failed: error -74\nXFS (sda1): log mount failed\nXFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c\nXFS (sda1): Ending clean mount\n\n...on the current xfsprogs for-next which has a broken mkfs.  xfs_info\nshows this...\n\nmeta-data=/dev/sda1              isize=512    agcount=4, agsize=644992 blks\n         =                       sectsz=4096  attr=2, projid32bit=1\n         =                       crc=1        finobt=1, sparse=1, rmapbt=1\n         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1\n         =                       exchange=1   metadir=1\ndata     =                       bsize=4096   blocks=2579968, imaxpct=25\n         =                       sunit=0      swidth=0 blks\nnaming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1\nlog      =internal log           bsize=4096   blocks=16384, version=2\n         =                       sectsz=4096  sunit=0 blks, lazy-count=1\nrealtime =none                   extsz=4096   blocks=0, rtextents=0\n         =                       rgcount=0    rgsize=268435456 extents\n         =                       zoned=0      start=0 reserved=0\n\n...observe that the log section has sectsz=4096 sunit=0, which means\nthat the roundoff factor is 512, not 4096 as you\u0026apos;d expect.  We should\nfix mkfs not to generate broken filesystems, but anyone can fuzz the\nondisk superblock so we should be more cautious.  I think the inadequate\nlogic predates commit a6a65fef5ef8d0, but that\u0026apos;s clearly going to\nrequire a different backport.(CVE-2026-43365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue-\u0026gt;state after sending an\nInitialization Connection Response (ICResp), but it does so without\nserializing against target-side queue teardown.\n\nIf an NVMe/TCP host sends an Initialization Connection Request\n(ICReq) and immediately closes the connection, target-side teardown\nmay start in softirq context before io_work drains the already\nbuffered ICReq. In that case, nvmet_tcp_schedule_release_queue()\nsets queue-\u0026gt;state to NVMET_TCP_Q_DISCONNECTING and drops the queue\nreference under state_lock.\n\nIf io_work later processes that ICReq, nvmet_tcp_handle_icreq() can\nstill overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the\nDISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and\nallows a later socket state change to re-enter teardown and issue a\nsecond kref_put() on an already released queue.\n\nThe ICResp send failure path has the same problem. If teardown has\nalready moved the queue to DISCONNECTING, a send error can still\noverwrite the state with NVMET_TCP_Q_FAILED, again reopening the\nwindow for a second teardown path to drop the queue reference.\n\nFix this by serializing both post-send state transitions with\nstate_lock and bailing out if teardown has already started.\n\nUse -ESHUTDOWN as an internal sentinel for that bail-out path rather\nthan propagating it as a transport error like -ECONNRESET. Keep\nnvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before\nhonoring that sentinel so receive-side parsing stays quiesced until the\nexisting release path completes.(CVE-2026-46135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()\n\ntarget_tg_pt_gp_members_show() formats LUN paths with snprintf() into a\n256-byte stack buffer, then will memcpy() cur_len bytes from that\nbuffer.  snprintf() returns the length the output would have had, which\ncan exceed the buffer size when the fabric WWN is long because iSCSI IQN\nnames can be up to 223 bytes.  The check at the memcpy() site only\nguards the destination page write, not the source read, so memcpy() will\nread past the stack buffer and copy adjacent stack contents to the sysfs\nreader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic()\nwill be triggered.\n\nCommit 27e06650a5ea (\u0026quot;scsi: target: target_core_configfs: Add length\ncheck to avoid buffer overflow\u0026quot;) added the same bound to the\ntarget_lu_gp_members_show() but the tg_pt_gp variant was missed so\nresolve that here.(CVE-2026-46149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL\n\nThe SCTP_SENDALL path in sctp_sendmsg() iterates ep-\u0026gt;asocs with\nlist_for_each_entry_safe(), which caches the next entry in @tmp before\nthe loop body runs.  The body calls sctp_sendmsg_to_asoc(), which may\ndrop the socket lock inside sctp_wait_for_sndbuf().\n\nWhile the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the\nassociation cached in @tmp, migrating it to a new endpoint via\nsctp_sock_migrate() (list_del_init() + list_add_tail() to\nnewep-\u0026gt;asocs), and optionally close the new socket which frees the\nassociation via kfree_rcu().  The cached @tmp can also be freed by a\nnetwork ABORT for that association, processed in softirq while the\nlock is dropped.\n\nsctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock\nvia the \u0026quot;sk != asoc-\u0026gt;base.sk\u0026quot; and \u0026quot;asoc-\u0026gt;base.dead\u0026quot; checks, but nothing\nrevalidates @tmp.  After a successful return, the iterator advances to\nthe stale @tmp, yielding either a use-after-free (if the peeled socket\nwas closed) or a list-walk onto the new endpoint\u0026apos;s list head (type\nconfusion of \u0026amp;newep-\u0026gt;asocs as a struct sctp_association *).\n\nBoth are reachable from CapEff=0; the type-confusion path gives\ncontrolled indirect call via the outqueue.sched-\u0026gt;init_sid pointer.\n\nFix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc()\nreturns.  @asoc is known to still be on ep-\u0026gt;asocs at that point: the\nonly callers that list_del an association from ep-\u0026gt;asocs are\nsctp_association_free() (which sets asoc-\u0026gt;base.dead) and\nsctp_assoc_migrate() (which changes asoc-\u0026gt;base.sk), and\nsctp_wait_for_sndbuf() checks both under the lock before any\nsuccessful return; a tripped check propagates as err \u0026lt; 0 and the loop\nbails before the re-derive.\n\nThe SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the\nloop hits \u0026apos;continue\u0026apos; before sctp_sendmsg_to_asoc() is ever called, so\nthe @tmp cached by list_for_each_entry_safe() still covers the\nlock-held free that ba59fb027307 (\u0026quot;sctp: walk the list of asoc\nsafely\u0026quot;) was added for.(CVE-2026-46227)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(\u0026amp;tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u0026gt; kill_fasync\n- send_sigurg() via tcp_check_urg -\u0026gt; sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(\u0026amp;tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026amp;tasklist_lock) in\n   fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n   read_lock(\u0026amp;tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -\u0026gt; SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n  \u0026amp;dev-\u0026gt;event_lock --\u0026gt; \u0026amp;f_owner-\u0026gt;lock --\u0026gt; tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n       CPU0                    CPU1\n       ----                    ----\n  lock(tasklist_lock);\n                           local_irq_disable();\n                           lock(\u0026amp;dev-\u0026gt;event_lock);\n                           lock(\u0026amp;f_owner-\u0026gt;lock);\n  \u0026lt;Interrupt\u0026gt;\n    lock(\u0026amp;dev-\u0026gt;event_lock);\n\n*** DEADLOCK ***(CVE-2026-52946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: fix deadlock in hid_post_reset()\n\nYou can build a USB device that includes a HID component\nand a storage or UAS component. The components can be reset\nonly together. That means that hid_pre_reset() and hid_post_reset()\nare in the block IO error handling. Hence no memory allocation\nused in them may do block IO because the IO can deadlock\non the mutex held while resetting a device and calling the\ninterface drivers.\nUse GFP_NOIO for all allocations in them.(CVE-2026-53037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp\n\nl2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding\nl2cap_chan_lock(). Every other l2cap_chan_del() caller in the file\nacquires the lock first. A remote BLE device can send a crafted\nL2CAP ECRED reconfiguration response to corrupt the channel list\nwhile another thread is iterating it.\n\nAdd l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),\nand l2cap_chan_unlock() and l2cap_chan_put() after, matching the\npattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().(CVE-2026-53071)",
  "id": "OESA-2026-2871",
  "modified": "2026-08-06T11:11:47Z",
  "published": "2026-07-06T11:11:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2871"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31455"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43112"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43158"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43350"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43365"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46135"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46149"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46227"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53037"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53071"
    }
  ],
  "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-31414",
    "CVE-2026-31453",
    "CVE-2026-31455",
    "CVE-2026-43112",
    "CVE-2026-43153",
    "CVE-2026-43158",
    "CVE-2026-43350",
    "CVE-2026-43365",
    "CVE-2026-46135",
    "CVE-2026-46149",
    "CVE-2026-46227",
    "CVE-2026-52946",
    "CVE-2026-53037",
    "CVE-2026-53071"
  ]
}

OESA-2026-3157 (CVE-2025-10263)

Vulnerability from osv_openeuler – Published: 2026-07-24 11:12 – Updated: 2026-08-06 11:12 – 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:

smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)

In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.

I actually just hit the case using rxe:

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

MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits

Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the __read_mostly section.

This corruption was observed because the variable __cpu_primary_thread_mask was corrupted, causing a hang very early during boot.

This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insn_la_mcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)

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

riscv: Sanitize syscall table indexing under speculation

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

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the no_hw_access flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smp_mb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)

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

btrfs: reject new transactions if the fs is fully read-only

[BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:

BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>

Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.

But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.

[CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.

However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.

[FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.(CVE-2026-23214)

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

nvme-fc: release admin tagset if init fails

nvme_fabrics creates an NVMe/FC controller in following path:

nvmf_dev_write()
  -&gt; nvmf_create_ctrl()
    -&gt; nvme_fc_create_ctrl()
      -&gt; nvme_fc_init_ctrl()

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

netfilter: nf_conntrack_expect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

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

ksmbd: fix OOB write in QUERY_INFO for compound requests

The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs.

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

dmaengine: idxd: Fix leaking event log memory

Do not check if the support was enabled, the check for 'idxd->evl' being valid (only allocated if the HW capability is available) is enough.(CVE-2026-31440)

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

dmaengine: idxd: Fix crash when the event log is disabled

Also, only try to free the event log if it was properly allocated.(CVE-2026-31443)

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

xfs: avoid dereferencing log items after push callbacks

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

ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()

When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.

This results in the following warning splat:

WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608 [...] RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395) [...] Call Trace: <TASK> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989) netlink_rcv_skb (net/netlink/af_netlink.c:2550) netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) netlink_sendmsg (net/netlink/af_netlink.c:1894) ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585) ___sys_sendmsg (net/socket.c:2641) __sys_sendmsg (net/socket.c:2671) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK>

Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too.

This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:

addattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)

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

wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.

syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]

The problem is that aql_enable_write() does not serialise concurrent write()s to the debugfs.

aql_enable_write() checks static_key_false(&aql_disable.key) and later calls static_branch_inc() or static_branch_dec(), but the state may change between the two calls.

aql_disable does not need to track inc/dec.

Let's use static_branch_enable() and static_branch_disable().

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

nvmet: move async event work off nvmet-wq

For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmet_execute_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)

nvmet_add_async_event() queue_work(nvmet_wq, &ctrl->async_event_work)

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N

kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.(CVE-2026-31557)

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

bcache: fix cached_dev.sb_bio use-after-free and crash

In our production environment, we have received multiple crash reports regarding libceph, which have caught our attention:

[6888366.280350] Call Trace:
[6888366.280452]  blk_update_request+0x14e/0x370
[6888366.280561]  blk_mq_end_request+0x1a/0x130
[6888366.280671]  rbd_img_handle_request+0x1a0/0x1b0 [rbd]
[6888366.280792]  rbd_obj_handle_request+0x32/0x40 [rbd]
[6888366.280903]  __complete_request+0x22/0x70 [libceph]
[6888366.281032]  osd_dispatch+0x15e/0xb40 [libceph]
[6888366.281164]  ? inet_recvmsg+0x5b/0xd0
[6888366.281272]  ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]
[6888366.281405]  ceph_con_process_message+0x79/0x140 [libceph]
[6888366.281534]  ceph_con_v1_try_read+0x5d7/0xf30 [libceph]
[6888366.281661]  ceph_con_workfn+0x329/0x680 [libceph]

After analyzing the coredump file, we found that the address of dc->sb_bio has been freed. We know that cached_dev is only freed when it is stopped.

Since sb_bio is a part of struct cached_dev, rather than an alloc every time. If the device is stopped while writing to the superblock, the released address will be accessed at endio.

This patch hopes to wait for sb_write to complete in cached_dev_free.

It should be noted that we analyzed the cause of the problem, then tell all details to the QWEN and adopted the modifications it made.(CVE-2026-31580)

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

KVM: x86: Use scratch field in MMIO fragment to hold small write values

When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value.

This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, and both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable.

The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data.

================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984

CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720

The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================

The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage.

Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---(CVE-2026-31588)

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

tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG

The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.(CVE-2026-31662)

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

xfrm: clear trailing padding in build_polexpire()

Add the missing memset_after() call, matching build_expire().(CVE-2026-31664)

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

netfilter: xt_multiport: validate range encoding in checkentry

ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end.

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

ksmbd: validate owner of durable handle on reconnect

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

usb: gadget: f_ecm: Fix net_device lifecycle with device_move

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

usb: ulpi: fix double free in ulpi_register_interface() error path

When device_register() fails, ulpi_register() calls put_device() on ulpi->dev.

The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free.

Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)