Vulnerability-Lookup

CVE-2025-68183 (GCVE-0-2025-68183)

Vulnerability from cvelistv5 – Published: 2025-12-16 13:43 – Updated: 2026-08-05 12:10

Title

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

Summary

In the Linux kernel, the following vulnerability has been resolved: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include <stdio.h> #include <sys/xattr.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdlib.h> int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; }

Severity

7.8 (High)


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

Assigner

Linux mitre root Scorecard

References

4 references

URL	Tags
https://git.kernel.org/stable/c/d2993a7e98eb70c73…
https://git.kernel.org/stable/c/edd824eb45e4f7e05…
https://git.kernel.org/stable/c/02aa671c08a4834be…
https://git.kernel.org/stable/c/88b4cbcf6b041ae0f…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: e3ccfe1ad7d895487977ef64eda3441d16c9851a , < d2993a7e98eb70c737c6f5365a190e79c72b8407 (git) Affected: e3ccfe1ad7d895487977ef64eda3441d16c9851a , < edd824eb45e4f7e05ad3ab090dab6dbdb79cd292 (git) Affected: e3ccfe1ad7d895487977ef64eda3441d16c9851a , < 02aa671c08a4834bef5166743a7b88686fbfa023 (git) Affected: e3ccfe1ad7d895487977ef64eda3441d16c9851a , < 88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd (git)	guessed
Linux	Linux	Affected: 5.14 Unaffected: 0 , < 5.14 (semver) Unaffected: 6.6.117 , ≤ 6.6.* (semver) Unaffected: 6.12.58 , ≤ 6.12.* (semver) Unaffected: 6.17.8 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "security/integrity/ima/ima_appraise.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d2993a7e98eb70c737c6f5365a190e79c72b8407",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            },
            {
              "lessThan": "edd824eb45e4f7e05ad3ab090dab6dbdb79cd292",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            },
            {
              "lessThan": "02aa671c08a4834bef5166743a7b88686fbfa023",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            },
            {
              "lessThan": "88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "security/integrity/ima/ima_appraise.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.14"
            },
            {
              "lessThan": "5.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.117",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.58",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.17.*",
              "status": "unaffected",
              "version": "6.17.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.18",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.117",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.58",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.17.8",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18",
                  "versionStartIncluding": "5.14",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nima: don\u0027t clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with \"ima_appraise=fix\nevm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere\u0027s a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include \u003cstdio.h\u003e\n    #include \u003csys/xattr.h\u003e\n    #include \u003cfcntl.h\u003e\n    #include \u003cunistd.h\u003e\n    #include \u003cstring.h\u003e\n    #include \u003cstdlib.h\u003e\n\n    int main() {\n        const char* file_path = \"/usr/sbin/test_binary\";\n        const char* hex_string = \"030204d33204490066306402304\";\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror(\"Error opening file\");\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i \u003c length; i += 2, j++) {\n            sscanf(hex_string + i, \"%2hhx\", \u0026ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= \"system_u:object_r:bin_t:s0\";\n        if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - Triggering requires local syscalls against a file on the system \u2014 `setxattr`/`fsetxattr` on an EVM-protected xattr, `setfacl`, or `fremovexattr` \u2014 followed by an open/close of the target file. No network, adjacent-network, or physical path reaches the IMA appraisal hooks.\nAC:L - The commit ships a deterministic reproducer: setting any EVM-protected xattr or a POSIX ACL unconditionally clears IMA_DIGSIG every time, with no memory-layout or timing luck involved. The enforce-mode variant needs a race against `process_measurement()`\u0027s `MAY_WRITE` check, but `ima_reset_appraise_flags()` takes no `iint-\u003emutex`, and the attacker drives both sides (one thread spinning on `setxattr(\"system.posix_acl_access\")`, another on `open(O_WRONLY)`); the required IMA-appraise + EVM configuration is a shipped, supported Fedora/RHEL setup, not a rare build option.\nPR:L - `vfs_set_acl()` invokes `security_inode_set_acl()` \u2192 `ima_inode_set_acl()` \u2192 `ima_reset_appraise_flags(inode, 0)` before `set_posix_acl()` ever reaches its `inode_owner_or_capable()` check, so an unprivileged user with no capabilities and no ownership of the file clears the cached IMA_DIGSIG bit on any signed appraised binary \u2014 the syscall fails with -EPERM only after the flag is already gone. No CAP_SYS_ADMIN is needed for this path, unlike the `security.ima` path guarded by `ima_protect_xattr()`.\nUI:N - The attacker performs the xattr/ACL operation and the file open/close entirely from their own process; no victim must mount a filesystem, open a file, or take any other action for the IMA_DIGSIG flag to be cleared and the signature to be replaced.\nS:U - The defeated control (IMA appraisal) and the affected resources (files and their security xattrs) live in the same kernel security authority; no VM, hypervisor, IOMMU, or sandbox boundary is crossed.\nC:H - Clearing IMA_DIGSIG both drops the \"signed files cannot be opened for write\" enforcement at `ima_main.c:472` and lets `ima_update_xattr()` re-bless the modified content with a fresh hash plus EVM HMAC, so attacker-substituted content in an appraised executable passes appraisal and subsequently runs \u2014 typically in a privileged/service context \u2014 yielding full disclosure of data reachable by that code. This is the standard treatment of a code-integrity/signature-verification bypass; the bug itself contains no direct memory-read primitive.\nI:H - The file\u0027s IMA digital signature \u2014 the one integrity artifact a local attacker cannot forge, since it is verified against the trusted IMA keyring \u2014 is silently destroyed and replaced by a locally computed hash written through `__vfs_setxattr_noperm()`, which bypasses the `CAP_SYS_ADMIN` gate in `ima_protect_xattr()`. Combined with the lost write-block, this converts \"signed and immutable\" into \"mutable and re-blessed on close\", a complete integrity bypass of IMA appraisal for the affected file.\nA:H - Once a signature is replaced by a plain hash, any policy carrying IMA_DIGSIG_REQUIRED (`appraise_type=imasig`) rejects that file in enforce mode, so appraised binaries become permanently unexecutable \u2014 applied to system-critical files such as init, sshd, or libc consumers this denies service and can leave the system unbootable, and the corrupted xattr persists on disk until the file is re-signed out of band."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:10:06.378Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/d2993a7e98eb70c737c6f5365a190e79c72b8407"
        },
        {
          "url": "https://git.kernel.org/stable/c/edd824eb45e4f7e05ad3ab090dab6dbdb79cd292"
        },
        {
          "url": "https://git.kernel.org/stable/c/02aa671c08a4834bef5166743a7b88686fbfa023"
        },
        {
          "url": "https://git.kernel.org/stable/c/88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd"
        }
      ],
      "title": "ima: don\u0027t clear IMA_DIGSIG flag when setting or removing non-IMA xattr",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-68183",
    "datePublished": "2025-12-16T13:43:01.178Z",
    "dateReserved": "2025-12-16T13:41:40.252Z",
    "dateUpdated": "2026-08-05T12:10:06.378Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-68183",
      "date": "2026-10-02",
      "epss": "0.00154",
      "percentile": "0.03916"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "security/integrity/ima/ima_appraise.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "d2993a7e98eb70c737c6f5365a190e79c72b8407",
                    "status": "affected",
                    "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "edd824eb45e4f7e05ad3ab090dab6dbdb79cd292",
                    "status": "affected",
                    "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "02aa671c08a4834bef5166743a7b88686fbfa023",
                    "status": "affected",
                    "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd",
                    "status": "affected",
                    "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "security/integrity/ima/ima_appraise.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "5.14"
                  },
                  {
                    "lessThan": "5.14",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.117",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.58",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.17.*",
                    "status": "unaffected",
                    "version": "6.17.8",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.18",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nima: don\u0027t clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with \"ima_appraise=fix\nevm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere\u0027s a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include \u003cstdio.h\u003e\n    #include \u003csys/xattr.h\u003e\n    #include \u003cfcntl.h\u003e\n    #include \u003cunistd.h\u003e\n    #include \u003cstring.h\u003e\n    #include \u003cstdlib.h\u003e\n\n    int main() {\n        const char* file_path = \"/usr/sbin/test_binary\";\n        const char* hex_string = \"030204d33204490066306402304\";\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror(\"Error opening file\");\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i \u003c length; i += 2, j++) {\n            sscanf(hex_string + i, \"%2hhx\", \u0026ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= \"system_u:object_r:bin_t:s0\";\n        if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }"
          }
        ],
        "id": "CVE-2025-68183",
        "lastModified": "2026-07-30T06:24:32.637",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2025-12-16T14:15:50.880",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/02aa671c08a4834bef5166743a7b88686fbfa023"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/d2993a7e98eb70c737c6f5365a190e79c72b8407"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/edd824eb45e4f7e05ad3ab090dab6dbdb79cd292"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Deferred"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-30T08:22:46+00:00",
      "cve": "CVE-2025-68183",
      "id": "CVE-2025-68183",
      "initial_release_date": "2025-12-16T00:00:00+00:00",
      "product_status:fixed": "1980",
      "product_status:known_affected": "33",
      "product_status:known_not_affected": "31",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: ima: don\u0027t clear IMA_DIGSIG flag when setting or removing non-IMA xattr",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-68183.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-23T23:51:10Z",
      "cve": "CVE-2025-68183",
      "id": "CVE-2025-68183",
      "initial_release_date": "2025-12-17T00:26:04Z",
      "product_status:first_fixed": "2",
      "product_status:known_affected": "354",
      "product_status:known_not_affected": "352",
      "product_status:recommended": "685",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2025-68183",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-68183.json",
      "version": "50"
    }
  }
}

CERTFR-2026-AVI-0986

