Vulnerability-Lookup

CVE-2026-89508 (GCVE-0-2026-89508)

Vulnerability from cvelistv5 – Published: 2026-09-11 19:43 – Updated: 2026-10-19 08:47

Title

RDMA/ucma: Lock the handler in ucma_set_ib_path()

Summary

In the Linux kernel, the following vulnerability has been resolved: RDMA/ucma: Lock the handler in ucma_set_ib_path() ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference: mutex_lock(&ctx->file->mut); /* file A */ list_add_tail(&uevent->list, &ctx->file->event_list); /* file B */ mutex_unlock(&ctx->file->mut); /* file B */ wake_up_interruptible(&ctx->file->poll_wait); /* file B */ A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list: BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0 The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep. This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present. Take the handler lock around the call.

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 CNA under the mitre root

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

References

8 references

URL	Tags
https://git.kernel.org/stable/c/3dd07b369371a2f29…
https://git.kernel.org/stable/c/b2da0d488a1c72956…
https://git.kernel.org/stable/c/a7f8d26e653ee43b0…
https://git.kernel.org/stable/c/71dc206f2e2a645da…
https://git.kernel.org/stable/c/764586f8f6180084c…
https://git.kernel.org/stable/c/28ac2dd416482d1c7…
https://git.kernel.org/stable/c/43a7d8ae9f645dc00…
https://git.kernel.org/stable/c/ecbe7d36dc2de07e5…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < 3dd07b369371a2f29e1c3caf1ade85bb92b4c551 (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < b2da0d488a1c72956ebb0a57015ee8ee6a2f7748 (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < a7f8d26e653ee43b0b572984b8ec544d3b3b6f3c (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < 71dc206f2e2a645dac78879768762451aa1799f7 (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < 764586f8f6180084c5a7d622120f526acc6ce0c9 (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < 28ac2dd416482d1c763c4af5d61af465b387fb50 (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < 43a7d8ae9f645dc00235cfa4bf57673c20b769f8 (git) Affected: 09e328e47a695b0d346598f5d6593ee598e64885 , < ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820 (git)	guessed
Linux	Linux	Affected: 5.10 Unaffected: 0 , < 5.10 (semver) Unaffected: 5.10.270 , ≤ 5.10.* (semver) Unaffected: 5.15.221 , ≤ 5.15.* (semver) Unaffected: 6.1.188 , ≤ 6.1.* (semver) Unaffected: 6.6.157 , ≤ 6.6.* (semver) Unaffected: 6.12.109 , ≤ 6.12.* (semver) Unaffected: 6.18.50 , ≤ 6.18.* (semver) Unaffected: 7.2.4 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/infiniband/core/ucma.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "3dd07b369371a2f29e1c3caf1ade85bb92b4c551",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "b2da0d488a1c72956ebb0a57015ee8ee6a2f7748",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "a7f8d26e653ee43b0b572984b8ec544d3b3b6f3c",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "71dc206f2e2a645dac78879768762451aa1799f7",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "764586f8f6180084c5a7d622120f526acc6ce0c9",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "28ac2dd416482d1c763c4af5d61af465b387fb50",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "43a7d8ae9f645dc00235cfa4bf57673c20b769f8",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            },
            {
              "lessThan": "ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820",
              "status": "affected",
              "version": "09e328e47a695b0d346598f5d6593ee598e64885",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/infiniband/core/ucma.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.10"
            },
            {
              "lessThan": "5.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.270",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.221",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.188",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.157",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.109",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.270",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.221",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.188",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.157",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.109",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.50",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.4",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "5.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ucma: Lock the handler in ucma_set_ib_path()\n\nucma_set_ib_path() calls ucma_event_handler() straight from the write()\npath, without the handler lock that keeps ctx-\u003efile stable while a uevent\nis queued.  The handler re-reads ctx-\u003efile for every dereference:\n\n\tmutex_lock(\u0026ctx-\u003efile-\u003emut);\t\t\t/* file A */\n\tlist_add_tail(\u0026uevent-\u003elist, \u0026ctx-\u003efile-\u003eevent_list);\t/* file B */\n\tmutex_unlock(\u0026ctx-\u003efile-\u003emut);\t\t\t/* file B */\n\twake_up_interruptible(\u0026ctx-\u003efile-\u003epoll_wait);\t/* file B */\n\nA concurrent ucma_migrate_id() reassigns ctx-\u003efile while the SET_OPTION\ncaller sleeps in mutex_lock(), so the list_add_tail() lands on file B\u0027s\nevent_list while only file A\u0027s mutex is held, racing every other user of\nthat list:\n\n  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0\n  Read of size 8 at addr ffff888153c6a418 by task poc_corr/486\n  Call Trace:\n   __list_add_valid_or_report+0x1aa/0x1c0\n   ucma_event_handler+0x1be/0xc00\n   ucma_set_ib_path+0x45e/0x710\n   ucma_set_option+0x32e/0x590\n   ucma_write+0x1f9/0x330\n  Allocated by task 505:\n   ucma_write_cm_event+0x1a1/0x660\n  Freed by task 505:\n   kfree+0x1da/0x4c0\n   ucma_get_event+0x5d5/0x7e0\n\nThe freed object is a ucma_event that another thread dequeued from file B\u0027s\nlist under file B\u0027s mutex.  File A\u0027s mut is left held on top of that,\nwedging its next writer in uninterruptible sleep.\n\nThis path needs a bound and address-resolved cm_id, so it requires an RDMA\ndevice to be present.\n\nTake the handler lock around the call."
        }
      ],
      "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 - The bug is reached only via write() on /dev/infiniband/rdma_cm (SET_OPTION -\u003e ucma_set_option -\u003e ucma_set_ib_path). A remote RDMA peer cannot invoke this path; in-kernel CM event delivery already holds the handler lock that this write path omitted.\nAC:L - The attacker controls both sides of the race: one thread issues SET_OPTION (RDMA_OPTION_IB_PATH) while another MIGRATE_IDs the cm_id to a second fd and a third GET_EVENTs to free the uevent. The window is the mutex_lock() sleep in ucma_event_handler, which the attacker can widen, and it was reproduced by poc_corr.\nPR:L - ucma is a miscdevice with mode 0666 and ucma_write() has no capability check. Any unprivileged local user can open /dev/infiniband/rdma_cm, CREATE_ID, resolve an address on an existing RDMA device, then issue SET_OPTION and MIGRATE_ID.\nUI:N - The attacker opens rdma_cm, creates and migrates their own cm_id, and issues the concurrent SET_OPTION and GET_EVENT writes themselves; no other user or administrator action is required.\nS:U - The use-after-free and list corruption are confined to host-kernel objects (ucma_event and file event_list). This is a standard local kernel compromise and does not cross a VM, IOMMU, or sandbox boundary.\nC:H - The race is a slab use-after-free of struct ucma_event (KASAN in __list_add_valid_or_report after GET_EVENT kfree). Reclaiming the freed object gives the attacker control over list pointers and event contents, enabling disclosure of kernel memory.\nI:H - list_add_tail runs on file B\u0027s event_list while only file A\u0027s mutex is held, corrupting list pointers. Combined with UAF reclaim of ucma_event, this is a classic kernel list-unlink arbitrary-write primitive suitable for control-flow hijacking.\nA:H - The UAF and list_debug BUG can oops the kernel, and the mismatched mutex_unlock leaves file A\u0027s mut held so the next writer sleeps uninterruptibly in D state, hanging the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T08:47:59.672Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/3dd07b369371a2f29e1c3caf1ade85bb92b4c551"
        },
        {
          "url": "https://git.kernel.org/stable/c/b2da0d488a1c72956ebb0a57015ee8ee6a2f7748"
        },
        {
          "url": "https://git.kernel.org/stable/c/a7f8d26e653ee43b0b572984b8ec544d3b3b6f3c"
        },
        {
          "url": "https://git.kernel.org/stable/c/71dc206f2e2a645dac78879768762451aa1799f7"
        },
        {
          "url": "https://git.kernel.org/stable/c/764586f8f6180084c5a7d622120f526acc6ce0c9"
        },
        {
          "url": "https://git.kernel.org/stable/c/28ac2dd416482d1c763c4af5d61af465b387fb50"
        },
        {
          "url": "https://git.kernel.org/stable/c/43a7d8ae9f645dc00235cfa4bf57673c20b769f8"
        },
        {
          "url": "https://git.kernel.org/stable/c/ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820"
        }
      ],
      "title": "RDMA/ucma: Lock the handler in ucma_set_ib_path()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89508",
    "datePublished": "2026-09-11T19:43:54.682Z",
    "dateReserved": "2026-09-11T19:38:34.716Z",
    "dateUpdated": "2026-10-19T08:47:59.672Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-89508",
      "date": "2026-11-09",
      "epss": "0.00126",
      "percentile": "0.02274"
    },
    "microsoft_vex": {
      "current_release_date": "2026-09-15T01:45:54.000Z",
      "cve": "CVE-2026-89508",
      "id": "msrc_CVE-2026-89508",
      "initial_release_date": "2026-09-13T01:02:21.000Z",
      "product_status:known_not_affected": "1",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "RDMA/ucma: Lock the handler in ucma_set_ib_path()",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-89508.json",
      "version": "3"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/infiniband/core/ucma.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "3dd07b369371a2f29e1c3caf1ade85bb92b4c551",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "b2da0d488a1c72956ebb0a57015ee8ee6a2f7748",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "a7f8d26e653ee43b0b572984b8ec544d3b3b6f3c",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "71dc206f2e2a645dac78879768762451aa1799f7",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "764586f8f6180084c5a7d622120f526acc6ce0c9",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "28ac2dd416482d1c763c4af5d61af465b387fb50",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "43a7d8ae9f645dc00235cfa4bf57673c20b769f8",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820",
                    "status": "affected",
                    "version": "09e328e47a695b0d346598f5d6593ee598e64885",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/infiniband/core/ucma.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "5.10"
                  },
                  {
                    "lessThan": "5.10",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.270",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.221",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.188",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.157",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.109",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.50",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.2.*",
                    "status": "unaffected",
                    "version": "7.2.4",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.3",
                    "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\nRDMA/ucma: Lock the handler in ucma_set_ib_path()\n\nucma_set_ib_path() calls ucma_event_handler() straight from the write()\npath, without the handler lock that keeps ctx-\u003efile stable while a uevent\nis queued.  The handler re-reads ctx-\u003efile for every dereference:\n\n\tmutex_lock(\u0026ctx-\u003efile-\u003emut);\t\t\t/* file A */\n\tlist_add_tail(\u0026uevent-\u003elist, \u0026ctx-\u003efile-\u003eevent_list);\t/* file B */\n\tmutex_unlock(\u0026ctx-\u003efile-\u003emut);\t\t\t/* file B */\n\twake_up_interruptible(\u0026ctx-\u003efile-\u003epoll_wait);\t/* file B */\n\nA concurrent ucma_migrate_id() reassigns ctx-\u003efile while the SET_OPTION\ncaller sleeps in mutex_lock(), so the list_add_tail() lands on file B\u0027s\nevent_list while only file A\u0027s mutex is held, racing every other user of\nthat list:\n\n  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0\n  Read of size 8 at addr ffff888153c6a418 by task poc_corr/486\n  Call Trace:\n   __list_add_valid_or_report+0x1aa/0x1c0\n   ucma_event_handler+0x1be/0xc00\n   ucma_set_ib_path+0x45e/0x710\n   ucma_set_option+0x32e/0x590\n   ucma_write+0x1f9/0x330\n  Allocated by task 505:\n   ucma_write_cm_event+0x1a1/0x660\n  Freed by task 505:\n   kfree+0x1da/0x4c0\n   ucma_get_event+0x5d5/0x7e0\n\nThe freed object is a ucma_event that another thread dequeued from file B\u0027s\nlist under file B\u0027s mutex.  File A\u0027s mut is left held on top of that,\nwedging its next writer in uninterruptible sleep.\n\nThis path needs a bound and address-resolved cm_id, so it requires an RDMA\ndevice to be present.\n\nTake the handler lock around the call."
          }
        ],
        "id": "CVE-2026-89508",
        "lastModified": "2026-10-19T09:17:45.060",
        "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": "2026-09-11T20:19:33.143",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/28ac2dd416482d1c763c4af5d61af465b387fb50"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/3dd07b369371a2f29e1c3caf1ade85bb92b4c551"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/43a7d8ae9f645dc00235cfa4bf57673c20b769f8"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/71dc206f2e2a645dac78879768762451aa1799f7"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/764586f8f6180084c5a7d622120f526acc6ce0c9"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/a7f8d26e653ee43b0b572984b8ec544d3b3b6f3c"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/b2da0d488a1c72956ebb0a57015ee8ee6a2f7748"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/ecbe7d36dc2de07e5dfbb4a8ff5b315ab43de820"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Important",
      "current_release_date": "2026-11-04T23:58:09+00:00",
      "cve": "CVE-2026-89508",
      "id": "CVE-2026-89508",
      "initial_release_date": "2026-09-11T00:00:00+00:00",
      "product_status:known_not_affected": "203",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: RDMA/ucma: Lock the handler in ucma_set_ib_path()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89508.json",
      "version": "3"
    }
  }
}