Vulnerability from certfr_avis - Published: 2026-08-07 - Updated: 2026-08-07

De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.

Solutions

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

Impacted products

Vendor	Product	Description
IBM	WebSphere	WebSphere Application Server version 9.0 avec IBM SDK, Java Technology Edition versions antérieures à 8 Service Refresh 8 FP70
IBM	QRadar	QRadar SIEM versions 7.5.x antérieures à 7.5.0 UP15 IF05 Hotfix 20260715231428
IBM	WebSphere	WebSphere Application Server version 8.5 avec IBM SDK, Java Technology Edition versions antérieures à 8 Service Refresh 8 FP70
IBM	Informix Dynamic Server	Informix Dynamic Server versions 15.0.x antérieures à 15.0.1.14
IBM	QRadar	QRadar SIEM versions 7.6.x antérieures à 7.6.0.2
IBM	WebSphere	WebSphere Automation versions 1.12.x antérieures à 1.13.0
IBM	Sterling	Sterling Control Center versions 6.4.2.0 antérieures à 6.4.2.0 iFix06
IBM	Db2	Db2 Bridge versions antérieures à 1.1.5.1
IBM	Informix Dynamic Server	Informix Dynamic Server versions 14.10.x antérieures à 14.10.xC13W13
IBM	WebSphere	WebSphere Hybrid Edition versions 5.1 sans les derniers correctifs de sécurité
IBM	WebSphere	WebSphere Application Server - Liberty avec IBM SDK, Java Technology Edition versions antérieures à 8 SR8 FP70
IBM	Tivoli	Tivoli Composite Application Manager for Application Diagnostics version 7.1.0 sans les derniers correctifs de sécurité
IBM	Sterling	Sterling B2B Integrator et IBM Sterling File Gateway versions 6.2.2.x antérieures à B2Bi 6.2.2.1
IBM	WebSphere	WebSphere Service Registry and Repository version 8.5 sans les derniers correctifs de sécurité
IBM	Sterling	Sterling Order Management version 10.0.2604.2 sans le dernier correctif de sécurité
IBM	Db2	Db2 Developer Extension versions 1.1.x antérieures à 1.1.2
IBM	Sterling	Sterling Control Center versions 6.3.1.0 antérieures à 6.3.1.0 iFix10

References

Title

Publication Time

ESSA-2026:0165

Vulnerability from csaf_opensuse - Published: 2026-08-28 01:47 - Updated: 2026-09-16 18:11

Summary

Important: kernel security, bug fix, and enhancement update

Severity

Moderate

Scope

9 vulnerabilities in this advisory, including CVE-2025-68183.

CVE-2025-68183

6.1 (Medium)


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

Recommended: 43 products

Open the full advisory

OPENSUSE-SU-2026:20145-1

Vulnerability from csaf_opensuse - Published: 2026-02-02 11:54 - Updated: 2026-09-30 15:57

Summary

Security update for the Linux Kernel

Severity

Important

Scope

215 vulnerabilities in this advisory, including CVE-2025-68183.

CVE-2025-68183

6.1 (Medium)


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

Recommended: 136 products

Open the full advisory

RHSA-2026:21556

Vulnerability from csaf_opensuse - Published: 2026-05-28 02:41 - Updated: 2026-09-28 16:43

Summary

Red Hat Security Advisory: kernel security update

Severity

Important

Scope

20 vulnerabilities in this advisory, including CVE-2025-68183.

CVE-2025-68183

7.1 (High)


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

Fixed: 303 products

https://access.redhat.com/errata/RHSA-2026:21556

Open the full advisory

RHSA-2026:21557

Vulnerability from csaf_opensuse - Published: 2026-05-28 02:21 - Updated: 2026-10-02 04:30

Summary

Red Hat Security Advisory: kernel security update

Severity

Important

Scope

18 vulnerabilities in this advisory, including CVE-2025-68183.

CVE-2025-68183

7.1 (High)


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

Fixed: 309 products

https://access.redhat.com/errata/RHSA-2026:21557

Open the full advisory

RHSA-2026:21706

Vulnerability from csaf_opensuse - Published: 2026-05-28 08:47 - Updated: 2026-09-24 21:50

Summary

Red Hat Security Advisory: kernel security update

Severity

Important

Scope

19 vulnerabilities in this advisory, including CVE-2025-68183.

CVE-2025-68183

7.1 (High)


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

Fixed: 120 products

https://access.redhat.com/errata/RHSA-2026:21706

Open the full advisory

FKIE_CVE-2025-68183

Vulnerability from fkie_nvd - Published: 2025-12-16 14:15 - Updated: 2026-07-30 06:24

Severity

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

Summary

References

	URL	Tags
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/02aa671c08a4834bef5166743a7b88686fbfa023
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/d2993a7e98eb70c737c6f5365a190e79c72b8407
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/edd824eb45e4f7e05ad3ab090dab6dbdb79cd292

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "security/integrity/ima/ima_appraise.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "d2993a7e98eb70c737c6f5365a190e79c72b8407",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            },
            {
              "lessThan": "edd824eb45e4f7e05ad3ab090dab6dbdb79cd292",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            },
            {
              "lessThan": "02aa671c08a4834bef5166743a7b88686fbfa023",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            },
            {
              "lessThan": "88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd",
              "status": "affected",
              "version": "e3ccfe1ad7d895487977ef64eda3441d16c9851a",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "security/integrity/ima/ima_appraise.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.14"
            },
            {
              "lessThan": "5.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.117",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.58",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.17.*",
              "status": "unaffected",
              "version": "6.17.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.18",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nima: don\u0027t clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with \"ima_appraise=fix\nevm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere\u0027s a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include \u003cstdio.h\u003e\n    #include \u003csys/xattr.h\u003e\n    #include \u003cfcntl.h\u003e\n    #include \u003cunistd.h\u003e\n    #include \u003cstring.h\u003e\n    #include \u003cstdlib.h\u003e\n\n    int main() {\n        const char* file_path = \"/usr/sbin/test_binary\";\n        const char* hex_string = \"030204d33204490066306402304\";\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror(\"Error opening file\");\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i \u003c length; i += 2, j++) {\n            sscanf(hex_string + i, \"%2hhx\", \u0026ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= \"system_u:object_r:bin_t:s0\";\n        if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }"
    }
  ],
  "id": "CVE-2025-68183",
  "lastModified": "2026-07-30T06:24:32.637",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2025-12-16T14:15:50.880",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/02aa671c08a4834bef5166743a7b88686fbfa023"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d2993a7e98eb70c737c6f5365a190e79c72b8407"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/edd824eb45e4f7e05ad3ab090dab6dbdb79cd292"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Deferred"
}

GHSA-W26Q-X7H4-9GC5

Vulnerability from github – Published: 2025-12-16 15:30 – Updated: 2026-07-30 06:32

Details

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

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file.

For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated,

# getfattr -m - -d -e hex /usr/bin/bash
# file: usr/bin/bash
security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed.

Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL,

#include <stdio.h>
#include <sys/xattr.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>

int main() {
    const char* file_path = "/usr/sbin/test_binary";
    const char* hex_string = "030204d33204490066306402304";
    int length = strlen(hex_string);
    char* ima_attr_value;
    int fd;

    fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
    if (fd == -1) {
        perror("Error opening file");
        return 1;
    }

    ima_attr_value = (char*)malloc(length / 2 );
    for (int i = 0, j = 0; i < length; i += 2, j++) {
        sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);
    }

    if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {
        perror("Error setting extended attribute");
        close(fd);
        return 1;
    }

    const char* selinux_value= "system_u:object_r:bin_t:s0";
    if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {
        perror("Error setting extended attribute");
        close(fd);
        return 1;
    }

    close(fd);

    return 0;
}

Severity

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-68183"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T14:15:50Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nima: don\u0027t clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with \"ima_appraise=fix\nevm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere\u0027s a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include \u003cstdio.h\u003e\n    #include \u003csys/xattr.h\u003e\n    #include \u003cfcntl.h\u003e\n    #include \u003cunistd.h\u003e\n    #include \u003cstring.h\u003e\n    #include \u003cstdlib.h\u003e\n\n    int main() {\n        const char* file_path = \"/usr/sbin/test_binary\";\n        const char* hex_string = \"030204d33204490066306402304\";\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror(\"Error opening file\");\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i \u003c length; i += 2, j++) {\n            sscanf(hex_string + i, \"%2hhx\", \u0026ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= \"system_u:object_r:bin_t:s0\";\n        if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) {\n            perror(\"Error setting extended attribute\");\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }",
  "id": "GHSA-w26q-x7h4-9gc5",
  "modified": "2026-07-30T06:32:24Z",
  "published": "2025-12-16T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68183"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/02aa671c08a4834bef5166743a7b88686fbfa023"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d2993a7e98eb70c737c6f5365a190e79c72b8407"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/edd824eb45e4f7e05ad3ab090dab6dbdb79cd292"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

OESA-2026-2675 (CVE-2025-38389)

Vulnerability from osv_openeuler – Published: 2026-06-12 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:

drm/i915/gt: Fix timeline left held on VMA alloc error

The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform:

<4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]---

If the test also unloads the i915 module then that's followed with:

<3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ...

Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt.

All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular.

If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error.

In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind.

Get the legacy timeline only after successful allocation of the context engine's VMA.

v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.

(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)(CVE-2025-38389)

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

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

# getfattr -m - -d -e hex /usr/bin/bash
# file: usr/bin/bash
security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed.

Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL,

#include &lt;stdio.h&gt;
#include &lt;sys/xattr.h&gt;
#include &lt;fcntl.h&gt;
#include &lt;unistd.h&gt;
#include &lt;string.h&gt;
#include &lt;stdlib.h&gt;

int main() {
    const char* file_path = &quot;/usr/sbin/test_binary&quot;;
    const char* hex_string = &quot;030204d33204490066306402304&quot;;
    int length = strlen(hex_string);
    char* ima_attr_value;
    int fd;

    fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
    if (fd == -1) {
        perror(&quot;Error opening file&quot;);
        return 1;
    }

    ima_attr_value = (char*)malloc(length / 2 );
    for (int i = 0, j = 0; i &lt; length; i += 2, j++) {
        sscanf(hex_string + i, &quot;%2hhx&quot;, &amp;ima_attr_value[j]);
    }

    if (fsetxattr(fd, &quot;security.ima&quot;, ima_attr_value, length/2, 0) == -1) {
        perror(&quot;Error setting extended attribute&quot;);
        close(fd);
        return 1;
    }

    const char* selinux_value= &quot;system_u:object_r:bin_t:s0&quot;;
    if (fsetxattr(fd, &quot;security.selinux&quot;, selinux_value, strlen(selinux_value), 0) == -1) {
        perror(&quot;Error setting extended attribute&quot;);
        close(fd);
        return 1;
    }

    close(fd);

    return 0;
}(CVE-2025-68183)

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

crash: fix crashkernel resource shrink

When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues:

Invalid crashkernel resource objects
Kernel crash if crashkernel shrinking is done twice

For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as:

cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel

If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel

Instead, it should show 50MB: af000000-b21fffff : Crash kernel

Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86):

BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI <snip...> Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 <snip...>

This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated.

Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.(CVE-2025-68198)

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

ipvs: fix ipv4 null-ptr-deref in route error path

The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure() without ensuring skb->dev is set, leading to a NULL pointer dereference in fib_compute_spec_dst() when ipv4_link_failure() attempts to send ICMP destination unreachable messages.

The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure") started calling __ip_options_compile() from ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst() which dereferences skb->dev. An attempt was made to fix the NULL skb->dev dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in ipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev) dereference by using a fallback device. The fix was incomplete because fib_compute_spec_dst() later in the call chain still accesses skb->dev directly, which remains NULL when IPVS calls dst_link_failure().

The crash occurs when: 1. IPVS processes a packet in NAT mode with a misconfigured destination 2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route 3. The error path calls dst_link_failure(skb) with skb->dev == NULL 4. ipv4_link_failure() → ipv4_send_dest_unreach() → __ip_options_compile() → fib_compute_spec_dst() 5. fib_compute_spec_dst() dereferences NULL skb->dev

Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix ipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev before calling dst_link_failure().

KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f] CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2 RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233 RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285 Call Trace: <TASK> spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764(CVE-2025-68813)

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

ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()

There exists a kernel oops caused by a BUG_ON(nhead < 0) at net/core/skbuff.c:2232 in pskb_expand_head(). This bug is triggered as part of the calipso_skbuff_setattr() routine when skb_cow() is passed headroom > INT_MAX (i.e. (int)(skb_headroom(skb) + len_delta) < 0).

The root cause of the bug is due to an implicit integer cast in __skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure that delta = headroom - skb_headroom(skb) is never negative, otherwise we will trigger a BUG_ON in pskb_expand_head(). However, if headroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta becomes negative, and pskb_expand_head() is passed a negative value for nhead.

Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing "negative" headroom sizes to skb_cow() within calipso_skbuff_setattr() by only using skb_cow() to grow headroom.

PoC: Using netlabelctl tool:

    netlabelctl map del default
    netlabelctl calipso add pass doi:7
    netlabelctl map add default address:0::1/128 protocol:calipso,7

    Then run the following PoC:

    int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);

    // setup msghdr
    int cmsg_size = 2;
    int cmsg_len = 0x60;
    struct msghdr msg;
    struct sockaddr_in6 dest_addr;
    struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,
                    sizeof(struct cmsghdr) + cmsg_len);
    msg.msg_name = &amp;dest_addr;
    msg.msg_namelen = sizeof(dest_addr);
    msg.msg_iov = NULL;
    msg.msg_iovlen = 0;
    msg.msg_control = cmsg;
    msg.msg_controllen = cmsg_len;
    msg.msg_flags = 0;

    // setup sockaddr
    dest_addr.sin6_family = AF_INET6;
    dest_addr.sin6_port = htons(31337);
    dest_addr.sin6_flowinfo = htonl(31337);
    dest_addr.sin6_addr = in6addr_loopback;
    dest_addr.sin6_scope_id = 31337;

    // setup cmsghdr
    cmsg-&gt;cmsg_len = cmsg_len;
    cmsg-&gt;cmsg_level = IPPROTO_IPV6;
    cmsg-&gt;cmsg_type = IPV6_HOPOPTS;
    char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);
    hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80

    sendmsg(fd, &amp;msg, 0);(CVE-2025-71085)

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

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

usbip: validate number_of_packets in usbip_pack_ret_submit()

When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the original number_of_packets from the CMD_SUBMIT.

A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets.

This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit.

Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.(CVE-2026-31607)

In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)

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

netfilter: nf_tables: reject immediate NF_QUEUE verdict

nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.(CVE-2026-43024)

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

ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()

Sashiko AI-review observed:

In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao.

Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info?

Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.(CVE-2026-43038)

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

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260

There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB!

Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.(CVE-2026-43071)

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

net: af_key: zero aligned sockaddr tail in PF_KEY exports

PF_KEY export paths use pfkey_sockaddr_size() when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, pfkey_sockaddr_fill() initializes only the first 28 bytes of struct sockaddr_in6, leaving the final 4 aligned bytes uninitialized.

Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain skb_put():

SADB_ACQUIRE
SADB_X_NAT_T_NEW_MAPPING
SADB_X_MIGRATE

Fix those paths by clearing only the aligned sockaddr tail after pfkey_sockaddr_fill().(CVE-2026-43088)

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

xfrm_user: fix info leak in build_mapping()

struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.(CVE-2026-43089)

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

xfrm: account XFRMA_IF_ID in aevent size calculation

xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set.

xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.(CVE-2026-43107)

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

tcp: fix potential race in tcp_v6_syn_recv_sock()

Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late.

After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it.

Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.

Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion.

This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.(CVE-2026-43198)

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

net: Drop the lock in skb_may_tx_timestamp()

skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU.

Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed.

Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)

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

vhost: move vdpa group bound check to vhost_vdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)

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

mm/page_alloc: clear page->private in free_pages_prepare()

Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values.

This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash:

KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860

Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.(CVE-2026-43303)

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

scsi: hisi_sas: Fix NULL pointer exception during user_scan()

user_scan() invokes updated sas_user_scan() for channel 0, and if successful, iteratively scans remaining channels (1 to shost->max_channel) via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans"). However, hisi_sas supports only one channel, and the current value of max_channel is 1. sas_user_scan() for channel 1 will trigger the following NULL pointer exception:

[ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0 [ 441.554699] Mem abort info: [ 441.554710] ESR = 0x0000000096000004 [ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits [ 441.554723] SET = 0, FnV = 0 [ 441.554726] EA = 0, S1PTW = 0 [ 441.554730] FSC = 0x04: level 0 translation fault [ 441.554735] Data abort info: [ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000 [ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000 [ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP [ 441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod [ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT [ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 441.698277] pc : sas_find_dev_by_rphy+0x44/0x118 [ 441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118 [ 441.707502] sp : ffff80009abbba40 [ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08 [ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00 [ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000 [ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020 [ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff [ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a [ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4 [ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030 [ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000 [ 441.782053] Call trace: [ 441.784488] sas_find_dev_by_rphy+0x44/0x118 (P) [ 441.789095] sas_target_alloc+0x24/0xb0 [ 441.792920] scsi_alloc_target+0x290/0x330 [ 441.797010] __scsi_scan_target+0x88/0x258 [ 441.801096] scsi_scan_channel+0x74/0xb8 [ 441.805008] scsi_scan_host_selected+0x170/0x188 [ 441.809615] sas_user_scan+0xfc/0x148 [ 441.813267] store_scan+0x10c/0x180 [ 441.816743] dev_attr_store+0x20/0x40 [ 441.820398] sysfs_kf_write+0x84/0xa8 [ 441.824054] kernfs_fop_write_iter+0x130/0x1c8 [ 441.828487] vfs_write+0x2c0/0x370 [ 441.831880] ksys_write+0x74/0x118 [ 441.835271] __arm64_sys_write+0x24/0x38 [ 441.839182] invoke_syscall+0x50/0x120 [ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0 [ 441.847611] do_el0_svc+0x24/0x38 [ 441.850913] el0_svc+0x38/0x158 [ 441.854043] el0t_64_sync_handler+0xa0/0xe8 [ 441.858214] el0t_64_sync+0x1ac/0x1b0 [ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75) [ 441.867946] ---[ end trace 0000000000000000 ]---

Therefore ---truncated---(CVE-2026-43413)

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

ipvs: skip ipv6 extension headers for csum checks

Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.(CVE-2026-45850)

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

net: hns3: fix double free issue for tx spare buffer

In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory.

Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory.

The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer.

Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new tx_spare fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.(CVE-2026-45891)

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

Clear only the 'Present' (P) bit of the PASID entry.
Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)

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

quota: fix livelock between quotactl and freeze_super

When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze.

However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled.

The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync.

This results in a hang of the freezer process and 100% CPU usage by the quota process.

While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:

# mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount # mount /dev/sda -o quota,usrquota,grpquota a_mount # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \ xfs_freeze -u a_mount; done" & # taskset -c 3 bash -c "while true; do quotaon a_mount; \ quotaoff a_mount; done" &

Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete.(CVE-2026-45895)

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

fat: avoid parent link count underflow in rmdir

Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink().

Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)

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

sched/rt: Skip currently executing CPU in rto_next_cpu()

CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed).

However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.

The trigging scenario is as follows:

     cpu0                      cpu1                    cpu2
                            pull_rt_task
                          tell_cpu_to_push
             &lt;------------irq_work_queue_on

rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func

Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)

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

ext4: fix dirtyclusters double decrement on fs shutdown

fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count:

WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]

Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks().

First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.

To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.(CVE-2026-45920)

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

ext4: fix e4b bitmap inconsistency reports

A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:

ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks

Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice:

folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock

The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window.

Additionally, this change addresses the following issues:

When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered:

corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc

Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:

ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock

The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.(CVE-2026-45942)

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

iommu/vt-d: Clear Present bit before tearing down context entry

When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.

While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
Fully zero out the entry only after the invalidation is complete.

Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)

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

ext4: fix memory leak in ext4_ext_shift_extents()

In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak.

Fix this by jumping to the out label to ensure the path is properly released.(CVE-2026-45948)

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

cpuidle: Skip governor when only one idle state is available

On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash.

[ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668

Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.(CVE-2026-45968)

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

ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O

When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues.

Assume we have an unwritten extent, and then DIO writes the second half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range

First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set.

Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.

[0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree

Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.

Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.(CVE-2026-45985)

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

KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT

If loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nested_svm_vmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.

From the APM:

Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:

...

if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN

Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway.(CVE-2026-46032)

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

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.(CVE-2026-46065)

In the Linux kernel, the vlan_dev_set_egress_priority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)

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

eventpoll: fix ep_remove struct eventpoll / struct file UAF

ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free().

For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory.

In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache.

Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs.

If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there.

A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.(CVE-2026-46242)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dc_link NULL handling in HPD init amdgpu_dm_hpd_init() may see connectors without a valid dc_link. The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts. Assign dc_link early and skip connectors where it is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed 'dc_link' could be null (see line 931) drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c 923 / 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 / 927 use_polling |= 928 amdgpu_dm_connector->dc_link && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id); 930 931 dc_link = amdgpu_dm_connector->dc_link; dc_link assigned here. 932 933 / 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on 937 * hpd_rx isn't available. DM currently controls hpd_rx 938 * explicitly with dc_interrupt_set() 939 / --> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1; 942 /* 943 * TODO: There's a mismatch between mode_info.num_hpd 944 * and what bios reports as the # of connectors with hpd The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)

In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)

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-38389	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68183	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68198	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68813	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71085	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31527	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31607	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31709	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43024	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43038	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43071	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43088	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43089	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43107	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43198	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43216	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43248	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43303	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43413	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45850	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45891	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45894	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45895	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45915	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45919	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45920	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45942	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45944	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45948	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45968	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45985	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46032	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46065	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46153	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46242	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46245	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46259	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-devel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-headers-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-source-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-tools-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "perf-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "python3-perf-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.1.15.153.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-devel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-headers-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-source-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-tools-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "perf-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "python3-perf-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.1.15.153.oe2403sp1"
            }
          ],
          "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\ndrm/i915/gt: Fix timeline left held on VMA alloc error\n\nThe following error has been reported sporadically by CI when a test\nunbinds the i915 driver on a ring submission platform:\n\n\u0026lt;4\u0026gt; [239.330153] ------------[ cut here ]------------\n\u0026lt;4\u0026gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-\u0026gt;mm.shrink_count)\n\u0026lt;4\u0026gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n\u0026lt;4\u0026gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n\u0026lt;4\u0026gt; [239.330942] Call Trace:\n\u0026lt;4\u0026gt; [239.330944]  \u0026lt;TASK\u0026gt;\n\u0026lt;4\u0026gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]\n\u0026lt;4\u0026gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]\n\u0026lt;4\u0026gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90\n\u0026lt;4\u0026gt; [239.331494]  devm_action_release+0x15/0x30\n\u0026lt;4\u0026gt; [239.331504]  release_nodes+0x3d/0x120\n\u0026lt;4\u0026gt; [239.331517]  devres_release_all+0x96/0xd0\n\u0026lt;4\u0026gt; [239.331533]  device_unbind_cleanup+0x12/0x80\n\u0026lt;4\u0026gt; [239.331543]  device_release_driver_internal+0x23a/0x280\n\u0026lt;4\u0026gt; [239.331550]  ? bus_find_device+0xa5/0xe0\n\u0026lt;4\u0026gt; [239.331563]  device_driver_detach+0x14/0x20\n...\n\u0026lt;4\u0026gt; [357.719679] ---[ end trace 0000000000000000 ]---\n\nIf the test also unloads the i915 module then that\u0026apos;s followed with:\n\n\u0026lt;3\u0026gt; [357.787478] =============================================================================\n\u0026lt;3\u0026gt; [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()\n\u0026lt;3\u0026gt; [357.788031] -----------------------------------------------------------------------------\n\u0026lt;3\u0026gt; [357.788204] Object 0xffff888109e7f480 @offset=29824\n\u0026lt;3\u0026gt; [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244\n\u0026lt;4\u0026gt; [357.788994]  i915_vma_instance+0xee/0xc10 [i915]\n\u0026lt;4\u0026gt; [357.789290]  init_status_page+0x7b/0x420 [i915]\n\u0026lt;4\u0026gt; [357.789532]  intel_engines_init+0x1d8/0x980 [i915]\n\u0026lt;4\u0026gt; [357.789772]  intel_gt_init+0x175/0x450 [i915]\n\u0026lt;4\u0026gt; [357.790014]  i915_gem_init+0x113/0x340 [i915]\n\u0026lt;4\u0026gt; [357.790281]  i915_driver_probe+0x847/0xed0 [i915]\n\u0026lt;4\u0026gt; [357.790504]  i915_pci_probe+0xe6/0x220 [i915]\n...\n\nCloser analysis of CI results history has revealed a dependency of the\nerror on a few IGT tests, namely:\n- igt@api_intel_allocator@fork-simple-stress-signal,\n- igt@api_intel_allocator@two-level-inception-interruptible,\n- igt@gem_linear_blits@interruptible,\n- igt@prime_mmap_coherency@ioctl-errors,\nwhich invisibly trigger the issue, then exhibited with first driver unbind\nattempt.\n\nAll of the above tests perform actions which are actively interrupted with\nsignals.  Further debugging has allowed to narrow that scope down to\nDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring\nsubmission, in particular.\n\nIf successful then that function, or its execlists or GuC submission\nequivalent, is supposed to be called only once per GEM context engine,\nfollowed by raise of a flag that prevents the function from being called\nagain.  The function is expected to unwind its internal errors itself, so\nit may be safely called once more after it returns an error.\n\nIn case of ring submission, the function first gets a reference to the\nengine\u0026apos;s legacy timeline and then allocates a VMA.  If the VMA allocation\nfails, e.g. when i915_vma_instance() called from inside is interrupted\nwith a signal, then ring_context_alloc() fails, leaving the timeline held\nreferenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the\ntimeline is got, and only that last one is put on successful completion.\nAs a consequence, the legacy timeline, with its underlying engine status\npage\u0026apos;s VMA object, is still held and not released on driver unbind.\n\nGet the legacy timeline only after successful allocation of the context\nengine\u0026apos;s VMA.\n\nv2: Add a note on other submission methods (Krzysztof Karas):\n    Both execlists and GuC submission use lrc_alloc() which seems free\n    from a similar issue.\n\n(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)(CVE-2025-38389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: don\u0026apos;t clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with \u0026quot;ima_appraise=fix\nevm=fix ima_policy=appraise_tcb\u0026quot; and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere\u0026apos;s a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include \u0026lt;stdio.h\u0026gt;\n    #include \u0026lt;sys/xattr.h\u0026gt;\n    #include \u0026lt;fcntl.h\u0026gt;\n    #include \u0026lt;unistd.h\u0026gt;\n    #include \u0026lt;string.h\u0026gt;\n    #include \u0026lt;stdlib.h\u0026gt;\n\n    int main() {\n        const char* file_path = \u0026quot;/usr/sbin/test_binary\u0026quot;;\n        const char* hex_string = \u0026quot;030204d33204490066306402304\u0026quot;;\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror(\u0026quot;Error opening file\u0026quot;);\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i \u0026lt; length; i += 2, j++) {\n            sscanf(hex_string + i, \u0026quot;%2hhx\u0026quot;, \u0026amp;ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, \u0026quot;security.ima\u0026quot;, ima_attr_value, length/2, 0) == -1) {\n            perror(\u0026quot;Error setting extended attribute\u0026quot;);\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= \u0026quot;system_u:object_r:bin_t:s0\u0026quot;;\n        if (fsetxattr(fd, \u0026quot;security.selinux\u0026quot;, selinux_value, strlen(selinux_value), 0) == -1) {\n            perror(\u0026quot;Error setting extended attribute\u0026quot;);\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }(CVE-2025-68183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrash: fix crashkernel resource shrink\n\nWhen crashkernel is configured with a high reservation, shrinking its\nvalue below the low crashkernel reservation causes two issues:\n\n1. Invalid crashkernel resource objects\n2. Kernel crash if crashkernel shrinking is done twice\n\nFor example, with crashkernel=200M,high, the kernel reserves 200MB of high\nmemory and some default low memory (say 256MB).  The reservation appears\nas:\n\ncat /proc/iomem | grep -i crash\naf000000-beffffff : Crash kernel\n433000000-43f7fffff : Crash kernel\n\nIf crashkernel is then shrunk to 50MB (echo 52428800 \u0026gt;\n/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:\naf000000-beffffff : Crash kernel\n\nInstead, it should show 50MB:\naf000000-b21fffff : Crash kernel\n\nFurther shrinking crashkernel to 40MB causes a kernel crash with the\nfollowing trace (x86):\n\nBUG: kernel NULL pointer dereference, address: 0000000000000038\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;snip...\u0026gt;\nCall Trace: \u0026lt;TASK\u0026gt;\n? __die_body.cold+0x19/0x27\n? page_fault_oops+0x15a/0x2f0\n? search_module_extables+0x19/0x60\n? search_bpf_extables+0x5f/0x80\n? exc_page_fault+0x7e/0x180\n? asm_exc_page_fault+0x26/0x30\n? __release_resource+0xd/0xb0\nrelease_resource+0x26/0x40\n__crash_shrink_memory+0xe5/0x110\ncrash_shrink_memory+0x12a/0x190\nkexec_crash_size_store+0x41/0x80\nkernfs_fop_write_iter+0x141/0x1f0\nvfs_write+0x294/0x460\nksys_write+0x6d/0xf0\n\u0026lt;snip...\u0026gt;\n\nThis happens because __crash_shrink_memory()/kernel/crash_core.c\nincorrectly updates the crashk_res resource object even when\ncrashk_low_res should be updated.\n\nFix this by ensuring the correct crashkernel resource object is updated\nwhen shrinking crashkernel memory.(CVE-2025-68198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix ipv4 null-ptr-deref in route error path\n\nThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()\nwithout ensuring skb-\u0026gt;dev is set, leading to a NULL pointer dereference\nin fib_compute_spec_dst() when ipv4_link_failure() attempts to send\nICMP destination unreachable messages.\n\nThe issue emerged after commit ed0de45a1008 (\u0026quot;ipv4: recompile ip options\nin ipv4_link_failure\u0026quot;) started calling __ip_options_compile() from\nipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()\nwhich dereferences skb-\u0026gt;dev. An attempt was made to fix the NULL skb-\u0026gt;dev\ndereference in commit 0113d9c9d1cc (\u0026quot;ipv4: fix null-deref in\nipv4_link_failure\u0026quot;), but it only addressed the immediate dev_net(skb-\u0026gt;dev)\ndereference by using a fallback device. The fix was incomplete because\nfib_compute_spec_dst() later in the call chain still accesses skb-\u0026gt;dev\ndirectly, which remains NULL when IPVS calls dst_link_failure().\n\nThe crash occurs when:\n1. IPVS processes a packet in NAT mode with a misconfigured destination\n2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route\n3. The error path calls dst_link_failure(skb) with skb-\u0026gt;dev == NULL\n4. ipv4_link_failure() \u2192 ipv4_send_dest_unreach() \u2192\n   __ip_options_compile() \u2192 fib_compute_spec_dst()\n5. fib_compute_spec_dst() dereferences NULL skb-\u0026gt;dev\n\nApply the same fix used for IPv6 in commit 326bf17ea5d4 (\u0026quot;ipvs: fix\nipv6 route unreach panic\u0026quot;): set skb-\u0026gt;dev from skb_dst(skb)-\u0026gt;dev before\ncalling dst_link_failure().\n\nKASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]\nCPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2\nRIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233\nRIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285\nCall Trace:\n  \u0026lt;TASK\u0026gt;\n  spec_dst_fill net/ipv4/ip_options.c:232\n  spec_dst_fill net/ipv4/ip_options.c:229\n  __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330\n  ipv4_send_dest_unreach net/ipv4/route.c:1252\n  ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265\n  dst_link_failure include/net/dst.h:437\n  __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412\n  ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764(CVE-2025-68813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()\n\nThere exists a kernel oops caused by a BUG_ON(nhead \u0026lt; 0) at\nnet/core/skbuff.c:2232 in pskb_expand_head().\nThis bug is triggered as part of the calipso_skbuff_setattr()\nroutine when skb_cow() is passed headroom \u0026gt; INT_MAX\n(i.e. (int)(skb_headroom(skb) + len_delta) \u0026lt; 0).\n\nThe root cause of the bug is due to an implicit integer cast in\n__skb_cow(). The check (headroom \u0026gt; skb_headroom(skb)) is meant to ensure\nthat delta = headroom - skb_headroom(skb) is never negative, otherwise\nwe will trigger a BUG_ON in pskb_expand_head(). However, if\nheadroom \u0026gt; INT_MAX and delta \u0026lt;= -NET_SKB_PAD, the check passes, delta\nbecomes negative, and pskb_expand_head() is passed a negative value for\nnhead.\n\nFix the trigger condition in calipso_skbuff_setattr(). Avoid passing\n\u0026quot;negative\u0026quot; headroom sizes to skb_cow() within calipso_skbuff_setattr()\nby only using skb_cow() to grow headroom.\n\nPoC:\n\tUsing `netlabelctl` tool:\n\n        netlabelctl map del default\n        netlabelctl calipso add pass doi:7\n        netlabelctl map add default address:0::1/128 protocol:calipso,7\n\n        Then run the following PoC:\n\n        int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);\n\n        // setup msghdr\n        int cmsg_size = 2;\n        int cmsg_len = 0x60;\n        struct msghdr msg;\n        struct sockaddr_in6 dest_addr;\n        struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,\n                        sizeof(struct cmsghdr) + cmsg_len);\n        msg.msg_name = \u0026amp;dest_addr;\n        msg.msg_namelen = sizeof(dest_addr);\n        msg.msg_iov = NULL;\n        msg.msg_iovlen = 0;\n        msg.msg_control = cmsg;\n        msg.msg_controllen = cmsg_len;\n        msg.msg_flags = 0;\n\n        // setup sockaddr\n        dest_addr.sin6_family = AF_INET6;\n        dest_addr.sin6_port = htons(31337);\n        dest_addr.sin6_flowinfo = htonl(31337);\n        dest_addr.sin6_addr = in6addr_loopback;\n        dest_addr.sin6_scope_id = 31337;\n\n        // setup cmsghdr\n        cmsg-\u0026gt;cmsg_len = cmsg_len;\n        cmsg-\u0026gt;cmsg_level = IPPROTO_IPV6;\n        cmsg-\u0026gt;cmsg_type = IPV6_HOPOPTS;\n        char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);\n        hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80\n\n        sendmsg(fd, \u0026amp;msg, 0);(CVE-2025-71085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb-\u0026gt;number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb-\u0026gt;iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb-\u0026gt;iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n  The buggy address is located 0 bytes to the right of\n   allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 (\u0026quot;usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input\u0026quot;) and b78d830f0049 (\u0026quot;usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input\u0026quot;). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo\u0026apos;s series (\u0026quot;usb: usbip: fix integer overflow in\nusbip_recv_iso()\u0026quot;, v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu-\u0026gt;number_of_packets against\nurb-\u0026gt;number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr-\u0026gt;size or dacl_ptr-\u0026gt;num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl-\u0026gt;num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject immediate NF_QUEUE verdict\n\nnft_queue is always used from userspace nftables to deliver the NF_QUEUE\nverdict. Immediately emitting an NF_QUEUE verdict is never used by the\nuserspace nft tools, so reject immediate NF_QUEUE verdicts.\n\nThe arp family does not provide queue support, but such an immediate\nverdict is still reachable. Globally reject NF_QUEUE immediate verdicts\nto address this issue.(CVE-2026-43024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: icmp: clear skb2-\u0026gt;cb[] in ip6_err_gen_icmpv6_unreach()\n\nSashiko AI-review observed:\n\n  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet\n  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2\n  and passed to icmp6_send(), it uses IP6CB(skb2).\n\n  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso\n  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm\n  at offset 18.\n\n  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao\n  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called\n  and uses ipv6_find_tlv(skb, opt-\u0026gt;dsthao, IPV6_TLV_HAO).\n\n  This would scan the inner, attacker-controlled IPv6 packet starting at that\n  offset, potentially returning a fake TLV without checking if the remaining\n  packet length can hold the full 18-byte struct ipv6_destopt_hao.\n\n  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end\n  of the packet data into skb_shared_info?\n\n  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and\n  ip6ip6_err() to prevent this?\n\nThis patch implements the first suggestion.\n\nI am not sure if ip6ip6_err() needs to be changed.\nA separate patch would be better anyway.(CVE-2026-43038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndcache: Limit the minimal number of bucket to two\n\nThere is an OOB read problem on dentry_hashtable when user sets\n\u0026apos;dhash_entries=1\u0026apos;:\n  BUG: unable to handle page fault for address: ffff888b30b774b0\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP PTI\n  RIP: 0010:__d_lookup+0x56/0x120\n   Call Trace:\n    d_lookup.cold+0x16/0x5d\n    lookup_dcache+0x27/0xf0\n    lookup_one_qstr_excl+0x2a/0x180\n    start_dirop+0x55/0xa0\n    simple_start_creating+0x8d/0xa0\n    debugfs_start_creating+0x8c/0x180\n    debugfs_create_dir+0x1d/0x1c0\n    pinctrl_init+0x6d/0x140\n    do_one_initcall+0x6d/0x3d0\n    kernel_init_freeable+0x39f/0x460\n    kernel_init+0x2a/0x260\n\nThere will be only one bucket in dentry_hashtable when dhash_entries is\nset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,\nfollowing process will access more than one buckets(which memory region\nis not allocated) in dentry_hashtable:\n d_lookup\n  b = d_hash(hash)\n    dentry_hashtable + ((u32)hashlen \u0026gt;\u0026gt; d_hash_shift)\n    // The C standard defines the behavior of right shift amounts\n    // exceeding the bit width of the operand as undefined. The\n    // result of \u0026apos;(u32)hashlen \u0026gt;\u0026gt; d_hash_shift\u0026apos; becomes \u0026apos;hashlen\u0026apos;,\n    // so \u0026apos;b\u0026apos; will point to an unallocated memory region.\n  hlist_bl_for_each_entry_rcu(b)\n   hlist_bl_first_rcu(head)\n    h-\u0026gt;first  // read OOB!\n\nFix it by limiting the minimal number of dentry_hashtable bucket to two,\nso that \u0026apos;d_hash_shift\u0026apos; won\u0026apos;t exceeds the bit width of type u32.(CVE-2026-43071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: zero aligned sockaddr tail in PF_KEY exports\n\nPF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr\npayload space, so IPv6 addresses occupy 32 bytes on the wire. However,\n`pfkey_sockaddr_fill()` initializes only the first 28 bytes of\n`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.\n\nNot every PF_KEY message is affected. The state and policy dump builders\nalready zero the whole message buffer before filling the sockaddr\npayloads. Keep the fix to the export paths that still append aligned\nsockaddr payloads with plain `skb_put()`:\n\n  - `SADB_ACQUIRE`\n  - `SADB_X_NAT_T_NEW_MAPPING`\n  - `SADB_X_MIGRATE`\n\nFix those paths by clearing only the aligned sockaddr tail after\n`pfkey_sockaddr_fill()`.(CVE-2026-43088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm_user: fix info leak in build_mapping()\n\nstruct xfrm_usersa_id has a one-byte padding hole after the proto\nfield, which ends up never getting set to zero before copying out to\nuserspace.  Fix that up by zeroing out the whole structure before\nsetting individual variables.(CVE-2026-43089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: account XFRMA_IF_ID in aevent size calculation\n\nxfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then\nbuild_aevent() appends attributes including XFRMA_IF_ID when x-\u0026gt;if_id is\nset.\n\nxfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states\nwith if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err \u0026lt; 0)\nin xfrm_get_ae(), turning a malformed netlink interaction into a kernel\npanic.\n\nAccount XFRMA_IF_ID in the size calculation unconditionally and replace\nthe BUG_ON with normal error unwinding.(CVE-2026-43107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix potential race in tcp_v6_syn_recv_sock()\n\nCode in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()\nis done too late.\n\nAfter tcp_v4_syn_recv_sock(), the child socket is already visible\nfrom TCP ehash table and other cpus might use it.\n\nSince newinet-\u0026gt;pinet6 is still pointing to the listener ipv6_pinfo\nbad things can happen as syzbot found.\n\nMove the problematic code in tcp_v6_mapped_child_init()\nand call this new helper from tcp_v4_syn_recv_sock() before\nthe ehash insertion.\n\nThis allows the removal of one tcp_sync_mss(), since\ntcp_v4_syn_recv_sock() will call it with the correct\ncontext.(CVE-2026-43198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Drop the lock in skb_may_tx_timestamp()\n\nskb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must\nnot be taken in IRQ context, only softirq is okay. A few drivers receive\nthe timestamp via a dedicated interrupt and complete the TX timestamp\nfrom that handler. This will lead to a deadlock if the lock is already\nwrite-locked on the same CPU.\n\nTaking the lock can be avoided. The socket (pointed by the skb) will\nremain valid until the skb is released. The -\u0026gt;sk_socket and -\u0026gt;file\nmember will be set to NULL once the user closes the socket which may\nhappen before the timestamp arrives.\nIf we happen to observe the pointer while the socket is closing but\nbefore the pointer is set to NULL then we may use it because both\npointer (and the file\u0026apos;s cred member) are RCU freed.\n\nDrop the lock. Use READ_ONCE() to obtain the individual pointer. Add a\nmatching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we\u0026apos;re at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: clear page-\u0026gt;private in free_pages_prepare()\n\nSeveral subsystems (slub, shmem, ttm, etc.) use page-\u0026gt;private but don\u0026apos;t\nclear it before freeing pages.  When these pages are later allocated as\nhigh-order pages and split via split_page(), tail pages retain stale\npage-\u0026gt;private values.\n\nThis causes a use-after-free in the swap subsystem.  The swap code uses\npage-\u0026gt;private to track swap count continuations, assuming freshly\nallocated pages have page-\u0026gt;private == 0.  When stale values are present,\nswap_count_continued() incorrectly assumes the continuation list is valid\nand iterates over uninitialized page-\u0026gt;lru containing LIST_POISON values,\ncausing a crash:\n\n  KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]\n  RIP: 0010:__do_sys_swapoff+0x1151/0x1860\n\nFix this by clearing page-\u0026gt;private in free_pages_prepare(), ensuring all\nfreed pages have clean state regardless of previous use.(CVE-2026-43303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Fix NULL pointer exception during user_scan()\n\nuser_scan() invokes updated sas_user_scan() for channel 0, and if\nsuccessful, iteratively scans remaining channels (1 to shost-\u0026gt;max_channel)\nvia scsi_scan_host_selected() in commit 37c4e72b0651 (\u0026quot;scsi: Fix\nsas_user_scan() to handle wildcard and multi-channel scans\u0026quot;). However,\nhisi_sas supports only one channel, and the current value of max_channel is\n1. sas_user_scan() for channel 1 will trigger the following NULL pointer\nexception:\n\n[  441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0\n[  441.554699] Mem abort info:\n[  441.554710]   ESR = 0x0000000096000004\n[  441.554718]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  441.554723]   SET = 0, FnV = 0\n[  441.554726]   EA = 0, S1PTW = 0\n[  441.554730]   FSC = 0x04: level 0 translation fault\n[  441.554735] Data abort info:\n[  441.554737]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[  441.554742]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[  441.554747]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[  441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000\n[  441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000\n[  441.554769] Internal error: Oops: 0000000096000004 [#1]  SMP\n[  441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod\n[  441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT\n[  441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[  441.698277] pc : sas_find_dev_by_rphy+0x44/0x118\n[  441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118\n[  441.707502] sp : ffff80009abbba40\n[  441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08\n[  441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00\n[  441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000\n[  441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020\n[  441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff\n[  441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a\n[  441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4\n[  441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030\n[  441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n[  441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000\n[  441.782053] Call trace:\n[  441.784488]  sas_find_dev_by_rphy+0x44/0x118 (P)\n[  441.789095]  sas_target_alloc+0x24/0xb0\n[  441.792920]  scsi_alloc_target+0x290/0x330\n[  441.797010]  __scsi_scan_target+0x88/0x258\n[  441.801096]  scsi_scan_channel+0x74/0xb8\n[  441.805008]  scsi_scan_host_selected+0x170/0x188\n[  441.809615]  sas_user_scan+0xfc/0x148\n[  441.813267]  store_scan+0x10c/0x180\n[  441.816743]  dev_attr_store+0x20/0x40\n[  441.820398]  sysfs_kf_write+0x84/0xa8\n[  441.824054]  kernfs_fop_write_iter+0x130/0x1c8\n[  441.828487]  vfs_write+0x2c0/0x370\n[  441.831880]  ksys_write+0x74/0x118\n[  441.835271]  __arm64_sys_write+0x24/0x38\n[  441.839182]  invoke_syscall+0x50/0x120\n[  441.842919]  el0_svc_common.constprop.0+0xc8/0xf0\n[  441.847611]  do_el0_svc+0x24/0x38\n[  441.850913]  el0_svc+0x38/0x158\n[  441.854043]  el0t_64_sync_handler+0xa0/0xe8\n[  441.858214]  el0t_64_sync+0x1ac/0x1b0\n[  441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75)\n[  441.867946] ---[ end trace 0000000000000000 ]---\n\nTherefore\n---truncated---(CVE-2026-43413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: skip ipv6 extension headers for csum checks\n\nProtocol checksum validation fails for IPv6 if there are extension\nheaders before the protocol header. iph-\u0026gt;len already contains its\noffset, so use it to fix the problem.(CVE-2026-45850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix double free issue for tx spare buffer\n\nIn hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure\nis created for rollback. However, the tx_spare pointer in the original\nring handle is incorrectly left pointing to the old backup memory.\n\nLater, if memory allocation fails in hns3_init_all_ring() during the setup,\nthe error path attempts to free all newly allocated rings. Since tx_spare\ncontains a stale (non-NULL) pointer from the backup, it is mistaken for\na newly allocated buffer and is erroneously freed, leading to a double-free\nof the backup memory.\n\nThe root cause is that the tx_spare field was not cleared after its value\nwas saved in tmp_rings, leaving a dangling pointer.\n\nFix this by setting tx_spare to NULL in the original ring structure\nwhen the creation of the new `tx_spare` fails. This ensures the\nerror cleanup path only frees genuinely newly allocated buffers.(CVE-2026-45891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down PASID entry\n\nThe Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64\nbytes). When tearing down an entry, the current implementation zeros the\nentire 64-byte structure immediately using multiple 64-bit writes.\n\nSince the IOMMU hardware may fetch these 64 bytes using multiple\ninternal transactions (e.g., four 128-bit bursts), updating or zeroing\nthe entire entry while it is active (P=1) risks a \u0026quot;torn\u0026quot; read. If a\nhardware fetch occurs simultaneously with the CPU zeroing the entry, the\nhardware could observe an inconsistent state, leading to unpredictable\nbehavior or spurious faults.\n\nFollow the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the PASID entry.\n2. Use a dma_wmb() to ensure the cleared bit is visible to hardware\n   before proceeding.\n3. Execute the required invalidation sequence (PASID cache, IOTLB, and\n   Device-TLB flush) to ensure the hardware has released all cached\n   references.\n4. Only after the flushes are complete, zero out the remaining fields\n   of the PASID entry.\n\nAlso, add a dma_wmb() in pasid_set_present() to ensure that all other\nfields of the PASID entry are visible to the hardware before the Present\nbit is set.(CVE-2026-45894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nquota: fix livelock between quotactl and freeze_super\n\nWhen a filesystem is frozen, quotactl_block() enters a retry loop\nwaiting for the filesystem to thaw. It acquires s_umount, checks the\nfreeze state, drops s_umount and uses sb_start_write() - sb_end_write()\npair to wait for the unfreeze.\n\nHowever, this retry loop can trigger a livelock issue, specifically on\nkernels with preemption disabled.\n\nThe mechanism is as follows:\n1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().\n2. sb_wait_write() calls percpu_down_write(), which initiates\n   synchronize_rcu().\n3. Simultaneously, quotactl_block() spins in its retry loop, immediately\n   executing the sb_start_write() - sb_end_write() pair.\n4. Because the kernel is non-preemptible and the loop contains no\n   scheduling points, quotactl_block() never yields the CPU. This\n   prevents that CPU from reaching an RCU quiescent state.\n5. synchronize_rcu() in the freezer thread waits indefinitely for the\n   quotactl_block() CPU to report a quiescent state.\n6. quotactl_block() spins indefinitely waiting for the freezer to\n   advance, which it cannot do as it is blocked on the RCU sync.\n\nThis results in a hang of the freezer process and 100% CPU usage by the\nquota process.\n\nWhile this can occur intermittently on multi-core systems, it is\nreliably reproducing on a node with the following script, running both\nthe freezer and the quota toggle on the same CPU:\n\n  # mkfs.ext4 -O quota /dev/sda 2g \u0026amp;\u0026amp; mkdir a_mount\n  # mount /dev/sda -o quota,usrquota,grpquota a_mount\n  # taskset -c 3 bash -c \u0026quot;while true; do xfs_freeze -f a_mount; \\\n    xfs_freeze -u a_mount; done\u0026quot; \u0026amp;\n  # taskset -c 3 bash -c \u0026quot;while true; do quotaon a_mount; \\\n    quotaoff a_mount; done\u0026quot; \u0026amp;\n\nAdding cond_resched() to the retry loop fixes the issue. It acts as an\nRCU quiescent state, allowing synchronize_rcu() in percpu_down_write()\nto complete.(CVE-2026-45895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfat: avoid parent link count underflow in rmdir\n\nCorrupted FAT images can leave a directory inode with an incorrect\ni_nlink (e.g. 2 even though subdirectories exist). rmdir then\nunconditionally calls drop_nlink(dir) and can drive i_nlink to 0,\ntriggering the WARN_ON in drop_nlink().\n\nAdd a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the\nparent link count when it is at least 3, otherwise report a filesystem\nerror.(CVE-2026-45915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task-\u0026gt;prio \u0026lt; rq-\u0026gt;donor-\u0026gt;prio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd-\u0026gt;rto_loop_next. Even when rd-\u0026gt;rto_cpu is set to -1, the mismatch between\nrd-\u0026gt;rto_loop and rd-\u0026gt;rto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n\u0026amp;\u0026amp; rt_nr_total \u0026gt; 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n         cpu0                      cpu1                    cpu2\n                                pull_rt_task\n                              tell_cpu_to_push\n                 \u0026lt;------------irq_work_queue_on\nrto_push_irq_work_func\n       push_rt_task\n    resched_curr(rq)                                   pull_rt_task\n    rto_next_cpu                                     tell_cpu_to_push\n                      \u0026lt;-------------------------- atomic_inc(rto_loop_next)\nrd-\u0026gt;rto_loop != next\n     rto_next_cpu\n   irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.(CVE-2026-45919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix dirtyclusters double decrement on fs shutdown\n\nfstests test generic/388 occasionally reproduces a warning in\next4_put_super() associated with the dirty clusters count:\n\n  WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]\n\nTracing the failure shows that the warning fires due to an\ns_dirtyclusters_counter value of -1. IOW, this appears to be a\nspurious decrement as opposed to some sort of leak. Further tracing\nof the dirty cluster count deltas and an LLM scan of the resulting\noutput identified the cause as a double decrement in the error path\nbetween ext4_mb_mark_diskspace_used() and the caller\next4_mb_new_blocks().\n\nFirst, note that generic/388 is a shutdown vs. fsstress test and so\nproduces a random set of operations and shutdown injections. In the\nproblematic case, the shutdown triggers an error return from the\next4_handle_dirty_metadata() call(s) made from\next4_mb_mark_context(). The changed value is non-zero at this point,\nso ext4_mb_mark_diskspace_used() does not exit after the error\nbubbles up from ext4_mb_mark_context(). Instead, the former\ndecrements both cluster counters and returns the error up to\next4_mb_new_blocks(). The latter falls into the !ar-\u0026gt;len out path\nwhich decrements the dirty clusters counter a second time, creating\nthe inconsistency.\n\nTo avoid this problem and simplify ownership of the cluster\nreservation in this codepath, lift the counter reduction to a single\nplace in the caller. This makes it more clear that\next4_mb_new_blocks() is responsible for acquiring cluster\nreservation (via ext4_claim_free_clusters()) in the !delalloc case\nas well as releasing it, regardless of whether it ends up consumed\nor returned due to failure.(CVE-2026-45920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix e4b bitmap inconsistency reports\n\nA bitmap inconsistency issue was observed during stress tests under\nmixed huge-page workloads. Ext4 reported multiple e4b bitmap check\nfailures like:\n\next4_mb_complex_scan_group:2508: group 350, 8179 free clusters as\nper group info. But got 8192 blocks\n\nAnalysis and experimentation confirmed that the issue is caused by a\nrace condition between page migration and bitmap modification. Although\nthis timing window is extremely narrow, it is still hit in practice:\n\nfolio_lock                        ext4_mb_load_buddy\n__migrate_folio\n  check ref count\n  folio_mc_copy                     __filemap_get_folio\n                                      folio_try_get(folio)\n                                  ......\n                                  mb_mark_used\n                                  ext4_mb_unload_buddy\n  __folio_migrate_mapping\n    folio_ref_freeze\nfolio_unlock\n\nThe root cause of this issue is that the fast path of load_buddy only\nincrements the folio\u0026apos;s reference count, which is insufficient to prevent\nconcurrent folio migration. We observed that the folio migration process\nacquires the folio lock. Therefore, we can determine whether to take the\nfast path in load_buddy by checking the lock status. If the folio is\nlocked, we opt for the slow path (which acquires the lock) to close this\nconcurrency window.\n\nAdditionally, this change addresses the following issues:\n\nWhen the DOUBLE_CHECK macro is enabled to inspect bitmap-related\nissues, the following error may be triggered:\n\ncorruption in group 324 at byte 784(6272): f in copy != ff on\ndisk/prealloc\n\nAnalysis reveals that this is a false positive. There is a specific race\nwindow where the bitmap and the group descriptor become momentarily\ninconsistent, leading to this error report:\n\next4_mb_load_buddy                   ext4_mb_load_buddy\n  __filemap_get_folio(create|lock)\n    folio_lock\n  ext4_mb_init_cache\n    folio_mark_uptodate\n                                     __filemap_get_folio(no lock)\n                                     ......\n                                     mb_mark_used\n                                       mb_mark_used_double\n  mb_cmp_bitmaps\n                                       mb_set_bits(e4b-\u0026gt;bd_bitmap)\n  folio_unlock\n\nThe original logic assumed that since mb_cmp_bitmaps is called when the\nbitmap is newly loaded from disk, the folio lock would be sufficient to\nprevent concurrent access. However, this overlooks a specific race\ncondition: if another process attempts to load buddy and finds the folio\nis already in an uptodate state, it will immediately begin using it without\nholding folio lock.(CVE-2026-45942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down context entry\n\nWhen tearing down a context entry, the current implementation zeros the\nentire 128-bit entry using multiple 64-bit writes. This creates a window\nwhere the hardware can fetch a \u0026quot;torn\u0026quot; entry \u2014 where some fields are\nalready zeroed while the \u0026apos;Present\u0026apos; bit is still set \u2014 leading to\nunpredictable behavior or spurious faults.\n\nWhile x86 provides strong write ordering, the compiler may reorder writes\nto the two 64-bit halves of the context entry. Even without compiler\nreordering, the hardware fetch is not guaranteed to be atomic with\nrespect to multiple CPU writes.\n\nAlign with the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the context entry first to\n   signal the transition of ownership from hardware to software.\n2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.\n3. Perform the required cache and context-cache invalidation to ensure\n   hardware no longer has cached references to the entry.\n4. Fully zero out the entry only after the invalidation is complete.\n\nAlso, add a dma_wmb() to context_set_present() to ensure the entry\nis fully initialized before the \u0026apos;Present\u0026apos; bit becomes visible.(CVE-2026-45944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix memory leak in ext4_ext_shift_extents()\n\nIn ext4_ext_shift_extents(), if the extent is NULL in the while loop, the\nfunction returns immediately without releasing the path obtained via\next4_find_extent(), leading to a memory leak.\n\nFix this by jumping to the out label to ensure the path is properly\nreleased.(CVE-2026-45948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpuidle: Skip governor when only one idle state is available\n\nOn certain platforms (PowerNV systems without a power-mgt DT node),\ncpuidle may register only a single idle state. In cases where that\nsingle state is a polling state (state 0), the ladder governor may\nincorrectly treat state 1 as the first usable state and pass an\nout-of-bounds index. This can lead to a NULL enter callback being\ninvoked, ultimately resulting in a system crash.\n\n[   13.342636] cpuidle-powernv : Only Snooze is available\n[   13.351854] Faulting instruction address: 0x00000000\n[   13.376489] NIP [0000000000000000] 0x0\n[   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668\n\nFix this by adding a bail-out in cpuidle_select() that returns state 0\ndirectly when state_count \u0026lt;= 1, bypassing the governor and keeping the\ntick running.(CVE-2026-45968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: don\u0026apos;t set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O\n\nWhen allocating blocks during within-EOF DIO and writeback with\ndioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an\nexisting large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was\nset when calling ext4_split_convert_extents(), which may potentially\nresult in stale data issues.\n\nAssume we have an unwritten extent, and then DIO writes the second half.\n\n   [UUUUUUUUUUUUUUUU] on-disk extent        U: unwritten extent\n   [UUUUUUUUUUUUUUUU] extent status tree\n            |\u0026lt;-   -\u0026gt;| ----\u0026gt; dio write this range\n\nFirst, ext4_iomap_alloc() call ext4_map_blocks() with\nEXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and\nEXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and\ncall ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the\nabove flags set.\n\nThen, ext4_split_convert_extents() calls ext4_split_extent() with\nEXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2\nflags set, and it calls ext4_split_extent_at() to split the second half\nwith EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT\nand EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()\nfailed to insert extent since a temporary lack -ENOSPC. It zeroes out\nthe first half but convert the entire on-disk extent to written since\nthe EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten\nin the extent status tree.\n\n   [0000000000SSSSSS]  data                S: stale data, 0: zeroed\n   [WWWWWWWWWWWWWWWW]  on-disk extent      W: written extent\n   [WWWWWWWWWWUUUUUU]  extent status tree\n\nFinally, if the DIO failed to write data to the disk, the stale data in\nthe second half will be exposed once the cached extent entry is gone.\n\nFix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting\nan unwritten extent before submitting I/O, and make\next4_split_convert_extents() to zero out the entire extent range\nto zero for this case, and also mark the extent in the extent status\ntree for consistency.(CVE-2026-45985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT\n\nIf loading L1\u0026apos;s CR3 fails on a nested #VMEXIT, nested_svm_vmexit()\nreturns an error code that is ignored by most callers, and continues to\nrun L1 with corrupted state. A sane recovery is not possible in this\ncase, and HW behavior is to cause a shutdown. Inject a triple fault\ninstead, and do not return early from nested_svm_vmexit(). Continue\ncleaning up the vCPU state (e.g. clear pending exceptions), to handle\nthe failure as gracefully as possible.\n\nFrom the APM:\n\n  Upon #VMEXIT, the processor performs the following actions in order to\n  return to the host execution context:\n\n  ...\n\n  if (illegal host state loaded, or exception while loading host state)\n      shutdown\n  else\n      execute first host instruction following the VMRUN\n\nRemove the return value of nested_svm_vmexit(), which is mostly\nunchecked anyway.(CVE-2026-46032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.(CVE-2026-46065)\n\nIn the Linux kernel, the vlan_dev_set_egress_priority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: fix ep_remove struct eventpoll / struct file UAF\n\nep_remove() (via ep_remove_file()) cleared file-\u0026gt;f_ep under\nfile-\u0026gt;f_lock but then kept using @file inside the critical section\n(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).\nA concurrent __fput() taking the eventpoll_release() fastpath in\nthat window observed the transient NULL, skipped\neventpoll_release_file() and ran to f_op-\u0026gt;release / file_free().\n\nFor the epoll-watches-epoll case, f_op-\u0026gt;release is\nep_eventpoll_release() -\u0026gt; ep_clear_and_put() -\u0026gt; ep_free(), which\nkfree()s the watched struct eventpoll. Its embedded -\u0026gt;refs\nhlist_head is exactly where epi-\u0026gt;fllink.pprev points, so the\nsubsequent hlist_del_rcu()\u0026apos;s \u0026quot;*pprev = next\u0026quot; scribbles into freed\nkmalloc-192 memory.\n\nIn addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot\nbacking @file could be recycled by alloc_empty_file() --\nreinitializing f_lock and f_ep -- while ep_remove() is still\nnominally inside that lock. The upshot is an attacker-controllable\nkmem_cache_free() against the wrong slab cache.\n\nPin @file via epi_fget() at the top of ep_remove() and gate the\ncritical section on the pin succeeding. With the pin held @file\ncannot reach refcount zero, which holds __fput() off and\ntransitively keeps the watched struct eventpoll alive across the\nhlist_del_rcu() and the f_lock use, closing both UAFs.\n\nIf the pin fails @file has already reached refcount zero and its\n__fput() is in flight. Because we bailed before clearing f_ep,\nthat path takes the eventpoll_release() slow path into\neventpoll_release_file() and blocks on ep-\u0026gt;mtx until the waiter\nside\u0026apos;s ep_clear_and_put() drops it. The bailed epi\u0026apos;s share of\nep-\u0026gt;refcount stays intact, so the trailing ep_refcount_dec_and_test()\nin ep_clear_and_put() cannot free the eventpoll out from under\neventpoll_release_file(); the orphaned epi is then cleaned up\nthere.\n\nA successful pin also proves we are not racing\neventpoll_release_file() on this epi, so drop the now-redundant\nre-check of epi-\u0026gt;dying under f_lock. The cheap lockless\nREAD_ONCE(epi-\u0026gt;dying) fast-path bailout stays.(CVE-2026-46242)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dc_link NULL handling in HPD init  amdgpu_dm_hpd_init() may see connectors without a valid dc_link.  The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.  Assign dc_link early and skip connectors where it is NULL.  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed \u0026apos;dc_link\u0026apos; could be null (see line 931)  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c     923                 /*     924                  * Analog connectors may be hot-plugged unlike other connector     925                  * types that don\u0026apos;t support HPD. Only poll analog connectors.     926                  */     927                 use_polling |=     928                         amdgpu_dm_connector-\u0026gt;dc_link \u0026amp;\u0026amp;                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed      929                         dc_connector_supports_analog(amdgpu_dm_connector-\u0026gt;dc_link-\u0026gt;link_id.id);     930     931                 dc_link = amdgpu_dm_connector-\u0026gt;dc_link;  dc_link assigned here.      932     933                 /*     934                  * Get a base driver irq reference for hpd ints for the lifetime     935                  * of dm. Note that only hpd interrupt types are registered with     936                  * base driver; hpd_rx types aren\u0026apos;t. IOW, amdgpu_irq_get/put on     937                  * hpd_rx isn\u0026apos;t available. DM currently controls hpd_rx     938                  * explicitly with dc_interrupt_set()     939                  */ --\u0026gt; 940                 if (dc_link-\u0026gt;irq_source_hpd != DC_IRQ_SOURCE_INVALID) {                             ^^^^^^^^^^^^^^^^^^^^^^^ If it\u0026apos;s NULL then we are trouble because we dereference it here.      941                         irq_type = dc_link-\u0026gt;irq_source_hpd - DC_IRQ_SOURCE_HPD1;     942                         /*     943                          * TODO: There\u0026apos;s a mismatch between mode_info.num_hpd     944                          * and what bios reports as the # of connectors with hpd  The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)\n\nIn the Linux kernel, the following vulnerability has been resolved:  procfs: fix missing RCU protection when reading real_parent in do_task_stat()  When reading /proc/[pid]/stat, do_task_stat() accesses task-\u0026gt;real_parent without proper RCU protection, which leads to:    cpu 0                               cpu 1   -----                               -----   do_task_stat     var = task-\u0026gt;real_parent                                       release_task                                         call_rcu(delayed_put_task_struct)     task_tgid_nr_ns(var)       rcu_read_lock   \u0026lt;--- Too late to protect task-\u0026gt;real_parent!       task_pid_ptr    \u0026lt;--- UAF!       rcu_read_unlock  This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task-\u0026gt;real_parent.  The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)",
  "id": "OESA-2026-2675",
  "modified": "2026-08-06T11:11:36Z",
  "published": "2026-06-12T11:11:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38389"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68813"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71085"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31527"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43024"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43071"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43088"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43107"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43216"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43413"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45850"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45891"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45948"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45985"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46065"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46242"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46245"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46259"
    }
  ],
  "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-38389",
    "CVE-2025-68183",
    "CVE-2025-68198",
    "CVE-2025-68813",
    "CVE-2025-71085",
    "CVE-2026-31527",
    "CVE-2026-31607",
    "CVE-2026-31709",
    "CVE-2026-43024",
    "CVE-2026-43038",
    "CVE-2026-43071",
    "CVE-2026-43088",
    "CVE-2026-43089",
    "CVE-2026-43107",
    "CVE-2026-43198",
    "CVE-2026-43216",
    "CVE-2026-43248",
    "CVE-2026-43303",
    "CVE-2026-43413",
    "CVE-2026-45850",
    "CVE-2026-45891",
    "CVE-2026-45894",
    "CVE-2026-45895",
    "CVE-2026-45915",
    "CVE-2026-45919",
    "CVE-2026-45920",
    "CVE-2026-45942",
    "CVE-2026-45944",
    "CVE-2026-45948",
    "CVE-2026-45968",
    "CVE-2026-45985",
    "CVE-2026-46032",
    "CVE-2026-46065",
    "CVE-2026-46153",
    "CVE-2026-46242",
    "CVE-2026-46245",
    "CVE-2026-46259"
  ]
}

RHSA-2026:21745

Vulnerability from csaf_redhat - Published: 2026-05-28 13:35 - Updated: 2026-09-24 21:51

Summary

Red Hat Security Advisory: kernel-rt security update

Severity

Important

Scope

19 vulnerabilities in this advisory, including CVE-2025-68183.

CVE-2025-68183

7.1 (High)


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

Fixed: 30 products

https://access.redhat.com/errata/RHSA-2026:21745

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

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

Related by attack behaviour

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

Action not permitted

CVE-2025-68183 (GCVE-0-2025-68183)

Solutions

OESA-2026-2675 (CVE-2025-38389)

Tags

Sightings

Nomenclature

Related by attack behaviour