MSRC_CVE-2026-89508

Vulnerability from csaf_microsoft - Published: 2026-09-13 01:02 - Updated: 2026-09-15 01:45

Summary

RDMA/ucma: Lock the handler in ucma_set_ib_path()

Scope

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

CVE-2026-89508

Known not affected: 1 product

Open the full advisory

OESA-2026-4185 (CVE-2026-64189)

Vulnerability from osv_openeuler – Published: 2026-09-30 13:47 – Updated: 2026-09-30 13:47 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

netfilter: ipset: fix race between dump and ip_set_list resize

The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section.

A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free.

The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex().

BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception(CVE-2026-64189)

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

sctp: drop a chunk if its transport was removed

sctp_rcv() resolves the transport once per packet and leaves it in chunk->transport. The lookup reference, or the one sctp_add_backlog() takes if the socket is owned by userspace, keeps it around until the chunk has been processed.

An authenticated ASCONF DEL-IP can remove it in the meantime. sctp_assoc_rm_peer() takes the transport out of the association and calls sctp_transport_free(), which tags it dead and drops the reference the association held. There is a window on both paths: the packet can sit on the socket backlog, and on the direct path the lookup completes before bh_lock_sock().

The DATA chunk in that packet puts the removed transport back into asoc->peer.last_data_from. Once the packet is done that reference goes away and the transport is freed by RCU, so the next delayed SACK carries the pointer into the SACK chunk and sctp_outq_select_transport() reads the freed transport's state.

Drop the chunk in sctp_inq_push(), next to the existing rcvr->dead check. Both paths reach it with the association's socket lock held. The peer retransmits it.(CVE-2026-89478)

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

sctp: stop processing a packet once its association is deleted

sctp_endpoint_bh_rcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference.

A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(), so the association and its transports are freed.

The endpoint loop has no counterpart to the asoc->base.dead check in sctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed transport and is then passed to sctp_do_sm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context.

The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctp_inq_free() releases the chunk on the association receive path.

sctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.(CVE-2026-89479)

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

RDMA/ucma: Lock the handler in ucma_set_ib_path()

ucma_set_ib_path() calls ucma_event_handler() straight from the write() path, without the handler lock that keeps ctx->file stable while a uevent is queued. The handler re-reads ctx->file for every dereference:

mutex_lock(&amp;ctx-&gt;file-&gt;mut);          /* file A */
list_add_tail(&amp;uevent-&gt;list, &amp;ctx-&gt;file-&gt;event_list);  /* file B */
mutex_unlock(&amp;ctx-&gt;file-&gt;mut);            /* file B */
wake_up_interruptible(&amp;ctx-&gt;file-&gt;poll_wait); /* file B */

A concurrent ucma_migrate_id() reassigns ctx->file while the SET_OPTION caller sleeps in mutex_lock(), so the list_add_tail() lands on file B's event_list while only file A's mutex is held, racing every other user of that list:

BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0 Read of size 8 at addr ffff888153c6a418 by task poc_corr/486 Call Trace: __list_add_valid_or_report+0x1aa/0x1c0 ucma_event_handler+0x1be/0xc00 ucma_set_ib_path+0x45e/0x710 ucma_set_option+0x32e/0x590 ucma_write+0x1f9/0x330 Allocated by task 505: ucma_write_cm_event+0x1a1/0x660 Freed by task 505: kfree+0x1da/0x4c0 ucma_get_event+0x5d5/0x7e0

The freed object is a ucma_event that another thread dequeued from file B's list under file B's mutex. File A's mut is left held on top of that, wedging its next writer in uninterruptible sleep.

This path needs a bound and address-resolved cm_id, so it requires an RDMA device to be present.

Take the handler lock around the call.(CVE-2026-89508)

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

RDMA/cxgb4: Cancel reg_work before freeing device on remove

c4iw_uld_state_change() queues reg_work to register the RDMA device. c4iw_remove() can free ctx->dev while this work is pending or running, leaving c4iw_register_device() accessing the freed device.

Cancel reg_work before removing the device. The registration work can tear down ctx->dev when registration fails, so do not unregister or deallocate it again in that case.

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

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

sched/core: Make core-sched flips wait for in-flight selections

Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was.

Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events.

sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.(CVE-2026-89520)

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

mpls: reload header after pskb_may_pull()

mpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop when an MPLS route has multiple nexthops. While walking the MPLS label stack, the hash routine caches hdr for the current label. After finding the bottom-of-stack label, it calls pskb_may_pull() before reading the inner IP header.

If an skb is constructed with the inner IP header in nonlinear data and insufficient tailroom in the linear head, pskb_may_pull() calls pskb_expand_head() to replace the skb head and free the old one. This leaves hdr pointing to freed memory. The IPv6 path can invalidate hdr again when it performs a second pull for the larger header.

The issue was found through static analysis. A reproducer sending a legal Geneve packet through a bareudp/MPLS multipath setup triggered the same KASAN report in 2 of 2 unpatched runs:

BUG: KASAN: slab-use-after-free in mpls_select_multipath Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23

Call Trace: mpls_select_multipath mpls_forward __netif_receive_skb_list_core netif_receive_skb_list_internal napi_complete_done gro_cell_poll __napi_poll net_rx_action

Freed by task 23: kfree pskb_expand_head __pskb_pull_tail mpls_select_multipath

Reload hdr from the current skb head after each successful pull before deriving the inner IPv4 or IPv6 header pointer.(CVE-2026-89555)

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

libnvdimm/labels: Prevent integer overflow in __nd_label_validate()

The on-media namespace index field nslot is a u32 read from the DIMM label storage area. __nd_label_validate() bounds it against the config area size, but sizeof_namespace_label() returns unsigned, so the product nslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before the comparison. A crafted nslot passes the bound and is then used as the loop trip count in nd_label_data_init(), whose memset() walks off the end of the config_size buffer: an out-of-bounds write.

The field is not trusted -- it comes from the medium, or from userspace via ND_CMD_SET_CONFIG_DATA. Evaluate the product in 64-bit so the bound check is exact; conforming labels are unaffected.

The check was safe when introduced by commit 4a826c83db4e ("libnvdimm: namespace indices: read and validate"): it multiplied by sizeof(struct nd_namespace_label), a size_t, so on a 64-bit build the product did not wrap. Commit 564e871aa66f ("libnvdimm, label: add v1.2 nvdimm label definitions") narrowed it to 32 bits when the label size became a runtime value read via sizeof_namespace_label().(CVE-2026-89559)

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

bpf: Disable preemption in __bpf_get_stack

get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and releases its recursion slot via put_callchain_entry() before returning, so nothing keeps the entry reserved while __bpf_get_stack() consumes it below.

A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate_disable() but not preempt_disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->nr with a larger value. copy_len is then computed from the inflated trace->nr and can exceed the caller's buffer, causing an out-of-bounds write in the memcpy() and in the build_id path.

The rcu_read_lock() taken here alone does not prevent this. It is only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does not disable preemption; it merely keeps perf's callchain buffer array alive (freed via call_rcu()) and does nothing to stop another task from reusing the entry.

Disable preemption around obtaining the callchain entry and copying it into the caller's buffer, so the entry cannot be reused underneath us and trace->nr stays bounded by max_depth. Build ID resolution may fault and is therefore deferred until after preemption is re-enabled; by then the instruction pointers have already been copied into buf, so it operates only on that private copy. Note, preempt_disable() also subsumes the buffer-lifetime guarantee the rcu_read_lock() provided, since a preempt-disabled section is an RCU read-side critical section for the callchain buffers' call_rcu() reclaim.

changed Fixes: commit

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

smb: client: clear ce->tgthint in free_tgts()

When free_tgts() frees all structures in ce->tlist, ce->tgthint is left pointing to one of the freed cache_dfs_tgt structures.

If ce->tgthint is not reset before it is used later, it results in a use-after-free.

Set ce->tgthint to NULL in free_tgts() after the elements are freed to reflect that no elements remain.(CVE-2026-89636)

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

ceph: do not repeat ceph_trim_dentries() if no progress possible

ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its nr_to_scan budget. This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (count==0) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns -EAGAIN, only to be queued again immediately.

The dir-lease walk made this worse. When expire_dir_lease is false (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned TOUCH for every valid lease. TOUCH moves the dentry to the tail of the list and resets di->time via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained nr_to_scan, guaranteeing the -EAGAIN requeue.

Fix this in three steps:

Return KEEP instead of TOUCH when expire_dir_lease is false. If we are not going to reclaim the lease, leave it in place instead of churning the list and resetting its timestamp; the walk then terminates naturally (or via STOP at the first fresh lease).
Only return -EAGAIN from the first (dentry-lease) walk when something was actually freed. A full batch that frees nothing means retrying the same list immediately is futile; fall through to the dir-lease walk instead.
After both walks, bail out with success (0) when nothing was freed and there is no cap pressure (count==0). There is no reason to keep retrying when we are not over the cap limit and made no progress.

Under real cap pressure (count>0) the reclaim path is unchanged and still retries via -EAGAIN.

Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers. This is very visible in /proc/lock_stat (5 minute capture):

          class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg

&mdsc->dentry_list_lock: 126180 128218 0.04 8063.44 15986965.20 124.69 1573354 5296812 0.04 8291.28 74164526.48 14.00

&mdsc->dentry_list_lock 111736 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2631 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 3878 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8 &mdsc->dentry_list_lock 9973 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0

&mdsc->dentry_list_lock 123621 [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8 &mdsc->dentry_list_lock 1822 [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 2720 [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0 &mdsc->dentry_list_lock 55 [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8

With this patch:

          class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg

&mdsc->dentry_list_lock: 1203 1215 0.16 408.88 33082.88 27.23 4320501 7357389 0.04 500.64 1961578.00 0.27

&mdsc->dentry_list_lock 1029 [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8 &mdsc->dentry_list_lock 1 ---truncated---(CVE-2026-89647)

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

ceph: cap delegated inode count in ceph_parse_deleg_inos()

ceph_parse_deleg_inos() decodes interval sets of delegated inode numbers from an MDS create-with-delegation reply. For each set it reads a 64-bit start and a 64-bit len with ceph_decode_64_safe(), which only validates that the eight bytes are present in the message, not the value, and then loops over len while inserting entries into s_delegated_inos.

len is fully attacker controlled. A malicious or compromised MDS can send one huge interval, many intervals in one reply, duplicate intervals, or repeated replies that accumulate delegated inodes on the same session. The original code bounded none of these and could spin the insert loop or grow the xarray without limit.

Bound both dimensions with a single enforcement point. Track the number of delegated inodes held by each MDS session in an atomic counter and grow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless() to refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper is the only place the counter grows, the per-session population can never exceed the cap, so no separate per-session pre-check is needed. The counter is decremented when async create consumes a delegated inode or when an insert fails, incremented when a delegated inode is restored, initialized with the session xarray, and reset when reconnect destroys the xarray.

A per-session cap alone still lets one reply spin the insert loop on duplicate ranges without growing the counter, so also cap the aggregate interval length accepted from a single reply. Together these bound both the loop trip count per reply and the xarray population across replies.

The cap is a fixed, client-chosen constant rather than a value derived from the MDS. mds_client_prealloc_inos is a userspace MDS configuration option; it is never sent to the kernel client on the wire, and a server-supplied bound could not be trusted for a defensive limit in any case. The constant is set well above that option's documented default of 1000 (a generous multiple), so legitimate refill behavior is unaffected while the CPU and xarray memory a malformed delegation stream can consume stays bounded.

Impact: a malicious or compromised Ceph MDS can no longer make a client spin through an unbounded delegated-inode interval or grow one session's delegated-inode xarray without limit.(CVE-2026-89648)

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

libceph: reject buckets with mismatched CRUSH ids

crush_decode() stores bucket data by array slot, and the mapper later derives the per-bucket workspace index from the decoded bucket id. A malformed map can therefore make one bucket reuse another bucket's workspace by encoding an id different from -1 - slot.

For uniform buckets, the second replica selection expands the source bucket's permutation into that aliased workspace buffer. If the source bucket is larger than the aliased bucket, the write runs past the smaller permutation array and can escape the kvmalloc'd CRUSH workspace. KASAN reports a slab OOB write of 4 bytes in bucket_perm_choose().

Reject buckets whose encoded id does not match their array slot. Valid CRUSH maps already use the canonical negative id corresponding to the bucket slot, so this restores the invariant expected by work->work[-1 - in->id] without changing valid map behavior.(CVE-2026-89656)

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

apparmor: fix out-of-bounds write when null terminating a label vec

aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE is passed. If the components are all distinct no duplicates are dropped, dups is 0 and the terminator goes to vec[n], so the caller has to provide room for n + 1 entries.

aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len, gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES it uses the local array of LOCAL_VEC_ENTRIES pointers, above that it allocates exactly len pointers. The terminator therefore lands one entry past the end of the local array when len is LOCAL_VEC_ENTRIES, and one entry past the end of the allocation when len is larger.

len comes from the number of "//&" separated components in the label name and label_count_strn_entries() does not bound it. An unprivileged task reaches the parse by writing to /proc/self/attr/apparmor/current or through lsm_set_self_attr(2), both of which go through do_setattr(), and the name is parsed before the change_profile permission is checked. The query_label() path behind the securityfs .access file, which is mode 0666, performs no permission check at all. Every component has to resolve to a loaded profile, so a system with policy loaded is required.

The other two VEC_FLAG_TERMINATE users work on a label vec that aa_label_alloc() has already sized with "+ 1 for null terminator entry on vec". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing len + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of the local array and into kzalloc().(CVE-2026-89761)

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

apparmor: fix cred UAF caused by begin_current_label_crit_section()

AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label.

The first problem with this is that it would directly lead to UAF of struct cred if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so:

const struct cred *cred = current_cred();
alloc_file_pseudo(...);
uid_t uid = cred-&gt;euid;

I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF.

The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if current_cred() != current_real_cred() (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds.

So in approximately the following scenario, things go wrong:

task begins with <creds A> (as both objective and subjective creds), with refcount=2
task grabs an extra reference on <creds A> for overriding
task calls override_creds(<creds A>), which returns a pointer to the old subjective creds (<creds A>)
task enters AppArmor LSM hook
AppArmor checks that objective/subjective creds are equal
AppArmor replaces both cred pointers with <creds B> and drops 2 refs on <creds A>
task leaves AppArmor LSM hook
task calls revert_creds(<creds A>)
now task->cred is <creds A> while task->real_cred is <creds B>, but the task_struct logically holds two references to <creds B>
another task drops the extra reference on <creds A> that was used for overriding, refcount drops to 0
now task->real_cred points to freed creds

At this point, any access to current_cred() will be UAF.

I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat.

To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.)

Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write().

There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious.(CVE-2026-89762)

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

KEYS: trusted: Fix TPM teardown ordering

trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() takes it for writing. It therefore provides the synchronization point that must precede backend teardown.

The current order permits this interleaving:

CPU 0 CPU 1 trusted_tpm_exit() key_type_lookup("trusted") put_device(&chip->dev) trusted_tpm_seal() kfree(digests) pcrlock() unregister_key_type() tpm_pcr_extend(..., digests)

CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it.

KASAN reported:

BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trusted_tpm_seal+0x1b6/0x570 [trusted] trusted_instantiate+0x293/0x340 [trusted] __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 Allocated by task 88: __kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [trusted] __do_sys_delete_module+0x346/0x510

Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed.(CVE-2026-89763)

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

Bluetooth: SCO: hold sk properly in sco_conn_ready

sk deref in sco_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk and parent sk is currently accessed without either, and without checking parent->sk_state:

[Task 1]            [Task 2]
                    sco_sock_release
sco_conn_ready
  sk = conn-&gt;sk
                      lock_sock(sk)
                        conn-&gt;sk = NULL
  lock_sock(sk)
                      release_sock(sk)
                      sco_sock_kill(sk)
   UAF on sk deref

and similarly for access to sco_get_sock_listen() return value.

Fix possible UAF by holding sk refcount in sco_conn_ready() and making sco_get_sock_listen() increase refcount. Also recheck after lock_sock that the socket is still valid. Adjust conn->sk locking so it's protected also by lock_sock() of the associated socket if any.(CVE-2026-89774)

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

bpf: Disable preemption in bpf_get_stackid

The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer.

Note the bpf_get_stackid_pe function is executed already with preemption disabled.(CVE-2026-89799)

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

media: saa7164: fix cleanup on resource allocation failure

saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions.

If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list.

Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning.

Also release BAR0 if it was successfully requested but the BAR2 request fails.(CVE-2026-89877)

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

media: cx231xx: reject geometry changes while the VBI queue is busy

vidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide dev->width / dev->norm but only refuse the change when the video queue (dev->vidq) is busy. The VBI queue (dev->vbiq) shares that same geometry: cx231xx_init_vbi_isoc() latches dma_q->lines_per_field from dev->norm, the VBI videobuf2 plane is sized from dev->width / dev->norm in vbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then recomputes the destination offset from the live dev->width and the latched lines_per_field on every URB completion:

offset = lines_completed * (dev-&gt;width &lt;&lt; 1) + ...;
if (dma_q-&gt;current_field == 2)
    offset += dev-&gt;width * 2 * dma_q-&gt;lines_per_field;
memcpy(plane + offset, p_buffer, lencopy);

Because the VBI node shares video_ioctl_ops with the video node, an application can size a small VBI plane (REQBUFS/QBUF with a small width, or with the NTSC standard), then enlarge dev->width (or switch dev->norm to PAL) through the video node while the VBI stream is running -- the change is allowed because only dev->vidq is checked -- and let the device deliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the offset with the larger geometry and memcpy()s past the end of the smaller plane that was already allocated, a heap out-of-bounds write whose offset is attacker-chosen and whose contents come from the device. The per-field guard in cx231xx_copy_vbi_line() does not help: it bounds the copy against the latched lines_per_field, not the plane's real capacity, and vb2 does not re-run buf_prepare() for an already prepared buffer.

Refuse the format/standard change when the VBI queue is busy as well, so the geometry cannot change underneath an allocated VBI buffer.(CVE-2026-89894)

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

media: cec: Serialize exclusive follower delivery

cec_receive_notify() reads the exclusive follower pointer without the adapter lock. Serialize the no-follower check and message delivery against mode changes and release.(CVE-2026-89897)

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

media: cec: disable delayed work before freeing an interrupted transmit

cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending:

ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout

Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.(CVE-2026-89899)

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

nvmet-tcp: reject unsolicited H2CData PDUs

nvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking that its TTAG is a valid in-range command index and that the command's data buffers are mapped. It never checks that the target has actually solicited that data by sending an R2T for the command.

A remote host can abuse this. It submits a write command that takes the R2T path and, before the target transmits the R2T, sends an H2CData PDU for that command's tag. The data completes the command early, and when the command then fails synchronously (e.g. a length mismatch caught by nvmet_check_transfer_len()), it is completed a second time. Each completion calls nvmet_tcp_queue_response(), so the same command is added to queue->resp_list twice while it is still linked; the second llist_add() makes the node point to itself (lentry->next == lentry).

nvmet_tcp_process_resp_list() then walks that self-referential node and adds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this trips the "list_add double add" check (kernel BUG); without it the loop never terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is remotely triggerable and needs no authentication on an allow_any_host subsystem.

Track whether an R2T has been transmitted for a command and reject an H2CData PDU that arrives before it. The flag is cleared on command reuse (nvmet_tcp_get_cmd() zeroes cmd->flags) and stays set across the multiple H2CData PDUs of a single solicited transfer.(CVE-2026-89968)

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

nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU

nvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as

queue-&gt;left = hdr-&gt;hlen - queue-&gt;offset + hdgst;

and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu).

A struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmet_tcp_pdu_size() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdr_digest and queue->data_digest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer.

Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.(CVE-2026-89969)

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

nvme: add missing SRCU grace period in error path

nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs.

The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.(CVE-2026-89972)

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

kprobes: Protect kprobe_blacklist with RCU

__within_kprobe_blacklist() traverses kprobe_blacklist without holding kprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist() removes blacklist entries and immediately frees them with kfree(). A concurrent call to within_kprobe_blacklist() can therefore dereference freed memory.

Furthermore, within_kprobe_blacklist() can be called in atomic or non-preemptible contexts where the sleeping kprobe_mutex cannot be taken.

Protect kprobe_blacklist with RCU. Use guard(rcu)() and list_for_each_entry_rcu() for traversal, list_add_tail_rcu() for insertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim entries safely after a grace period.(CVE-2026-89988)

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

ftrace: Take trace_array reference before accessing its ftrace_ops

The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel.

Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used.

This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is.(CVE-2026-90002)

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

scsi: target: iscsi: Reserve a terminator byte for the login payload

iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where

padding = ((-payload_length) &amp; 3);

any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator.

The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered.

Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.(CVE-2026-90011)

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

NFSD: Prevent client use-after-free during blocked-lock reaping

A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory.

Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.(CVE-2026-90036)

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

NFSD: Prevent client use-after-free during close_lru reaping

An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock.

Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.(CVE-2026-90037)

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

Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan

For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read.

[Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref)

Task 1 may observe NULL which causes null-ptr-deref.

Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL.

Clarify code comments vs. locking.(CVE-2026-90091)

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

bpf: Fix potential UAF when reading bpf link info

In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue.

Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields.(CVE-2026-90392)

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

IB/isert: reject login PDUs declaring more data than was received

isert_login_recv_done() records how many bytes the HCA actually placed in the login buffer, but nothing compares that against the length the login PDU's BHS declares. isert_rx_login_req() copies min(login_req_len, MAX_KEY_VALUE_PAIRS) bytes into login->req_buf, and the login code then reads the declared length back out of that buffer - for the first PDU in iscsi_target_locate_portal(),

payload_length = ntoh24(login_req-&gt;dlength);
tmpbuf = kmemdup_nul(login-&gt;req_buf, payload_length, GFP_KERNEL);

and for the ones after it in iscsi_decode_text_input(), reached from iscsi_target_do_login().

login->req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so an initiator that declares more than it sends reads off the end of it, before authentication and with the length under its control:

BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167 __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_target_locate_portal+0x48d/0x1180 iscsi_target_login_thread+0x19a9/0x3350 Allocated by task 167: __kmalloc_cache_noprof+0x158/0x370 iscsi_target_login_thread+0x971/0x3350 which belongs to the cache kmalloc-8k of size 8192 allocated 8192-byte region

Falsifying the second login PDU instead reaches the other reader, on the same buffer:

BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80 Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50 Workqueue: isert_login_wq iscsi_target_do_login_rx __asan_memcpy+0x23/0x60 kmemdup_nul+0x43/0x80 iscsi_decode_text_input+0xc6/0x11c0 iscsi_target_do_login+0x261/0x1470 iscsi_target_do_login_rx+0x51d/0x7d0

iscsit over TCP is not exposed: iscsit_get_login_rx() validates the declared length with iscsi_target_check_login_request() and then reads exactly that many bytes off the socket, so the declared length governs how much arrives rather than how much is copied out of an already-filled buffer. isert does not call iscsi_target_check_login_request() at all.

Reject a login PDU whose declared DataSegmentLength exceeds what was received, in both paths that reach isert_rx_login_req(): isert_get_login_rx() for the first login PDU and isert_login_recv_done() for the ones after it. dlength <= login_req_len is allowed because the received count can include up to three bytes of iSCSI padding.

Once the check is in place the copy out can no longer exceed the copy in: the posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is login_req_len.

Like the existing short-PDU check added by 29e7b925ae6d, the reject in isert_login_recv_done() returns without completing login_req_comp, so a malformed subsequent PDU leaves the login to be torn down by the login timer rather than failing immediately. The first-PDU path returns an error and fails straight away.

Reproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an initiator that sends the real key=value payload while declaring 8193 in the BHS, on the first login PDU and on the second in separate runs. The reported read size tracks the declared value exactly; 16384 and 61440 behave the same. Unpatched 3 of 3 runs report on each of the two paths, patched 0 of 3 on both, run alternately in a single session, and a normal login still completes on the patched build.(CVE-2026-90413)

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

IB/isert: reject PDUs declaring more data than was received

isert_recv_done() hands each received PDU to the opcode handlers without ever looking at wc->byte_len, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsol_data_len / imm_data_len) - out of the fixed-size descriptor:

isert_handle_iscsi_dataout(): sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc), unsol_data_len); isert_handle_scsi_cmd(): sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents, isert_get_data(rx_desc), imm_data_len);

Because the declared length is never checked against wc->byte_len, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer.

Nothing upstream of isert closes this door:

__iscsit_check_dataout_hdr() bounds the inbound payload against conn_ops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check.
iscsi_set_connection_parameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsi_check_acceptor_state(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling.
isert never clamps the negotiated value to its own fixed receive descriptor (ISER_RX_SIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated.

The imm_data_len == data_len path is more than an over-read: it aliases the receive descriptor via sg_set_buf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated.

Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN:

BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ib_cq_poll_work Call Trace: sg_copy_buffer+0x150/0x1c0 isert_recv_done+0xba6/0x2390 __ib_process_cq+0xe1/0x390 ib_cq_poll_work+0x46/0x150

isert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout() (ib_isert.c:1160), inlined through isert_rx_opcode().

Validate wc->byte_len against the framing in isert_recv_done() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISER_HEADERS_LEN (commit 29e7b925ae6d ("IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all.

isert reads the data segment from a fixed offset: isert_get_data() returns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum against wc->byte_len bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---(CVE-2026-90414)

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

hfsplus: validate thread record before delete key rebuild

hfsplus_delete_cat() is called with str == NULL when the last open reference to an unlinked HFS+ hardlink backing inode is closed. In that case, the function finds the catalog thread by CNID and rebuilds the catalog key from thread.nodeName.

That reconstruction path reads thread.nodeName.length directly from the catalog B-tree into fd.search_key and then copies length * 2 bytes into fd.search_key->cat.name.unicode. It does not first check that the found record is a thread record or that its size matches the thread name.

A corrupted image can therefore provide an oversized thread name length and make hfs_bnode_read() write past the catalog search-key allocation.

Read the CNID record through hfsplus_brec_read_cat(), which bounds the record read to sizeof(hfsplus_cat_entry) and verifies that a thread record's size exactly matches nodeName.length. Together, these checks ensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread records before building the delete key from the validated thread name.

Share the thread-record-type helper between hfsplus_find_cat() and hfsplus_delete_cat().(CVE-2026-93095)

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

RDMA/hfi1: Preserve unit 0 on allocation failure

hfi1_free_devdata() assumes that the device was inserted into the unit table and unconditionally erases dd->unit. If xa_alloc_irq() fails, the zero-initialized unit remains zero, so full cleanup can remove an unrelated device from index 0.

Release only the rdmavt allocation and return immediately while the unit table has not acquired the device.(CVE-2026-93103)

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

RDMA/rvt: Return NULL after port allocation failure

rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free.

Return NULL immediately after deallocation so callers can propagate the allocation failure.(CVE-2026-93104)

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

bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux

bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the bpf_verifier_lock, but publishes the result through a plain store and re-checks it through a plain lockless load. Nothing orders the stores initializing the struct btf inside btf_parse_vmlinux() against the store publishing the pointer: On a weakly ordered arch, a concurrent first-time caller taking the lockless fast path could in principle observe the pointer before the parsed contents are visible. The mutex_unlock() does not help such a reader given it only synchronizes with a later acquisition of the same lock. Thus, publish the pointer with smp_store_release() and read it on the fast path with smp_load_acquire().

Acquire semantics are needed rather than a dependency-ordered READ_ONCE(): btf_parse_vmlinux() also populates globals outside the returned object (e.g. bpf_ctx_convert.t). An address dependency would only order accesses performed through the pointer and not cover other globals.(CVE-2026-93138)

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

HID: core: quiesce input in hid_hw_stop() to prevent use-after-free

A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver.

Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:

drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c

Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect().

For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged.

No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.(CVE-2026-93189)

Severity

9.8 (Critical)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64189	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89478	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89479	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89508	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89510	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89520	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89555	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89559	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89580	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89636	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89647	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89648	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89656	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89761	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89762	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89763	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89774	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89799	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89877	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89894	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89897	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89899	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89968	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89969	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89972	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-89988	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90002	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90011	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90036	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90037	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90091	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90392	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90413	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-90414	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93095	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93103	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93104	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93138	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-93189	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-335.0.0.236.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-335.0.0.236.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-335.0.0.236.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: fix race between dump and ip_set_list resize\n\nThe release path of ip_set_dump_do() and ip_set_dump_done() read\ninst-\u0026gt;ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()\nof the array pointer. These run from netlink_recvmsg() without the nfnl\nmutex and without an RCU read-side critical section.\n\nA concurrent ip_set_create() can grow the array: it publishes the new\narray, calls synchronize_net() and then kvfree()s the old one. Since the\ndump paths read the array outside any RCU reader, synchronize_net() does\nnot wait for them and the old array can be freed while they still index\ninto it, causing a use-after-free.\n\nThe dumped set itself stays pinned via set-\u0026gt;ref_netlink, so only the\narray load needs protecting. Take rcu_read_lock() around it, matching\nip_set_get_byname() and __ip_set_put_byindex().\n\n  BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)\n  Read of size 8 at addr ffff88800b5c4018 by task exploit/150\n  Call Trace:\n   ...\n   kasan_report (mm/kasan/report.c:595)\n   ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)\n   netlink_dump (net/netlink/af_netlink.c:2325)\n   netlink_recvmsg (net/netlink/af_netlink.c:1976)\n   sock_recvmsg (net/socket.c:1159)\n   __sys_recvfrom (net/socket.c:2315)\n   ...\n  Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI\n  KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7]\n  RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)\n  Kernel panic - not syncing: Fatal exception(CVE-2026-64189)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: drop a chunk if its transport was removed\n\nsctp_rcv() resolves the transport once per packet and leaves it in\nchunk-\u0026gt;transport. The lookup reference, or the one sctp_add_backlog() takes\nif the socket is owned by userspace, keeps it around until the chunk has\nbeen processed.\n\nAn authenticated ASCONF DEL-IP can remove it in the meantime.\nsctp_assoc_rm_peer() takes the transport out of the association and calls\nsctp_transport_free(), which tags it dead and drops the reference the\nassociation held. There is a window on both paths: the packet can sit on\nthe socket backlog, and on the direct path the lookup completes before\nbh_lock_sock().\n\nThe DATA chunk in that packet puts the removed transport back into\nasoc-\u0026gt;peer.last_data_from. Once the packet is done that reference goes\naway and the transport is freed by RCU, so the next delayed SACK carries\nthe pointer into the SACK chunk and sctp_outq_select_transport() reads the\nfreed transport\u0026apos;s state.\n\nDrop the chunk in sctp_inq_push(), next to the existing rcvr-\u0026gt;dead check.\nBoth paths reach it with the association\u0026apos;s socket lock held. The peer\nretransmits it.(CVE-2026-89478)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: stop processing a packet once its association is deleted\n\nsctp_endpoint_bh_rcv() looks the association up only when chunk-\u0026gt;asoc is\nNULL, and caches the result in chunk-\u0026gt;asoc and chunk-\u0026gt;transport without\ntaking a reference.\n\nA packet that matches no association is handed to the endpoint, so a peer\ncan bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The\nCOOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and\nwith the outqueue empty the SHUTDOWN ACK reaches sctp_sf_do_9_2_final(),\nso the association and its transports are freed.\n\nThe endpoint loop has no counterpart to the asoc-\u0026gt;base.dead check in\nsctp_assoc_bh_rcv(). The next chunk writes to last_time_heard in the freed\ntransport and is then passed to sctp_do_sm() with the freed association.\nThe transport is freed through RCU, so this needs the packet to come off\nthe socket backlog, where the loop runs in task context.\n\nThe endpoint loop cannot do the same check: it holds no reference on the\nassociation, so reading asoc-\u0026gt;base.dead would itself be a use-after-free.\nMark the packet for discard in the command interpreter, just before it\ndeletes the association. That is also before sctp_inq_free() releases the\nchunk on the association receive path.\n\nsctp_sf_do_5_2_4_dupcook() issues SCTP_CMD_DELETE_TCB for the temporary\nassociation, while the one the packet belongs to stays alive. A restarting\npeer can bundle DATA behind its COOKIE ECHO, so compare against\nchunk-\u0026gt;asoc and leave that case alone.(CVE-2026-89479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ucma: Lock the handler in ucma_set_ib_path()\n\nucma_set_ib_path() calls ucma_event_handler() straight from the write()\npath, without the handler lock that keeps ctx-\u0026gt;file stable while a uevent\nis queued.  The handler re-reads ctx-\u0026gt;file for every dereference:\n\n\tmutex_lock(\u0026amp;ctx-\u0026gt;file-\u0026gt;mut);\t\t\t/* file A */\n\tlist_add_tail(\u0026amp;uevent-\u0026gt;list, \u0026amp;ctx-\u0026gt;file-\u0026gt;event_list);\t/* file B */\n\tmutex_unlock(\u0026amp;ctx-\u0026gt;file-\u0026gt;mut);\t\t\t/* file B */\n\twake_up_interruptible(\u0026amp;ctx-\u0026gt;file-\u0026gt;poll_wait);\t/* file B */\n\nA concurrent ucma_migrate_id() reassigns ctx-\u0026gt;file while the SET_OPTION\ncaller sleeps in mutex_lock(), so the list_add_tail() lands on file B\u0026apos;s\nevent_list while only file A\u0026apos;s mutex is held, racing every other user of\nthat list:\n\n  BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x1aa/0x1c0\n  Read of size 8 at addr ffff888153c6a418 by task poc_corr/486\n  Call Trace:\n   __list_add_valid_or_report+0x1aa/0x1c0\n   ucma_event_handler+0x1be/0xc00\n   ucma_set_ib_path+0x45e/0x710\n   ucma_set_option+0x32e/0x590\n   ucma_write+0x1f9/0x330\n  Allocated by task 505:\n   ucma_write_cm_event+0x1a1/0x660\n  Freed by task 505:\n   kfree+0x1da/0x4c0\n   ucma_get_event+0x5d5/0x7e0\n\nThe freed object is a ucma_event that another thread dequeued from file B\u0026apos;s\nlist under file B\u0026apos;s mutex.  File A\u0026apos;s mut is left held on top of that,\nwedging its next writer in uninterruptible sleep.\n\nThis path needs a bound and address-resolved cm_id, so it requires an RDMA\ndevice to be present.\n\nTake the handler lock around the call.(CVE-2026-89508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cxgb4: Cancel reg_work before freeing device on remove\n\nc4iw_uld_state_change() queues reg_work to register the RDMA device.\nc4iw_remove() can free ctx-\u0026gt;dev while this work is pending or running,\nleaving c4iw_register_device() accessing the freed device.\n\nCancel reg_work before removing the device.  The registration work can\ntear down ctx-\u0026gt;dev when registration fails, so do not unregister or\ndeallocate it again in that case.\n\nThis issue was found by an in-house static analysis tool.(CVE-2026-89510)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Make core-sched flips wait for in-flight selections\n\nCore scheduling\u0026apos;s pick_next_task() operates on all sibling rqs under one\nacquisition of the shared core-wide lock. A -\u0026gt;pick_task() that releases the\nrq lock leaves every sibling __lock momentarily free, letting\n__sched_core_flip(false) complete mid-selection and rebind rq_lockp() under\nit. The selection resumes on the split locks, touching sibling state it no\nlonger protects, and __schedule() finally releases a lock that was never\ntaken while leaking the one that was.\n\nCount in-flight core-wide selections in the leader\u0026apos;s rq-\u0026gt;core_pick_in_flight\nand make __sched_core_flip() wait for the count to drain. The count only\nchanges under the shared lock, which the flip holds while sampling, so no\nother ordering is needed. The wait can repeat while selections overlap, but\nthe flip backs off between samples and flips are rare cookie-lifetime\nevents.\n\nsched_core_cpu_deactivate() moves the count to the new leader - a stale copy\nleft behind would bias it forever if that CPU later returns as its own\nleader.(CVE-2026-89520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmpls: reload header after pskb_may_pull()\n\nmpls_select_multipath() calls mpls_multipath_hash() to choose a nexthop\nwhen an MPLS route has multiple nexthops.  While walking the MPLS label\nstack, the hash routine caches hdr for the current label.  After finding\nthe bottom-of-stack label, it calls pskb_may_pull() before reading the\ninner IP header.\n\nIf an skb is constructed with the inner IP header in nonlinear data and\ninsufficient tailroom in the linear head, pskb_may_pull() calls\npskb_expand_head() to replace the skb head and free the old one.  This\nleaves hdr pointing to freed memory.  The IPv6 path can invalidate hdr\nagain when it performs a second pull for the larger header.\n\nThe issue was found through static analysis.  A reproducer sending a legal\nGeneve packet through a bareudp/MPLS multipath setup triggered the same\nKASAN report in 2 of 2 unpatched runs:\n\n  BUG: KASAN: slab-use-after-free in mpls_select_multipath\n  Read of size 1 at addr ffff88800ecc6e20 by task ksoftirqd/1/23\n\n  Call Trace:\n   mpls_select_multipath\n   mpls_forward\n   __netif_receive_skb_list_core\n   netif_receive_skb_list_internal\n   napi_complete_done\n   gro_cell_poll\n   __napi_poll\n   net_rx_action\n\n  Freed by task 23:\n   kfree\n   pskb_expand_head\n   __pskb_pull_tail\n   mpls_select_multipath\n\nReload hdr from the current skb head after each successful pull before\nderiving the inner IPv4 or IPv6 header pointer.(CVE-2026-89555)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Prevent integer overflow in __nd_label_validate()\n\nThe on-media namespace index field nslot is a u32 read from the DIMM\nlabel storage area.  __nd_label_validate() bounds it against the config\narea size, but sizeof_namespace_label() returns unsigned, so the product\nnslot * label_size is evaluated in 32-bit and wraps modulo 2^32 before\nthe comparison.  A crafted nslot passes the bound and is then used as the\nloop trip count in nd_label_data_init(), whose memset() walks off the end\nof the config_size buffer: an out-of-bounds write.\n\nThe field is not trusted -- it comes from the medium, or from userspace\nvia ND_CMD_SET_CONFIG_DATA.  Evaluate the product in 64-bit so the bound\ncheck is exact; conforming labels are unaffected.\n\nThe check was safe when introduced by commit 4a826c83db4e (\u0026quot;libnvdimm:\nnamespace indices: read and validate\u0026quot;): it multiplied by sizeof(struct\nnd_namespace_label), a size_t, so on a 64-bit build the product did not\nwrap.  Commit 564e871aa66f (\u0026quot;libnvdimm, label: add v1.2 nvdimm label\ndefinitions\u0026quot;) narrowed it to 32 bits when the label size became a runtime\nvalue read via sizeof_namespace_label().(CVE-2026-89559)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable preemption in __bpf_get_stack\n\nget_perf_callchain() returns a per-CPU perf_callchain_entry buffer and\nreleases its recursion slot via put_callchain_entry() before returning,\nso nothing keeps the entry reserved while __bpf_get_stack() consumes\nit below.\n\nA preemptible BPF program (e.g. a non-sleepable raw tracepoint program\non a PREEMPT kernel, which runs under migrate_disable() but not\npreempt_disable()) can be scheduled out between obtaining the entry\nand the copy. Another task scheduled on the same CPU then reuses the\nsame per-CPU buffer and overwrites trace-\u0026gt;nr with a larger value.\ncopy_len is then computed from the inflated trace-\u0026gt;nr and can exceed\nthe caller\u0026apos;s buffer, causing an out-of-bounds write in the memcpy()\nand in the build_id path.\n\nThe rcu_read_lock() taken here alone does not prevent this. It is\nonly taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does\nnot disable preemption; it merely keeps perf\u0026apos;s callchain buffer array\nalive (freed via call_rcu()) and does nothing to stop another task\nfrom reusing the entry.\n\nDisable preemption around obtaining the callchain entry and copying\nit into the caller\u0026apos;s buffer, so the entry cannot be reused underneath\nus and trace-\u0026gt;nr stays bounded by max_depth. Build ID resolution may\nfault and is therefore deferred until after preemption is re-enabled;\nby then the instruction pointers have already been copied into buf,\nso it operates only on that private copy. Note, preempt_disable() also\nsubsumes the buffer-lifetime guarantee the rcu_read_lock() provided,\nsince a preempt-disabled section is an RCU read-side critical section\nfor the callchain buffers\u0026apos; call_rcu() reclaim.\n\n\n[ changed Fixes: commit ](CVE-2026-89580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: clear ce-\u0026gt;tgthint in free_tgts()\n\nWhen free_tgts() frees all structures in ce-\u0026gt;tlist, ce-\u0026gt;tgthint\nis left pointing to one of the freed cache_dfs_tgt structures.\n\nIf ce-\u0026gt;tgthint is not reset before it is used later, it results\nin a use-after-free.\n\nSet ce-\u0026gt;tgthint to NULL in free_tgts() after the elements are\nfreed to reflect that no elements remain.(CVE-2026-89636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: do not repeat ceph_trim_dentries() if no progress possible\n\nceph_cap_reclaim_work() re-queues itself for as long as\nceph_trim_dentries() returns -EAGAIN, which happens whenever a lease\nwalk exhausts its `nr_to_scan` budget.  This creates a busy loop that\nconsumes CPU without making any progress when there is nothing to\nreclaim: with no cap pressure (`count==0`) and every scanned lease\nstill valid, each pass runs the full scan budget down to zero and\nreturns `-EAGAIN`, only to be queued again immediately.\n\nThe dir-lease walk made this worse.  When `expire_dir_lease` is\n`false` (i.e. we have no intention of reclaiming dir leases),\n__dir_lease_check() returned `TOUCH` for every valid lease.  `TOUCH`\nmoves the dentry to the tail of the list and resets `di-\u0026gt;time` via\n__dentry_dir_lease_touch(), so a walk over N valid leases pointlessly\nrewrote the list, refreshed the timestamps (preventing them from ever\naging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN`\nrequeue.\n\nFix this in three steps:\n\n - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is\n   `false`.  If we are not going to reclaim the lease, leave it in\n   place instead of churning the list and resetting its timestamp; the\n   walk then terminates naturally (or via `STOP` at the first fresh\n   lease).\n\n - Only return `-EAGAIN` from the first (dentry-lease) walk when something\n   was actually freed.  A full batch that frees nothing means retrying\n   the same list immediately is futile; fall through to the dir-lease\n   walk instead.\n\n - After both walks, bail out with success (0) when nothing was freed\n   and there is no cap pressure (`count==0`).  There is no reason to\n   keep retrying when we are not over the cap limit and made no\n   progress.\n\nUnder real cap pressure (`count\u0026gt;0`) the reclaim path is unchanged and\nstill retries via `-EAGAIN`.\n\nWithout this patch, I saw 500 ceph_trim_dentries() calls per second on\nour web servers.  This is very visible in `/proc/lock_stat` (5 minute\ncapture):\n\n              class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg\n\n \u0026amp;mdsc-\u0026gt;dentry_list_lock:        126180         128218           0.04        8063.44    15986965.20         124.69        1573354        5296812           0.04        8291.28    74164526.48          14.00\n -----------------------\n \u0026amp;mdsc-\u0026gt;dentry_list_lock         111736          [\u0026lt;000000007b11e319\u0026gt;] __ceph_dentry_dir_lease_touch+0x7c/0xa8\n \u0026amp;mdsc-\u0026gt;dentry_list_lock           2631          [\u0026lt;0000000050597999\u0026gt;] __dentry_leases_walk+0x64/0x2c8\n \u0026amp;mdsc-\u0026gt;dentry_list_lock           3878          [\u0026lt;00000000c0022f62\u0026gt;] __ceph_dentry_lease_touch+0x5c/0xa8\n \u0026amp;mdsc-\u0026gt;dentry_list_lock           9973          [\u0026lt;000000002f27cb6f\u0026gt;] __dentry_lease_unlist+0x50/0xa0\n -----------------------\n \u0026amp;mdsc-\u0026gt;dentry_list_lock         123621          [\u0026lt;0000000050597999\u0026gt;] __dentry_leases_walk+0x64/0x2c8\n \u0026amp;mdsc-\u0026gt;dentry_list_lock           1822          [\u0026lt;000000007b11e319\u0026gt;] __ceph_dentry_dir_lease_touch+0x7c/0xa8\n \u0026amp;mdsc-\u0026gt;dentry_list_lock           2720          [\u0026lt;000000002f27cb6f\u0026gt;] __dentry_lease_unlist+0x50/0xa0\n \u0026amp;mdsc-\u0026gt;dentry_list_lock             55          [\u0026lt;00000000c0022f62\u0026gt;] __ceph_dentry_lease_touch+0x5c/0xa8\n\nWith this patch:\n\n              class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg\n\n \u0026amp;mdsc-\u0026gt;dentry_list_lock:          1203           1215           0.16         408.88       33082.88          27.23        4320501        7357389           0.04         500.64     1961578.00           0.27\n -----------------------\n \u0026amp;mdsc-\u0026gt;dentry_list_lock           1029          [\u0026lt;000000003c9aea8a\u0026gt;] __ceph_dentry_dir_lease_touch+0x7c/0xa8\n \u0026amp;mdsc-\u0026gt;dentry_list_lock            1\n---truncated---(CVE-2026-89647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: cap delegated inode count in ceph_parse_deleg_inos()\n\nceph_parse_deleg_inos() decodes interval sets of delegated inode numbers\nfrom an MDS create-with-delegation reply. For each set it reads a 64-bit\nstart and a 64-bit len with ceph_decode_64_safe(), which only validates\nthat the eight bytes are present in the message, not the value, and then\nloops over len while inserting entries into s_delegated_inos.\n\nlen is fully attacker controlled. A malicious or compromised MDS can send\none huge interval, many intervals in one reply, duplicate intervals, or\nrepeated replies that accumulate delegated inodes on the same session.\nThe original code bounded none of these and could spin the insert loop or\ngrow the xarray without limit.\n\nBound both dimensions with a single enforcement point. Track the number\nof delegated inodes held by each MDS session in an atomic counter and\ngrow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless()\nto refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper\nis the only place the counter grows, the per-session population can never\nexceed the cap, so no separate per-session pre-check is needed. The\ncounter is decremented when async create consumes a delegated inode or\nwhen an insert fails, incremented when a delegated inode is restored,\ninitialized with the session xarray, and reset when reconnect destroys\nthe xarray.\n\nA per-session cap alone still lets one reply spin the insert loop on\nduplicate ranges without growing the counter, so also cap the aggregate\ninterval length accepted from a single reply. Together these bound both\nthe loop trip count per reply and the xarray population across replies.\n\nThe cap is a fixed, client-chosen constant rather than a value derived\nfrom the MDS. mds_client_prealloc_inos is a userspace MDS configuration\noption; it is never sent to the kernel client on the wire, and a\nserver-supplied bound could not be trusted for a defensive limit in any\ncase. The constant is set well above that option\u0026apos;s documented default of\n1000 (a generous multiple), so legitimate refill behavior is unaffected\nwhile the CPU and xarray memory a malformed delegation stream can consume\nstays bounded.\n\nImpact: a malicious or compromised Ceph MDS can no longer make a client\nspin through an unbounded delegated-inode interval or grow one session\u0026apos;s\ndelegated-inode xarray without limit.(CVE-2026-89648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: reject buckets with mismatched CRUSH ids\n\ncrush_decode() stores bucket data by array slot, and the mapper later\nderives the per-bucket workspace index from the decoded bucket id. A\nmalformed map can therefore make one bucket reuse another bucket\u0026apos;s\nworkspace by encoding an id different from -1 - slot.\n\nFor uniform buckets, the second replica selection expands the source\nbucket\u0026apos;s permutation into that aliased workspace buffer. If the source\nbucket is larger than the aliased bucket, the write runs past the smaller\npermutation array and can escape the kvmalloc\u0026apos;d CRUSH workspace. KASAN\nreports a slab OOB write of 4 bytes in bucket_perm_choose().\n\nReject buckets whose encoded id does not match their array slot. Valid\nCRUSH maps already use the canonical negative id corresponding to the\nbucket slot, so this restores the invariant expected by\nwork-\u0026gt;work[-1 - in-\u0026gt;id] without changing valid map behavior.(CVE-2026-89656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix out-of-bounds write when null terminating a label vec\n\naa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE\nis passed. If the components are all distinct no duplicates are dropped,\ndups is 0 and the terminator goes to vec[n], so the caller has to provide\nroom for n + 1 entries.\n\naa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len,\ngfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but\nvec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES\nit uses the local array of LOCAL_VEC_ENTRIES pointers, above that it\nallocates exactly len pointers. The terminator therefore lands one entry\npast the end of the local array when len is LOCAL_VEC_ENTRIES, and one\nentry past the end of the allocation when len is larger.\n\nlen comes from the number of \u0026quot;//\u0026amp;\u0026quot; separated components in the label name\nand label_count_strn_entries() does not bound it. An unprivileged task\nreaches the parse by writing to /proc/self/attr/apparmor/current or through\nlsm_set_self_attr(2), both of which go through do_setattr(), and the name\nis parsed before the change_profile permission is checked.\nThe query_label() path behind the securityfs .access file, which is\nmode 0666, performs no permission check at all. Every component has to\nresolve to a loaded profile, so a system with policy loaded is required.\n\nThe other two VEC_FLAG_TERMINATE users work on a label vec that\naa_label_alloc() has already sized with \u0026quot;+ 1 for null terminator entry on\nvec\u0026quot;. Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing\nlen + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of\nthe local array and into kzalloc().(CVE-2026-89761)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix cred UAF caused by begin_current_label_crit_section()\n\nAppArmor\u0026apos;s begin_current_label_crit_section() is a scary function called\nfrom lots of LSM hooks (in particular VFS/socket-related ones) that checks\nif the label referenced by the current creds is marked FLAG_STALE, and if\nso, attempts to use aa_replace_current_label() to replace the creds with an\nupdated version that uses a new label.\n\nThe first problem with this is that it would directly lead to UAF of\n`struct cred` if anything in the kernel takes a pointer to the current\ncreds and accesses these past a security hook invocation that replaces\ncreds, like so:\n```\nconst struct cred *cred = current_cred();\nalloc_file_pseudo(...);\nuid_t uid = cred-\u0026gt;euid;\n```\nI don\u0026apos;t know if anything in the kernel actually does this, but I think it\nis very surprising that this pattern could lead to UAF.\n\nThe second problem is that things go wrong when aa_replace_current_label()\nruns with overridden credentials. aa_replace_current_label() bails out if\n`current_cred() != current_real_cred()` (mirroring the check in\nproc_pid_attr_write()), but this check can\u0026apos;t actually reliably detect\noverridden credentials because the overridden creds can be the same as the\nobjective creds.\n\nSo in approximately the following scenario, things go wrong:\n\n1. task begins with \u0026lt;creds A\u0026gt; (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on \u0026lt;creds A\u0026gt; for overriding\n3. task calls override_creds(\u0026lt;creds A\u0026gt;), which returns a pointer to the old\n   subjective creds (\u0026lt;creds A\u0026gt;)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with \u0026lt;creds B\u0026gt; and drops 2 refs on\n   \u0026lt;creds A\u0026gt;\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(\u0026lt;creds A\u0026gt;)\n9. now task-\u0026gt;cred is \u0026lt;creds A\u0026gt; while task-\u0026gt;real_cred is \u0026lt;creds B\u0026gt;, but the\n   task_struct logically holds two references to \u0026lt;creds B\u0026gt;\n10. another task drops the extra reference on \u0026lt;creds A\u0026gt; that was used for\n    overriding, refcount drops to 0\n11. now task-\u0026gt;real_cred points to freed creds\n\nAt this point, any access to current_cred() will be UAF.\n\nI have a test case where I run aa-disable on a profile while a process\nusing that profile is blocked on splice() from a FUSE passthrough file into\na full pipe; after the profile update, the pipe becomes empty, splice()\nresumes, the credentials go out of sync, and a subsequent getuid() syscall\nresults in a KASAN UAF splat.\n\nTo fix this, instead of directly replacing creds, do it via task_work that\nwill run at the end of the current syscall. (The point in time at which the\ncred replacement happens should have no correctness impact; it is just a\nperformance optimization to avoid unnecessarily touching the refcount of\nthe new label.)\n\nNote that AppArmor still performs direct cred replacements in the\nsb_pivotroot LSM hook after this change, and that direct cred replacements\ncan still happen in VFS -\u0026gt;write() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new-\u0026gt;label_replacement_pending after the entire\naa_task_ctx has been copied, or switch to manually copying members over.\nI am switching to manually copying members over because that should make\nbugs more obvious.(CVE-2026-89762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix TPM teardown ordering\n\ntrusted_tpm_exit() drops the TPM chip reference and frees the digest\narray before unregistering the trusted key type. key_type_lookup()\nholds key_types_sem for reading until the key operation finishes, while\nunregister_key_type() takes it for writing. It therefore provides the\nsynchronization point that must precede backend teardown.\n\nThe current order permits this interleaving:\n\n  CPU 0                              CPU 1\n  trusted_tpm_exit()                 key_type_lookup(\u0026quot;trusted\u0026quot;)\n    put_device(\u0026amp;chip-\u0026gt;dev)             trusted_tpm_seal()\n    kfree(digests)                       pcrlock()\n    unregister_key_type()                  tpm_pcr_extend(..., digests)\n\nCPU 1 can consequently dereference the freed digest array. The chip can\nalso be released before callbacks stop using it.\n\nKASAN reported:\n\n  BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200\n  Read of size 2 at addr ffff88810872d000 by task poc/89\n  Call Trace:\n    tpm_pcr_extend+0x1f0/0x200\n    pcrlock+0x42/0x70 [trusted]\n    trusted_tpm_seal+0x1b6/0x570 [trusted]\n    trusted_instantiate+0x293/0x340 [trusted]\n    __key_instantiate_and_link+0xb2/0x2b0\n    __key_create_or_update+0x61e/0xb50\n    __do_sys_add_key+0x1b8/0x310\n  Allocated by task 88:\n    __kmalloc_noprof+0x1a7/0x490\n    do_one_initcall+0xa1/0x390\n    do_init_module+0x2df/0x840\n  Freed by task 90:\n    kfree+0x131/0x3c0\n    trusted_tpm_exit+0x59/0xa0 [trusted]\n    __do_sys_delete_module+0x346/0x510\n\nMove unregister_key_type() before releasing either resource. This stops\nnew lookups and waits for in-flight key operations to finish before the\nbackend state is destroyed.(CVE-2026-89763)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SCO: hold sk properly in sco_conn_ready\n\nsk deref in sco_conn_ready must be done either under conn-\u0026gt;lock, or\nholding a refcount, to avoid concurrent close. conn-\u0026gt;sk and parent sk is\ncurrently accessed without either, and without checking parent-\u0026gt;sk_state:\n\n    [Task 1]            [Task 2]\n                        sco_sock_release\n    sco_conn_ready\n      sk = conn-\u0026gt;sk\n                          lock_sock(sk)\n                            conn-\u0026gt;sk = NULL\n      lock_sock(sk)\n                          release_sock(sk)\n                          sco_sock_kill(sk)\n       UAF on sk deref\n\nand similarly for access to sco_get_sock_listen() return value.\n\nFix possible UAF by holding sk refcount in sco_conn_ready() and making\nsco_get_sock_listen() increase refcount. Also recheck after lock_sock\nthat the socket is still valid.  Adjust conn-\u0026gt;sk locking so it\u0026apos;s\nprotected also by lock_sock() of the associated socket if any.(CVE-2026-89774)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable preemption in bpf_get_stackid\n\nThe get_perf_callchain call needs disabled preemption plus we need\nit disabled as long as we access its returned trace entries buffer.\n\nNote the bpf_get_stackid_pe function is executed already with\npreemption disabled.(CVE-2026-89799)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: saa7164: fix cleanup on resource allocation failure\n\nsaa7164_dev_setup() adds the device to the global saa7164_devlist before\nrequesting the PCI BAR memory regions.\n\nIf get_resources() fails, saa7164_dev_setup() decrements the device count\nand returns an error, but leaves the device on saa7164_devlist. The probe\nerror path then frees the device, leaving a dangling entry on the global\nlist.\n\nReuse the existing MMIO mapping error path to remove the device from\nsaa7164_devlist and decrement the device count before returning.\n\nAlso release BAR0 if it was successfully requested but the BAR2 request\nfails.(CVE-2026-89877)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: reject geometry changes while the VBI queue is busy\n\nvidioc_s_fmt_vid_cap() and vidioc_s_std() change the device-wide\ndev-\u0026gt;width / dev-\u0026gt;norm but only refuse the change when the *video* queue\n(dev-\u0026gt;vidq) is busy. The VBI queue (dev-\u0026gt;vbiq) shares that same geometry:\ncx231xx_init_vbi_isoc() latches dma_q-\u0026gt;lines_per_field from dev-\u0026gt;norm,\nthe VBI videobuf2 plane is sized from dev-\u0026gt;width / dev-\u0026gt;norm in\nvbi_queue_setup() and vbi_buf_prepare(), and cx231xx_do_vbi_copy() then\nrecomputes the destination offset from the *live* dev-\u0026gt;width and the\nlatched lines_per_field on every URB completion:\n\n\toffset = lines_completed * (dev-\u0026gt;width \u0026lt;\u0026lt; 1) + ...;\n\tif (dma_q-\u0026gt;current_field == 2)\n\t\toffset += dev-\u0026gt;width * 2 * dma_q-\u0026gt;lines_per_field;\n\tmemcpy(plane + offset, p_buffer, lencopy);\n\nBecause the VBI node shares video_ioctl_ops with the video node, an\napplication can size a small VBI plane (REQBUFS/QBUF with a small width,\nor with the NTSC standard), then enlarge dev-\u0026gt;width (or switch dev-\u0026gt;norm\nto PAL) through the video node while the VBI stream is running -- the\nchange is allowed because only dev-\u0026gt;vidq is checked -- and let the device\ndeliver a field-2 VBI payload. cx231xx_do_vbi_copy() now computes the\noffset with the larger geometry and memcpy()s past the end of the smaller\nplane that was already allocated, a heap out-of-bounds write whose offset\nis attacker-chosen and whose contents come from the device. The\nper-field guard in cx231xx_copy_vbi_line() does not help: it bounds the\ncopy against the latched lines_per_field, not the plane\u0026apos;s real capacity,\nand vb2 does not re-run buf_prepare() for an already prepared buffer.\n\nRefuse the format/standard change when the VBI queue is busy as well, so\nthe geometry cannot change underneath an allocated VBI buffer.(CVE-2026-89894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cec: Serialize exclusive follower delivery\n\ncec_receive_notify() reads the exclusive follower pointer without the\nadapter lock. Serialize the no-follower check and message delivery\nagainst mode changes and release.(CVE-2026-89897)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cec: disable delayed work before freeing an interrupted transmit\n\ncec_transmit_msg_fh() drops adap-\u0026gt;lock to wait for a blocking transmit in\nwait_for_completion_killable(). If that wait is interrupted by a signal,\ncancel_delayed_work_sync() can run before the CEC kthread arms the reply\ntimeout via schedule_delayed_work(\u0026amp;data-\u0026gt;work) in cec_transmit_done_ts().\nThe work is then armed after the cancel, and the data is freed with its\ndelayed_work still pending:\n\n  ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout\n\nUse disable_delayed_work_sync(): it cancels the work and disables it, so\nthe later schedule_delayed_work() becomes a no-op and the work cannot be\nre-armed. The data is freed right after, so it need not be re-enabled.(CVE-2026-89899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: reject unsolicited H2CData PDUs\n\nnvmet_tcp_handle_h2c_data_pdu() accepts an H2CData PDU after only checking\nthat its TTAG is a valid in-range command index and that the command\u0026apos;s\ndata buffers are mapped. It never checks that the target has actually\nsolicited that data by sending an R2T for the command.\n\nA remote host can abuse this. It submits a write command that takes the\nR2T path and, before the target transmits the R2T, sends an H2CData PDU\nfor that command\u0026apos;s tag. The data completes the command early, and when\nthe command then fails synchronously (e.g. a length mismatch caught by\nnvmet_check_transfer_len()), it is completed a second time. Each\ncompletion calls nvmet_tcp_queue_response(), so the same command is added\nto queue-\u0026gt;resp_list twice while it is still linked; the second llist_add()\nmakes the node point to itself (lentry-\u0026gt;next == lentry).\n\nnvmet_tcp_process_resp_list() then walks that self-referential node and\nadds the command to resp_send_list twice. With CONFIG_DEBUG_LIST this\ntrips the \u0026quot;list_add double add\u0026quot; check (kernel BUG); without it the loop\nnever terminates and the nvmet_tcp workqueue wedges (soft-lockup). It is\nremotely triggerable and needs no authentication on an allow_any_host\nsubsystem.\n\nTrack whether an R2T has been transmitted for a command and reject an\nH2CData PDU that arrives before it. The flag is cleared on command reuse\n(nvmet_tcp_get_cmd() zeroes cmd-\u0026gt;flags) and stays set across the multiple\nH2CData PDUs of a single solicited transfer.(CVE-2026-89968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix out-of-bounds write when receiving an over-long PDU\n\nnvmet_tcp_try_recv_pdu() reads a PDU header into the fixed 128-byte\nqueue-\u0026gt;pdu union, then computes the remaining payload length as\n\n\tqueue-\u0026gt;left = hdr-\u0026gt;hlen - queue-\u0026gt;offset + hdgst;\n\nand reads that many more bytes into \u0026amp;queue-\u0026gt;pdu + queue-\u0026gt;offset, without\never bounding the result against sizeof(queue-\u0026gt;pdu).\n\nA struct nvme_tcp_icreq_pdu is itself 128 bytes, exactly the size of the\nunion. Once a header digest has been negotiated (hdgst = 4), a second\nICReq passes the hlen == nvmet_tcp_pdu_size() check but yields\nqueue-\u0026gt;left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the\n128-byte buffer -- 4 bytes past its end, over queue-\u0026gt;hdr_digest and\nqueue-\u0026gt;data_digest. Those bytes are attacker-controlled (an ICReq\ncarries no digest), and the duplicate ICReq is only rejected later,\nafter the overflow. A remote unauthenticated host can thus corrupt\nkernel memory adjacent to the receive buffer.\n\nReject any PDU whose declared length would read past the end of\nqueue-\u0026gt;pdu before the second recv.(CVE-2026-89969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: add missing SRCU grace period in error path\n\nnvme_alloc_ns() error path at out_unlink_ns removes ns from the\nnamespace head siblings list with list_del_rcu(\u0026amp;ns-\u0026gt;siblings) but\ndoes not wait for SRCU readers before freeing the namespace struct.\nMultipath code iterates the head-\u0026gt;list under srcu_read_lock() in\nnvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent\nreader can still hold a reference to ns when kfree(ns) runs.\n\nThe normal removal path in nvme_ns_remove() correctly calls\nsynchronize_srcu(\u0026amp;ns-\u0026gt;head-\u0026gt;srcu) after list_del_rcu() to wait for\nin-progress readers. Add the same grace period in the error path.(CVE-2026-89972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: Protect kprobe_blacklist with RCU\n\n__within_kprobe_blacklist() traverses kprobe_blacklist without holding\nkprobe_mutex. When a module is unloaded, kprobe_remove_area_blacklist()\nremoves blacklist entries and immediately frees them with kfree().\nA concurrent call to within_kprobe_blacklist() can therefore dereference\nfreed memory.\n\nFurthermore, within_kprobe_blacklist() can be called in atomic or\nnon-preemptible contexts where the sleeping kprobe_mutex cannot be taken.\n\nProtect kprobe_blacklist with RCU. Use guard(rcu)() and\nlist_for_each_entry_rcu() for traversal, list_add_tail_rcu() for\ninsertions, list_del_rcu() for deletions, and kfree_rcu() to reclaim\nentries safely after a grace period.(CVE-2026-89988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Take trace_array reference before accessing its ftrace_ops\n\nThe trace instance files set_ftrace_filter and set_ftrace_notrace was\nupdated to work with specific trace instances (trace_arrays). The issue is\nthat when these files are opened, there is a small race window where it\nwill use the ftrace_ops from the inode-\u0026gt;private pointer to get a reference\nto the trace_array and then take its reference. The problem is that the\nftrace_ops itself could be freed. If the rmdir on the instance happens at\nthe same time the set_ftrace_filter file is opened, the rmdir could have\nalso freed the ftrace_ops and referencing it will cause a use-after-free\nbug and crash the kernel.\n\nInstead, pass in the trace_array as the file private data (NULL for the\ntop level instance), and then pass both the trace_array and the ftrace_ops\nto the ftrace_regex_open() function. If the trace_array is NULL, then it\njust uses the ftrace_ops without the need to take its reference (like\nnormal). If the ftrace_ops is NULL, that is only the case for the top\nlevel instance and the global_ops can be used.\n\nThis allows the trace_array to have its reference incremented before\ntouching the ftrace_ops that could also be freed when the instance is.(CVE-2026-90002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Reserve a terminator byte for the login payload\n\niscsi_target_check_login_request() rejects a login PDU whose\nDataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is \u0026apos;\u0026gt;\u0026apos; and\nlogin-\u0026gt;req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS\nbytes. Since iscsit_get_login_rx() receives payload_length + padding\nbytes, where\n\n\tpadding = ((-payload_length) \u0026amp; 3);\n\nany payload_length from 8189 to 8192 fills the whole 8192 byte\nbuffer. The write stays in bounds, but no byte is left for a NUL\nterminator.\n\nThe buffer is subsequently consumed as a C string. In the CHAP path\nchap_check_algorithm() calls kstrdup(a_str), and extract_param() calls\nstrstr(in_buf, pattern) followed by strlen_semi(), none of which take a\nlength. convert_null_to_semi() additionally rewrites every embedded NUL\nto \u0026apos;;\u0026apos;, so even a payload made of well formed NUL separated key=value\nrecords is left without a terminator. These walk past the end of the\nobject into adjacent slab memory. It is reachable by an unauthenticated\ninitiator against a portal configured for CHAP; when authentication is\nnot required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and\nthe CHAP path is never entered.\n\nAllocate one extra byte. kzalloc() zeroes it and nothing ever writes to\nit, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS\nbytes, so the buffer is always terminated.(CVE-2026-90011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Prevent client use-after-free during blocked-lock reaping\n\nA bare lock owner -- its only remaining reference a blocked lock on\nnn-\u0026gt;blocked_locks_lru -- holds a raw pointer to its nfs4_client but\nno reference keeping the client alive. When the per-net laundromat\nreaps such a lock, freeing the nbl drops the owner reference\nheld through flc_owner, and the final nfs4_put_stateowner()\ntakes the client\u0026apos;s cl_lock. Because the laundromat detaches the\nnbl first, __destroy_client() no longer finds it, so a concurrent\nforce_expire_client() can free the client before nfs4_put_stateowner()\nruns, dereferencing cl_lock in freed memory.\n\nPin the client with cl_rpc_users before dropping\nnn-\u0026gt;blocked_locks_lock, and skip clients already expiring, whose\nblocked locks __destroy_client() frees while holding an owner\nreference. Take nn-\u0026gt;client_lock outside nn-\u0026gt;blocked_locks_lock.\nEvery other site holds nn-\u0026gt;blocked_locks_lock as a leaf, acquiring\nno further lock, so placing nn-\u0026gt;client_lock outside it cannot form\na lock-order cycle.(CVE-2026-90036)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Prevent client use-after-free during close_lru reaping\n\nAn nfs4_openowner left on nn-\u0026gt;close_lru after its final CLOSE keeps\nits last closed stateid in oo_last_closed_stid, holding only a raw\npointer to its nfs4_client. The laundromat reaps timed-out entries,\ndrops nn-\u0026gt;client_lock, and calls nfs4_put_stid(), which dereferences\nthe client through cl_lock. Nothing pins the client across that\nwindow, so a concurrent force_expire_client() can free it and\nnfs4_put_stid() reads freed memory. __destroy_client() hits the same\nrace, walking clp-\u0026gt;cl_openowners without cl_lock.\n\nPin the client with cl_rpc_users before dropping client_lock, and\nskip clients already expiring. __destroy_client() then cleans up its\nown close_lru entries through release_last_closed_stateid(), so\nteardown no longer races the laundromat.(CVE-2026-90037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan\n\nFor L2CAP sockets without owning sk-\u0026gt;sk_socket, reading\nl2cap_pi(sk)-\u0026gt;chan may race against concurrent l2cap_sock_kill() -\u0026gt;\nl2cap_sock_put_chan().  This excludes simultaneous proto_ops callbacks,\nbut access in l2cap_sock_cleanup_listen() has unsafe lockless read.\n\n [Task 1]                         [Task 2 (hdev-\u0026gt;workqueue)]\n l2cap_sock_release(parent)       l2cap_disconn_cfm\n   l2cap_sock_cleanup_listen        l2cap_conn_del\n     bt_accept_dequeue                l2cap_chan_del\n       lock_sock(sk)                    l2cap_sock_teardown_cb\n       bt_accept_unlink\n         bt_sk(sk)-\u0026gt;parent = NULL\n       release_sock(sk) ----------------\u0026gt; lock_sock(sk)\n                                          parent = /* NULL */\n     lock_sock(sk) \u0026lt;--------------------- release_sock(sk)\n                                          sock_set_flag(sk, SOCK_ZAPPED)\n                                      l2cap_sock_close_cb\n                                        l2cap_sock_kill(sk)\n                                          l2cap_sock_put_chan\n     chan = READ l2cap_pi(sk)-\u0026gt;chan         l2cap_pi(sk)-\u0026gt;chan = NULL\n     l2cap_chan_hold_unless_zero            l2cap_put_chan(chan)\n       kref_get_unless_zero(\u0026amp;chan-\u0026gt;ref)\n\nTask 1 may observe NULL which causes null-ptr-deref.\n\nFix the race by taking lock_sock() in l2cap_sock_kill() to\nsynchronize with l2cap_sock_cleanup_listen().  hold_unless_zero() is not\nneeded here, l2cap_pi(sk)-\u0026gt;chan owns reference if it is non-NULL.\n\nClarify code comments vs. locking.(CVE-2026-90091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix potential UAF when reading bpf link info\n\nIn bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link-\u0026gt;prog is\naccessed without holding any locks. If the prog is concurrently replaced\nvia bpf_link_update, the old prog can be freed, leading to a potential\nUAF issue.\n\nFix this by accessing link-\u0026gt;prog under RCU protection to safely fetch\nthe pointer and guarantee its lifetime while reading its fields.(CVE-2026-90392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: reject login PDUs declaring more data than was received\n\nisert_login_recv_done() records how many bytes the HCA actually placed in\nthe login buffer, but nothing compares that against the length the login\nPDU\u0026apos;s BHS declares.  isert_rx_login_req() copies min(login_req_len,\nMAX_KEY_VALUE_PAIRS) bytes into login-\u0026gt;req_buf, and the login code then\nreads the declared length back out of that buffer - for the first PDU in\niscsi_target_locate_portal(),\n\n\tpayload_length = ntoh24(login_req-\u0026gt;dlength);\n\ttmpbuf = kmemdup_nul(login-\u0026gt;req_buf, payload_length, GFP_KERNEL);\n\nand for the ones after it in iscsi_decode_text_input(), reached from\niscsi_target_do_login().\n\nlogin-\u0026gt;req_buf is a fixed MAX_KEY_VALUE_PAIRS (8192) byte allocation, so\nan initiator that declares more than it sends reads off the end of it,\nbefore authentication and with the length under its control:\n\n  BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80\n  Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167\n   __asan_memcpy+0x23/0x60\n   kmemdup_nul+0x43/0x80\n   iscsi_target_locate_portal+0x48d/0x1180\n   iscsi_target_login_thread+0x19a9/0x3350\n  Allocated by task 167:\n   __kmalloc_cache_noprof+0x158/0x370\n   iscsi_target_login_thread+0x971/0x3350\n  which belongs to the cache kmalloc-8k of size 8192\n  allocated 8192-byte region\n\nFalsifying the second login PDU instead reaches the other reader, on the\nsame buffer:\n\n  BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80\n  Read of size 8193 at addr ffff888104d10000 by task kworker/1:1/50\n  Workqueue: isert_login_wq iscsi_target_do_login_rx\n   __asan_memcpy+0x23/0x60\n   kmemdup_nul+0x43/0x80\n   iscsi_decode_text_input+0xc6/0x11c0\n   iscsi_target_do_login+0x261/0x1470\n   iscsi_target_do_login_rx+0x51d/0x7d0\n\niscsit over TCP is not exposed: iscsit_get_login_rx() validates the\ndeclared length with iscsi_target_check_login_request() and then reads\nexactly that many bytes off the socket, so the declared length governs\nhow much arrives rather than how much is copied out of an already-filled\nbuffer.  isert does not call iscsi_target_check_login_request() at all.\n\nReject a login PDU whose declared DataSegmentLength exceeds what was\nreceived, in both paths that reach isert_rx_login_req():\nisert_get_login_rx() for the first login PDU and isert_login_recv_done()\nfor the ones after it.  dlength \u0026lt;= login_req_len is allowed because the\nreceived count can include up to three bytes of iSCSI padding.\n\nOnce the check is in place the copy out can no longer exceed the copy in:\nthe posted login SGE is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot\nexceed MAX_KEY_VALUE_PAIRS and the min() in isert_rx_login_req() is\nlogin_req_len.\n\nLike the existing short-PDU check added by 29e7b925ae6d, the reject in\nisert_login_recv_done() returns without completing login_req_comp, so a\nmalformed subsequent PDU leaves the login to be torn down by the login\ntimer rather than failing immediately.  The first-PDU path returns an\nerror and fails straight away.\n\nReproduced on 7.2.0-rc4 with soft-RoCE (rdma_rxe) under KASAN, using an\ninitiator that sends the real key=value payload while declaring 8193 in\nthe BHS, on the first login PDU and on the second in separate runs.  The\nreported read size tracks the declared value exactly; 16384 and 61440\nbehave the same.  Unpatched 3 of 3 runs report on each of the two paths,\npatched 0 of 3 on both, run alternately in a single session, and a normal\nlogin still completes on the patched build.(CVE-2026-90413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIB/isert: reject PDUs declaring more data than was received\n\nisert_recv_done() hands each received PDU to the opcode handlers without\never looking at wc-\u0026gt;byte_len, the number of bytes the HCA actually placed\nin the receive descriptor. The handlers then copy that many bytes - the\ndata-segment length the initiator declared in the BHS\n(ntoh24(hdr-\u0026gt;dlength), via the derived unsol_data_len / imm_data_len) -\nout of the fixed-size descriptor:\n\n  isert_handle_iscsi_dataout():\n        sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc),\n                            unsol_data_len);\n  isert_handle_scsi_cmd():\n        sg_copy_from_buffer(cmd-\u0026gt;se_cmd.t_data_sg, sg_nents,\n                            isert_get_data(rx_desc), imm_data_len);\n\nBecause the declared length is never checked against wc-\u0026gt;byte_len, an\ninitiator can declare a data segment larger than the bytes it actually\nsent (and larger than the descriptor) and cause an out-of-bounds read of\nthe receive buffer.\n\nNothing upstream of isert closes this door:\n\n  - __iscsit_check_dataout_hdr() bounds the inbound payload against\n    conn_ops-\u0026gt;MaxXmitDataSegmentLength (MXDSL) - a transmit parameter,\n    used here for the inbound check.\n  - iscsi_set_connection_parameters() sets\n    ops-\u0026gt;MaxXmitDataSegmentLength = ops-\u0026gt;TargetRecvDataSegmentLength;\n    and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in\n    iscsi_check_acceptor_state(), so the value the initiator declares is\n    adopted verbatim (type range 512..16777215). The initiator effectively\n    raises its own ceiling.\n  - isert never clamps the negotiated value to its own fixed receive\n    descriptor (ISER_RX_SIZE, 9216 bytes), so the target core\u0026apos;s bound and\n    the descriptor size are unrelated.\n\nThe imm_data_len == data_len path is more than an over-read: it aliases\nthe receive descriptor via sg_set_buf() and passes it to the backend as\nthe data source for the SCSI WRITE, so an over-declared length causes heap\ncontents past the descriptor to be written through the backend to the\nbacking store. The backend is the victim of the oversized scatterlist\nisert hands it, not the cause; no read-back of the written bytes was\ndemonstrated.\n\nTrigger: after login completes (full feature phase), an initiator that has\ndeclared a large TargetRecvDataSegmentLength and a FirstBurstLength that\npermits unsolicited/immediate data sends a PDU whose declared data-segment\nlength exceeds what was received. With KASAN:\n\n  BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0\n  Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25\n  Workqueue: ib-comp-wq ib_cq_poll_work\n  Call Trace:\n   sg_copy_buffer+0x150/0x1c0\n   isert_recv_done+0xba6/0x2390\n   __ib_process_cq+0xe1/0x390\n   ib_cq_poll_work+0x46/0x150\n\nisert_recv_done+0xba6 resolves to isert_handle_iscsi_dataout()\n(ib_isert.c:1160), inlined through isert_rx_opcode().\n\nValidate wc-\u0026gt;byte_len against the framing in isert_recv_done() before the\nPDU reaches any handler, and reinstate the connection if it is short.\nBecause the test compares without subtracting the header length, it also\nrejects PDUs shorter than the iSER and iSCSI headers, which would otherwise\nbe parsed out of stale descriptor contents. The login handler rejects PDUs\nshorter than ISER_HEADERS_LEN (commit 29e7b925ae6d (\u0026quot;IB/isert: Reject login\nPDUs shorter than ISER_HEADERS_LEN\u0026quot;)) but does not bound the declared\nlength either; that is fixed in the next patch. The data handlers had no\nlength check at all.\n\nisert reads the data segment from a fixed offset: isert_get_data()\nreturns the iSER header plus ISER_HEADERS_LEN and makes no adjustment for\nan AHS.  The bytes the handlers touch are therefore exactly\n[ISER_HEADERS_LEN, ISER_HEADERS_LEN + dlength), and comparing that sum\nagainst wc-\u0026gt;byte_len bounds precisely the region that is read.  An AHS\nterm would only make the test stricter without bounding anything furth\n---truncated---(CVE-2026-90414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: validate thread record before delete key rebuild\n\nhfsplus_delete_cat() is called with str == NULL when the last open\nreference to an unlinked HFS+ hardlink backing inode is closed. In that\ncase, the function finds the catalog thread by CNID and rebuilds the\ncatalog key from thread.nodeName.\n\nThat reconstruction path reads thread.nodeName.length directly from the\ncatalog B-tree into fd.search_key and then copies length * 2 bytes into\nfd.search_key-\u0026gt;cat.name.unicode. It does not first check that the found\nrecord is a thread record or that its size matches the thread name.\n\nA corrupted image can therefore provide an oversized thread name length\nand make hfs_bnode_read() write past the catalog search-key allocation.\n\nRead the CNID record through hfsplus_brec_read_cat(), which bounds the\nrecord read to sizeof(hfsplus_cat_entry) and verifies that a thread\nrecord\u0026apos;s size exactly matches nodeName.length. Together, these checks\nensure an accepted thread name fits HFSPLUS_MAX_STRLEN. Reject non-thread\nrecords before building the delete key from the validated thread name.\n\nShare the thread-record-type helper between hfsplus_find_cat() and\nhfsplus_delete_cat().(CVE-2026-93095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Preserve unit 0 on allocation failure\n\nhfi1_free_devdata() assumes that the device was inserted into the unit\ntable and unconditionally erases dd-\u0026gt;unit. If xa_alloc_irq() fails, the\nzero-initialized unit remains zero, so full cleanup can remove an\nunrelated device from index 0.\n\nRelease only the rdmavt allocation and return immediately while the unit\ntable has not acquired the device.(CVE-2026-93103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rvt: Return NULL after port allocation failure\n\nrvt_alloc_device() deallocates the IB device when its port array cannot\nbe allocated but then returns the pointer to the released allocation.\nCallers treat any non-NULL value as valid and dereference it, resulting\nin a use-after-free.\n\nReturn NULL immediately after deallocation so callers can propagate the\nallocation failure.(CVE-2026-93104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux\n\nbpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the\nbpf_verifier_lock, but publishes the result through a plain store\nand re-checks it through a plain lockless load. Nothing orders\nthe stores initializing the struct btf inside btf_parse_vmlinux()\nagainst the store publishing the pointer: On a weakly ordered\narch, a concurrent first-time caller taking the lockless fast\npath could in principle observe the pointer before the parsed\ncontents are visible. The mutex_unlock() does not help such a\nreader given it only synchronizes with a later acquisition of the\nsame lock. Thus, publish the pointer with smp_store_release()\nand read it on the fast path with smp_load_acquire().\n\nAcquire semantics are needed rather than a dependency-ordered\nREAD_ONCE(): btf_parse_vmlinux() also populates globals outside\nthe returned object (e.g. bpf_ctx_convert.t). An address\ndependency would only order accesses performed through the\npointer and not cover other globals.(CVE-2026-93138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: quiesce input in hid_hw_stop() to prevent use-after-free\n\nA driver\u0026apos;s probe calls hid_device_io_start() to enable input delivery,\nthen fails at a later initialization step and unwinds via hid_hw_stop().\nThe unwind frees struct hidraw via hidraw_disconnect() while in-flight\nHID reports may still be running on another CPU, dereferencing the\nfreed object through hidraw_report_event(). syzbot reports the\nresulting use-after-free for the corsair-psu HID driver.\n\nEdward Adam Davis posted a per-driver fix for corsair-psu that adds\nan explicit hid_device_io_stop() before hid_hw_stop() in the probe\nerror path (\u0026quot;hwmon: prevent packets from going to driver for probe\u0026quot;,\n2026-04-28). Auditing the tree shows 15 drivers call\nhid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:\n\n  drivers calling hid_device_io_start() without a matching\n  hid_device_io_stop() before hid_hw_stop():\n    drivers/hwmon/corsair-psu.c       (fix posted by Edward)\n    drivers/hwmon/corsair-cpro.c\n    drivers/hwmon/nzxt-kraken3.c\n    drivers/hwmon/nzxt-smart2.c\n    drivers/hwmon/gigabyte_waterforce.c\n    drivers/hid/hid-logitech-dj.c\n    drivers/hid/hid-nintendo.c\n    drivers/hid/hid-mcp2221.c\n\nRoughly half of all callers of the API are exposed. Centralize the\nquiesce in hid_hw_stop() so callers do not have to remember the\nmatching stop: if a driver has left hdev-\u0026gt;io_started true on entry,\ncall hid_device_io_stop() before hid_disconnect().\n\nFor the 7 drivers that already call hid_device_io_stop() correctly,\nhdev-\u0026gt;io_started is false on entry, the guard short-circuits, and\nbehavior is unchanged.\n\nNo Fixes: tag because the affected drivers gained their\nhid_device_io_start() calls independently over years; the bug is a\nclass-wide API misuse rather than a regression from one commit.(CVE-2026-93189)",
  "id": "OESA-2026-4185",
  "modified": "2026-09-30T13:47:24Z",
  "published": "2026-09-30T13:47:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4185"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64189"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89478"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89508"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89510"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89520"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89555"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89559"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89580"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89636"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89647"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89648"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89656"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89762"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89763"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89774"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89799"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89897"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90011"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90036"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90037"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90392"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90413"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90414"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93103"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93104"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93138"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93189"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-64189",
    "CVE-2026-89478",
    "CVE-2026-89479",
    "CVE-2026-89508",
    "CVE-2026-89510",
    "CVE-2026-89520",
    "CVE-2026-89555",
    "CVE-2026-89559",
    "CVE-2026-89580",
    "CVE-2026-89636",
    "CVE-2026-89647",
    "CVE-2026-89648",
    "CVE-2026-89656",
    "CVE-2026-89761",
    "CVE-2026-89762",
    "CVE-2026-89763",
    "CVE-2026-89774",
    "CVE-2026-89799",
    "CVE-2026-89877",
    "CVE-2026-89894",
    "CVE-2026-89897",
    "CVE-2026-89899",
    "CVE-2026-89968",
    "CVE-2026-89969",
    "CVE-2026-89972",
    "CVE-2026-89988",
    "CVE-2026-90002",
    "CVE-2026-90011",
    "CVE-2026-90036",
    "CVE-2026-90037",
    "CVE-2026-90091",
    "CVE-2026-90392",
    "CVE-2026-90413",
    "CVE-2026-90414",
    "CVE-2026-93095",
    "CVE-2026-93103",
    "CVE-2026-93104",
    "CVE-2026-93138",
    "CVE-2026-93189"
  ]
}

OPENSUSE-SU-2026:11880-1

Vulnerability from csaf_opensuse - Published: 2026-09-24 00:00 - Updated: 2026-11-04 21:56

Summary

kernel-devel-7.2.7-1.1 on GA media

Severity

Moderate

Scope

904 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2026:22091-1

Vulnerability from csaf_opensuse - Published: 2026-10-12 15:44 - Updated: 2026-10-19 17:25

Summary

Security update for the Linux Kernel

Severity

Important

Scope

401 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 136 products

Open the full advisory

SUSE-SU-2026:24179-1

Vulnerability from csaf_suse - Published: 2026-10-12 13:24 - Updated: 2026-10-20 09:49

Summary

Security update for the Linux Kernel

Severity

Important

Scope

401 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 8 products

Open the full advisory

SUSE-SU-2026:24181-1

Vulnerability from csaf_suse - Published: 2026-10-12 15:51 - Updated: 2026-10-20 09:49

Summary

Security update for the Linux Kernel

Severity

Important

Scope

473 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 17 products

Open the full advisory

SUSE-SU-2026:24182-1

Vulnerability from csaf_suse - Published: 2026-10-12 14:42 - Updated: 2026-10-20 09:49

Summary

Security update for the Linux Kernel

Severity

Important

Scope

479 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 20 products

Open the full advisory

SUSE-SU-2026:24184-1

Vulnerability from csaf_suse - Published: 2026-10-12 13:51 - Updated: 2026-10-20 09:49

Summary

Security update for the Linux Kernel

Severity

Important

Scope

401 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 28 products

Open the full advisory

SUSE-SU-2026:24197-1

Vulnerability from csaf_suse - Published: 2026-10-12 14:15 - Updated: 2026-10-21 11:49

Summary

Security update for the Linux Kernel

Severity

Important

Scope

401 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 9 products

Open the full advisory

SUSE-SU-2026:24235-1

Vulnerability from csaf_suse - Published: 2026-10-12 13:51 - Updated: 2026-10-21 11:50

Summary

Security update for the Linux Kernel

Severity

Important

Scope

401 vulnerabilities in this advisory, including CVE-2026-89508.

CVE-2026-89508

4.7 (Medium)


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

Recommended: 114 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

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

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

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

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

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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

Related by attack behaviour

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

Action not permitted

CVE-2026-89508 (GCVE-0-2026-89508)

OESA-2026-4185 (CVE-2026-64189)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour