)]}' { "log": [ { "commit": "a2c1ccf251822b22c396b5bd6fc1fd725d376c01", "tree": "180c3b8b8278e6c54a0e3e9f580660e0f83cedf5", "parents": [ "34c7bbfa34586b0bdba4e119f4a18f0e508d1f99" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 16:43:12 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 16:43:12 2026 +0200" }, "message": "strip the new mbox files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "34c7bbfa34586b0bdba4e119f4a18f0e508d1f99", "tree": "6de16a27ee99fb1c24d071021bad4f3d8a9d5486", "parents": [ "21fff32f3cde56e7ba6d3357c7ae3fc4a22962d1" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 16:42:54 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 16:42:54 2026 +0200" }, "message": "assign some CVE ids on request\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "21fff32f3cde56e7ba6d3357c7ae3fc4a22962d1", "tree": "ae4c65c2578730cdb48e98501770b5fcd311205a", "parents": [ "b9f3b8181a40de1d89bdf526b97354b1c856b4c2" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 15:59:43 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 15:59:43 2026 +0200" }, "message": "assign a cve on request\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "b9f3b8181a40de1d89bdf526b97354b1c856b4c2", "tree": "fca3e242604389694eae7ad08bda6b6217c3fe97", "parents": [ "7c4d3036f35aee74974b6dad9ad021cc858e47cc" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 14:00:59 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 19 14:00:59 2026 +0200" }, "message": "updates for new stable releases.\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "7c4d3036f35aee74974b6dad9ad021cc858e47cc", "tree": "0fb352f9d765f608c3661cc462601801eabf528b", "parents": [ "6502476fc8261131ea883bbf0b142b3209d8be17" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Thu Jun 18 00:01:31 2026 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Thu Jun 18 00:01:31 2026 +0530" }, "message": "reject CVE-2026-43122 as it was reverted\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "6502476fc8261131ea883bbf0b142b3209d8be17", "tree": "6ac8896090bdb0f52a410b3c9540c55142204e16", "parents": [ "84f82b7135fcfe563555ee6c0abdf99101344586" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 23:55:34 2026 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 23:55:34 2026 +0530" }, "message": "reject some CVE ids that have their commits reverted\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "84f82b7135fcfe563555ee6c0abdf99101344586", "tree": "333ee5d9bdb662611596ab6d224e0e512e27f575", "parents": [ "a73a632603929ff0ad9dc5cce8059d4e1b65c18a" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 19:13:33 2026 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 19:13:33 2026 +0530" }, "message": "update CVE-2026-31456 with another git id\n\nGotta love duplcate commits in the tree with multiple git ids...\n\nReported-by: Heiko Stübner \u003cheiko@sntech.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "a73a632603929ff0ad9dc5cce8059d4e1b65c18a", "tree": "b93c1f81bea46b63949e42e4f7e48ddb8eb7268c", "parents": [ "9e2b8fe56b6d35e2cc1b269845412b459451a20f" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 11:44:32 2026 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 11:44:32 2026 +0530" }, "message": "update for new reference\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "9e2b8fe56b6d35e2cc1b269845412b459451a20f", "tree": "4b00aff8c45088a23e6f20b9b831a2e3df48e41a", "parents": [ "fdda9fb1d94c19a58679dd355909f91b965ef22c" ], "author": { "name": "Salvatore Bonaccorso", "email": "carnil@debian.org", "time": "Wed Jun 17 08:02:41 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Wed Jun 17 11:41:19 2026 +0530" }, "message": "CVE-2026-46173: Add Google p0 issue reference\n\nLink: https://project-zero.issues.chromium.org/issues/510793286\nSigned-off-by: Salvatore Bonaccorso \u003ccarnil@debian.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "fdda9fb1d94c19a58679dd355909f91b965ef22c", "tree": "93435a74e036e97af95ba9053e8eb39cf82bc016", "parents": [ "001894b0b749fbec95d94d3b0b44a05029a251a6" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 16 11:56:08 2026 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 16 11:56:08 2026 +0530" }, "message": "strip the new mbox\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "001894b0b749fbec95d94d3b0b44a05029a251a6", "tree": "0ecf57274095461e2a40edeee5fcaa19f2bb3b7f", "parents": [ "927de31ad82898567ad9cd38ab3e1877bd0be815" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 16 11:55:36 2026 +0530" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 16 11:55:36 2026 +0530" }, "message": "finally make CVE-2026-46331 \"public\"\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "927de31ad82898567ad9cd38ab3e1877bd0be815", "tree": "abf2e8228ea9fc34727ee628504f02562e138bcc", "parents": [ "734a49e9a0b6ea16f9336fb7ce6f23c0fa2e1570" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 10:04:54 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 10:04:54 2026 +0200" }, "message": "reject 3 cve ids as they are not in any released version anymore.\n\nHappens after -final comes out every time...\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "734a49e9a0b6ea16f9336fb7ce6f23c0fa2e1570", "tree": "a37c85d5eaa681bc2e5e4bbc9e4958c473aed104", "parents": [ "9f6abe8f0a8fddba6221fcc0253a0057ecaa1344" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 10:02:48 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 10:02:48 2026 +0200" }, "message": "updates due to new .vulnerable file information\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "9f6abe8f0a8fddba6221fcc0253a0057ecaa1344", "tree": "e818e54d38c745cd018088549066125c09bb6d25", "parents": [ "64ae3b7a1afa6afbdb992cae14139b9a1bb6effe" ], "author": { "name": "Rolf Eike Beer", "email": "eb@emlix.com", "time": "Fri May 29 08:21:18 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 09:59:20 2026 +0200" }, "message": "add more atomisp driver holes\n\nThis driver has been absent from the tree from 4.18 to 5.8.\n\nSigned-off-by: Rolf Eike Beer \u003ceb@emlix.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "64ae3b7a1afa6afbdb992cae14139b9a1bb6effe", "tree": "5d4d8fca6eb55046ec99d8ff4fb5c666bf2acdf8", "parents": [ "f38932f50efc432afc4c72c33ff3d69321bfcb82" ], "author": { "name": "Rolf Eike Beer", "email": "eb@emlix.com", "time": "Fri May 29 07:47:48 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 09:59:20 2026 +0200" }, "message": "add .vulnerable id for CVE-2026-46135\n\nThis commit is not necessarily where the issues were actually introduced. This\ncommit is where the NVMe over TCP target driver was first introduced into the\nmainline kernel, so this is just a lower barrier to denote that no older\nversions can be affected.\n\nSigned-off-by: Rolf Eike Beer \u003ceb@emlix.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "f38932f50efc432afc4c72c33ff3d69321bfcb82", "tree": "2a023e1cc798c59a40b2e28a89aaf6fb59f81218", "parents": [ "5e76d99948575120e59a204fe0402bd765f39195" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 04:03:26 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 15 04:03:26 2026 +0200" }, "message": "updates now that 7.1 is released\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "5e76d99948575120e59a204fe0402bd765f39195", "tree": "f892b6669bb7a3c1b54f5f7ed71236c27f56a607", "parents": [ "b9c4575d388ced987cd8dbcc65163241c202c629" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 14 06:55:29 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 14 06:55:29 2026 +0200" }, "message": "updates after cvss merge\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "b9c4575d388ced987cd8dbcc65163241c202c629", "tree": "97955105b976c790d3b873d654aed008e3d4cfcb", "parents": [ "60a9ef9f13876e9f67afe6fa07cb7bc5a9c85d82", "7fc41fbabb9e9d44f3139512a8091eeb3be20911" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 14 05:52:31 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 14 05:52:31 2026 +0200" }, "message": "Merge branch \u0027sasha-cvss-important\u0027\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "60a9ef9f13876e9f67afe6fa07cb7bc5a9c85d82", "tree": "e6add0afae6dadb24992a04e145aca59da156fc5", "parents": [ "d07ae557fddf6b63d84f9eeff7d4d4461e76e6e6" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 12 10:31:58 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 12 10:31:58 2026 +0200" }, "message": "updates based on new references\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "d07ae557fddf6b63d84f9eeff7d4d4461e76e6e6", "tree": "9952bdf19e1a7627b94959ea4988ec44fbafd7fd", "parents": [ "d9289aeb3d2ed77c9ee205ec3e9962672d27937a" ], "author": { "name": "Salvatore Bonaccorso", "email": "carnil@debian.org", "time": "Thu Jun 11 22:32:28 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 12 10:27:56 2026 +0200" }, "message": "CVE-2025-40214: Add reference to write-up\n\nThe reporter published a blogpost with a walkthrough of the rewritten\nAF_UNIX garbage collector, the CVE-2025-40214 scc_index\nuninitialised-field bug, and two reproducers. Reference it in the CVE\nentry.\n\nLink: https://mohandacherir.github.io/Qdiv7/posts/unix_new_gc/\nSigned-off-by: Salvatore Bonaccorso \u003ccarnil@debian.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "d9289aeb3d2ed77c9ee205ec3e9962672d27937a", "tree": "4950ffd80cab2e7e18760d59655a46881082054f", "parents": [ "e702ea65884280f40b27539316aea2a4bd8c2895" ], "author": { "name": "Salvatore Bonaccorso", "email": "carnil@debian.org", "time": "Thu Jun 11 21:22:26 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 12 10:27:54 2026 +0200" }, "message": "CVE-2026-43494: Add reference from reporter\n\nCVE-2026-43494 aka PinTheft was discovered by Aaron Esau and they\nprovided later an exploit to demonstrate the issue. Add the public\nreference to it.\n\nLink: https://github.com/v12-security/pocs/tree/main/pintheft\nSigned-off-by: Salvatore Bonaccorso \u003ccarnil@debian.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "e702ea65884280f40b27539316aea2a4bd8c2895", "tree": "6255074f65cc73d1c31a77189f67bb8b46452269", "parents": [ "04e3f6bc4080bdd4a579598fc596f1d3039b4bfe" ], "author": { "name": "Allen Pais", "email": "apais@linux.microsoft.com", "time": "Thu Jun 11 06:21:57 2026 +0000" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 12 10:27:48 2026 +0200" }, "message": "proposed: Add Allen\u0027s v7.0.[10/11] results\n\nSigned-off-by: Allen Pais \u003capais@linux.microsoft.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "7fc41fbabb9e9d44f3139512a8091eeb3be20911", "tree": "94c28b6948aed7457ad0ed24fc54bb5e63a6ee15", "parents": [ "d3fbea9e960fbd021040d14b68cf3056d598a323" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:24:55 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46275: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -Exploitation requires local TTY control (TIOCSETD to N_HCI,\n HCIUARTSETPROTO ioctl, hangup/close) gated by CAP_NET_ADMIN at\n hci_uart_tty_open(); the bugs are in driver lifecycle teardown, not\n in processing of remote Bluetooth over-the-air packets.\nAC:L -The attacker controls both sides of every race by\n concurrently opening/closing the TTY line discipline, issuing\n HCIUART ioctls, and timing hangup against in-flight workqueues and\n protocol timers; UAF conditions are reliably winnable without\n luck-dependent memory layout.\nPR:L -hci_uart_tty_open() explicitly requires CAP_NET_ADMIN, and\n adapter teardown paths are similarly admin-gated; CAP_NET_ADMIN is\n obtainable by an unprivileged user inside a user namespace,\n satisfying the Low privileges threshold rather than High.\nUI:N -Once the attacker has the required local TTY/HCI access,\n triggering the UAF or double-free races requires no action from a\n separate victim user.\nS:U -The vulnerability corrupts kernel heap memory within the\n kernel\u0027s own security boundary; successful exploitation yields\n kernel privilege escalation, not a cross-boundary escape such as VM\n or sandbox breakout.\nC:H -Multiple use-after-free conditions on the hci_uart and hci_dev\n structures allow dereferencing attacker-influenced freed memory,\n providing a standard kernel info-leak primitive consistent with UAF\n severity guidance.\nI:H -The UAF and hu-\u003etx_skb double-free races enable control of\n freed slab objects and heap grooming, providing a path to arbitrary\n kernel memory corruption and potential code execution in kernel\n context.\nA:H -Use-after-free and double-free in kernel workqueue and\n teardown paths reliably cause kernel oops or panic, and can be\n triggered repeatedly to deny availability of the affected system.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "d3fbea9e960fbd021040d14b68cf3056d598a323", "tree": "b9532c8b9742a3855e2bf8805094183c4507bb78", "parents": [ "dcc3186d3f17ea06efc457e30bac477b9f942a23" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:24:17 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46274: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is reached only through io_uring syscalls\n (io_uring_setup/io_uring_enter) that enqueue and cancel async io-wq\n work; there is no network, adjacent-radio, or physical-device entry\n path to io_wq_remove_pending().\nAC:L -An attacker fully controls the trigger sequence—queue a\n non-hashed async request, queue a hashed bucket-0 request behind\n it, cancel the hashed pending work, let the non-hashed work\n complete, then enqueue another hashed bucket-0 request—with no\n dependence on uncontrollable timing or rare kernel configuration.\nPR:L -Any unprivileged local user who can invoke io_uring (default\n when kernel.io_uring_disabled\u003d0) can drive the cancel/enqueue\n sequence; no real-root or special capability beyond normal local\n process access is required.\nUI:N -Exploitation requires only the attacker\u0027s own io_uring\n submissions and cancellations; no victim user action such as\n opening files or mounting filesystems is needed beyond what the\n attacker initiates.\nS:U -The flaw corrupts kernel heap memory within the same kernel\n security domain to escalate from local user to kernel privileges;\n it does not inherently cross a VM/host or IOMMU boundary on its own.\nC:H -The stale hash_tail pointer is a use-after-free of a freed\n io_kiocb slab object; subsequent dereferences in\n io_wq_insert_work() read freed memory and UAF heap corruption is\n routinely weaponizable for arbitrary kernel memory disclosure.\nI:H -io_wq_insert_work() calls wq_list_add_after(), which writes\n attacker-influenced list pointers through the freed io_kiocb\u0027s\n list.next field, providing a controlled heap write primitive\n suitable for further memory corruption or code execution.\nA:H -Dereferencing and writing through the dangling hash_tail\n pointer can cause kernel oops/panic from invalid slab access, and\n successful heap corruption can crash or hang the system even before\n full exploitation.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "dcc3186d3f17ea06efc457e30bac477b9f942a23", "tree": "6026fb1134ce7260d41345503abfaf2bd7c0a4cf", "parents": [ "ec9d79cf69756d00273849a05a67c72c77592b05" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:24:08 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46277: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is reached only when a ZONE_DEVICE folio is freed via\n `__folio_put()` → `free_zone_device_folio()`, which occurs during\n device-private memory migration teardown (e.g.\n `migrate_vma_finalize()` → `folio_put()` on source folios). That\n path is driven by local process activity—mmap, CPU page faults on\n GPU-resident memory, and concurrent GPU allocation—not by remote\n network packet handling.\nAC:L -Exploitation requires winning a race between `-\u003efolio_free()`\n returning a folio to a driver free list and `percpu_ref_put_many()`\n re-reading `folio-\u003epgmap`, but an attacker can control both sides\n by running concurrent GPU migration and allocation threads on the\n same device. No conditions outside attacker influence (specific\n memory layout, victim state) are required beyond normal GPU\n workload timing.\nPR:L -Triggering device-private folio migration and free requires\n only an unprivileged local user with access to a GPU render node\n (e.g. `/dev/dri/renderD*`, typically granted via the `render`\n group), not real root in the init namespace. No CAP_SYS_ADMIN or\n other elevated capability is needed to exercise the\n migrate/fault/alloc paths that reach `free_zone_device_folio()`.\nUI:N -Exploitation is fully automatable through GPU compute or\n graphics workloads that migrate memory between system RAM and\n device-private VRAM; no victim click, mount, or other deliberate\n interactive action beyond the attacker running their own program is\n required.\nS:U -Successful exploitation corrupts kernel memory and\n `dev_pagemap` refcounts to achieve kernel privilege escalation\n within the host kernel security boundary. It does not inherently\n cross a VM/host or IOMMU/DMA isolation boundary, even though GPU\n cloud tenants are a plausible deployment scenario.\nC:H -After `-\u003efolio_free()`, the folio may be immediately\n reallocated and its metadata overwritten; reading `folio-\u003epgmap`\n afterward is a use-after-free that can dereference\n attacker-influenced or stale pointers. Wrong `percpu_ref` targets\n can also cause premature `pgmap` teardown, enabling further kernel\n memory disclosure.\nI:H -Calling `percpu_ref_put_many()` on a corrupted or wrong\n `pgmap-\u003eref` (potentially with a large `nr` from a huge folio)\n corrupts kernel refcount state and adjacent memory, which is a\n standard path to arbitrary kernel write and control-flow hijack,\n not merely a bounded data change.\nA:H -Incorrect `percpu_ref_put_many()` on a stale or wrong `pgmap`\n can underflow refcounts, trigger use-after-free of `dev_pagemap`,\n or cause immediate kernel BUG/WARN/oops during memory teardown.\n Even without full exploit development, the bug reliably threatens\n kernel crashes and denial of service during device folio free.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "ec9d79cf69756d00273849a05a67c72c77592b05", "tree": "7d701ab960c29d758c546981020b0e356f196bc3", "parents": [ "b3a95e79d646572cc354fd4d378cec6e8c12f2c2" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:21:14 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46280: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -Exploitation requires local syscalls to open the hmm_dmirror\n character device, issue HMM_DMIRROR_MIGRATE_TO_DEV ioctl, close the\n fd, and fault migrated pages; there is no network,\n adjacent-wireless, or physical-device attack path.\nAC:L -The UAF is deterministically triggered by the attacker\u0027s own\n migrate-then-close-then-fault sequence with no race or external\n timing dependency; the attacker fully controls both sides of the\n lifecycle.\nPR:L -The vulnerable ioctl and release paths perform no capability\n or permission checks beyond opening the local character device; any\n local user who can access /dev/hmm_dmirrorN can execute the full\n exploit chain without real root privileges in the init namespace.\nUI:N -No victim interaction is required; the attacker triggers the\n fault themselves by accessing their own migrated pages or aborting\n for coredump after closing the device file.\nS:U -Impact is confined to kernel memory corruption and panic\n within the same kernel security boundary; this is a test-module\n UAF, not a VM escape, IOMMU bypass, or cross-authority sandbox\n breakout.\nC:H -The stale dmirror pointer is dereferenced in\n dmirror_devmem_fault() to read freed kmalloc memory\n (dmirror-\u003emdevice, dmirror-\u003eflags), giving a classic UAF\n information-disclosure primitive.\nI:H -The fault handler continues to use the freed dmirror for\n migration and xa_erase on dmirror-\u003ept, enabling heap reuse attacks\n and arbitrary kernel memory write or code-execution primitives.\nA:H -The bug was reported to cause kernel panic during coredump VMA\n walks, and any UAF page fault on stale device-private pages can\n oops or panic the system.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "b3a95e79d646572cc354fd4d378cec6e8c12f2c2", "tree": "a5eae8d291e9ab157f13280588a66a4c2ee808e9", "parents": [ "23882acb053cd1a3d5d48f280caa49b080b6fcba" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:17:47 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46289: Add CVSS 3.1 score (9.8 CRITICAL)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nAV:N -The vulnerable `extract_kvec_to_sg()` is reached through\n `extract_iter_to_sg()` on the SMB3/CIFS client crypto path\n (`decrypt_raw_data()` → `crypt_message()` → `smb2_get_aead_req()`),\n which processes encrypted SMB traffic received over TCP/445 from a\n remote peer in the `cifsd` demultiplex thread.\nAC:L -When an `ITER_KVEC` iterator spans a page boundary, the bug\n deterministically sets inflated scatterlist lengths\n (`sg_set_page(..., len, off)` instead of `seg`); an attacker can\n choose I/O sizes and offsets to cross page boundaries without races\n or layout luck.\nPR:N -A malicious SMB server operator needs no local privileges on\n the victim host—only an established SMB3 sealed session (common in\n enterprise NAS, cloud file shares, and domain-joined clients) to\n drive encrypted read/write traffic through the affected scatterlist\n construction.\nUI:N -No end-user interaction beyond normal automated SMB client\n operation is required once a share/session exists; the kernel\n processes attacker-supplied encrypted payloads on the network\n receive path without additional victim actions.\nS:U -Impact is kernel memory corruption and privilege escalation\n within the same kernel security domain; it does not cross VM,\n container, or IOMMU boundaries.\nC:H -Inflated scatter-gather lengths cause out-of-bounds reads past\n page boundaries when the malformed scatterlist is consumed by AEAD\n crypto/DMA, yielding arbitrary adjacent-kernel-memory disclosure\n primitives.\nI:H -The same corrupted scatterlist metadata directs crypto/DMA\n writes beyond the intended page, enabling out-of-bounds kernel\n writes and potential control-flow hijack from memory corruption.\nA:H -Scatterlist length corruption during in-kernel AEAD operations\n can cause kernel oops/panic or reliably destabilize the system;\n memory corruption bugs in this path carry high availability impact\n even before full exploitation.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "23882acb053cd1a3d5d48f280caa49b080b6fcba", "tree": "655f5631f84e6e6003458e85af895c4277a67a23", "parents": [ "5aaeb63df4c60cf3ce489988e7d4e2930502c004" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:10:47 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46288: Add CVSS 3.1 score (8.4 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The vulnerable code runs only during late_initcall boot\n self-tests in drivers/of/unittest.c; reaching it requires local\n ability to build and boot a kernel with CONFIG_OF_UNITTEST enabled,\n with no network, syscall, or ioctl runtime path.\nAC:L -Once the unittest kernel boots, the UAF triggers\n deterministically after of_changeset_revert() when of_node_put()\n drops the sole reference; no race or attacker-uncontrolled memory\n layout is required.\nPR:N -Exploitation does not require privileges on a running\n production system—only booting a specially built unittest kernel—so\n no authenticated local user or namespace capability on the target\n image is needed.\nUI:N -The unittest executes automatically during kernel\n initialization after testcase DT data is attached; no additional\n victim interaction beyond booting the test configuration is\n required.\nS:U -The UAF corrupts kernel heap memory during in-kernel\n device-tree self-tests and does not cross VM, sandbox, or IOMMU\n security boundaries.\nC:H -After of_node_put() frees the device_node,\n of_property_present() and of_property_read_string() dereference\n freed memory, enabling kernel information disclosure from\n attacker-influencable freed heap contents.\nI:H -Use-after-free on a struct device_node in kernel heap can be\n leveraged for memory corruption and arbitrary kernel code execution\n via heap grooming, not merely a bounded write.\nA:H -Dereferencing a freed device_node during property lookups can\n cause kernel oops, BUG, or panic during boot-time unittest\n execution.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "5aaeb63df4c60cf3ce489988e7d4e2930502c004", "tree": "7fe5ec18ba2c08390764a9e91f89314eaa09d7dc", "parents": [ "fcca0f6c9fea92ac75d6d0ac5817c13ca745ebd2" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:03:46 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46299: Add CVSS 3.1 score (7.0 HIGH)\n\nCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is only reachable through the local mount syscall\n path (__x64_sys_mount → path_mount → vfs_get_tree → get_tree_bdev →\n hfsplus_fill_super); hfsplus is a block-device filesystem with no\n network-facing handler.\nAC:H -The faulty branch requires hfsplus_cat_build_key() to fail on\n the hardcoded HFSP_HIDDENDIR_NAME string (29 bytes, limit 255),\n which researchers could only trigger by GDB-patching\n max_unistr_len; attackers cannot influence this input via a crafted\n HFS+ image.\nPR:L -Exploitation requires mounting an hfsplus volume, which needs\n CAP_SYS_ADMIN; per kernel CNA guidance this is Low because\n unprivileged users with user-namespace CAP_SYS_ADMIN can mount\n loop-backed filesystems.\nUI:N -No victim interaction is required; the attacker (or their\n user-namespace root) initiates the mount syscall directly to reach\n the vulnerable cleanup path.\nS:U -Impact is confined to kernel memory/locking state during mount\n teardown; it does not cross a VM, container, or IOMMU security\n boundary.\nC:H -Freeing the hfs_btree structure while tree_lock is still held\n corrupts lock lifecycle state and can lead to use-after-free of the\n embedded mutex metadata when the slab is reused, enabling potential\n kernel memory disclosure.\nI:H -The held-lock-during-kfree condition is a memory-management\n corruption bug that can corrupt mutex/lockdep state and potentially\n be leveraged for further kernel memory writes or control-flow\n disruption.\nA:H -The confirmed runtime impact is a lockdep \"held lock freed\"\n warning during mount failure, and freeing kernel structures with\n active locks can cause kernel instability, oops, or panic on\n subsequent lock operations.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "fcca0f6c9fea92ac75d6d0ac5817c13ca745ebd2", "tree": "54eaeb4edb781296a12dc75c19040844f5884beb", "parents": [ "3b4499164ce5145e3f876dd66144dd1fa6d3c5ae" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:03:11 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46303: Add CVSS 3.1 score (8.2 HIGH)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N\n\nAV:N - isofs supports NFS export (export.c), and\n nfsd_readlink()/LOOKUP on an exported mount reach rock_continue()\n through vfs_get_link() and isofs_iget() without any local syscall\n on the attacking host.\nAC:L - The attacker fully controls CE extent, offset, and size in a\n crafted ISO image, so triggering the bad sb_bread() path is\n reliable once the image is mounted and accessed.\nPR:N - A remote NFS client needs only network access to an exported\n isofs mount to invoke symlink readlink and directory inode parsing;\n no CAP_SYS_ADMIN or host root on the attacker\u0027s machine is required.\nUI:N - An attacker with a local shell can loop-mount a malicious\n ISO inside a user namespace (CAP_SYS_ADMIN there) and trigger\n exploitation without any separate victim action.\nS:U - Impact is unauthorized kernel-mediated reads and limited\n inode metadata skew on the same host; there is no VM escape,\n sandbox breakout, or cross-security-authority boundary change.\nC:H - In-range CE extents can cause sb_bread() to fetch blocks from\n an adjacent filesystem on the same device, and mis-parsed Rock\n Ridge SL text is returned to userspace through readlink(),\n constituting unauthorized data disclosure.\nI:L - Adjacent-block data parsed as Rock Ridge PX/PN/CL records\n during inode setup can overwrite inode mode, ownership, device\n numbers, or relocation fields, but there is no arbitrary kernel\n write or memory corruption.\nA:N - Out-of-range blocks fail cleanly through sb_bread()\u0027s\n NULL/EIO path with no oops, panic, or hang; errors propagate as\n -EIO to the calling syscall or NFS operation.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "3b4499164ce5145e3f876dd66144dd1fa6d3c5ae", "tree": "b6b021b4fa2e78ec70e98e2be7900c33c60ca7a1", "parents": [ "836945e31fb813e4405265a91fbc5434f5d877d8" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:02:43 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46306: Add CVSS 3.1 score (7.5 HIGH)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n\nAV:N -The flaw is triggered by a crafted PPPoE session Ethernet\n frame received on a network interface and processed in the core\n packet-receive path (NAPI → `netif_receive_skb_list_internal` →\n `get_rps_cpu` → `__skb_get_hash_net` → `__skb_flow_dissect`), which\n matches kernel guidance for net-stack bugs reachable via received\n packets.\nAC:L -An attacker fully controls the malicious PPPoE PFC frame\n contents; once RPS (or another flow-hash caller such as tc flower\n ingress) is active on the target interface, sending the frame\n reliably reproduces the misaligned IPv4 header access and kernel\n exception without races or victim-specific timing.\nPR:N -Exploitation requires only the ability to transmit Ethernet\n frames to the victim interface; no local account, capabilities, or\n PPPoE session establishment is needed, as confirmed by the fix\n commit reproducing the crash with no active PPPoE session.\nUI:N -No victim user action is required beyond normal network\n operation; the kernel processes the injected frame automatically\n during receive-side RPS flow hashing.\nS:U -Impact is confined to kernel crash/DoS on the affected host;\n there is no cross-boundary escape from a sandbox, VM guest, or\n separate security authority.\nC:N -The bug causes an unaligned load fault while parsing\n attacker-supplied skb data at a wrong offset; it does not perform\n an out-of-bounds read of kernel memory or disclose kernel secrets,\n only misreads bytes within the crafted packet before faulting.\nI:N -There is no memory corruption, arbitrary write, or type\n confusion; the failure mode is a load-address exception on\n strict-alignment architectures (e.g., MIPS) without modifying\n kernel or application data.\nA:H -The documented impact is a kernel exception/oops in\n `__skb_flow_dissect` (MIPS ExcCode 04 unaligned access), which\n crashes or panics the system and can be retriggered remotely by\n resending the malicious frame.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "836945e31fb813e4405265a91fbc5434f5d877d8", "tree": "1e83333199219ea091d71fa014e63952fc616a3a", "parents": [ "64c21361734a172f0031147a147af6de2b7b8bb0" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:59:20 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46307: Add CVSS 3.1 score (8.3 HIGH)\n\nCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L\n\nAV:A -The flaw fires on AR5212 TX completion in the ath5k driver\n when multi-rate retry exhausts to series index 3; an adjacent WiFi\n attacker can induce victim transmissions and RF/rate conditions\n that reach this path without remote Internet routing.\nAC:L -Once AR5212 hardware with ath5k is present, reaching\n `ts_final_idx \u003d\u003d 3` is normal MRR behavior under poor link quality,\n and an attacker can reliably force that state through sustained\n WiFi traffic and interference rather than depending on\n uncontrollable timing or layout.\nPR:N -Exploitation requires no privileges on the victim host; an\n adjacent WiFi peer can trigger victim TX completions through\n standard 802.11 interaction (association, data frames, deauth/retry\n pressure) without local shell or capability-bearing access.\nUI:N -No victim user action such as mounting a filesystem or\n opening a file is required; the bug is hit automatically during\n routine wireless transmit completion handling.\nS:U -Impact is confined to kernel wireless driver TX-status\n metadata on the same host and does not cross VM, container, or\n IOMMU security boundaries.\nC:H -The out-of-bounds write corrupts kernel memory in\n `ieee80211_tx_info.status` (clobbering `ack_signal`), and any OOB\n kernel memory corruption is treated as enabling information\n disclosure through corrupted status data fed back into mac80211.\nI:H -The vulnerability is an out-of-bounds write\n (`rates[ts_final_idx + 1].idx \u003d -1` with `ts_final_idx \u003d\u003d 3`) that\n modifies adjacent kernel metadata beyond the allocated `rates[4]`\n array.\nA:L -The corruption primarily perturbs TX status/rate-control state\n rather than reliably panicking production kernels, but can degrade\n wireless availability through corrupted ACK signal and\n rate-reporting used by mac80211/minstrel.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "64c21361734a172f0031147a147af6de2b7b8bb0", "tree": "1bd49f9a8c89c2c0d83250876721d9b921605f33", "parents": [ "993fff3cb01550fd5fb4ddb730470440129abf6e" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:57:46 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:01 2026 -0400" }, "message": "CVE-2026-46304: Add CVSS 3.1 score (7.5 HIGH)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n\nAV:N -The bug is reached through the NVMe-oF TCP target (nvmet-tcp)\n disconnect/teardown path; remote peers connect over TCP and closing\n that connection drives `nvmet_tcp_release_queue_work()` on\n `nvmet-wq`, which can call the vulnerable `flush_work()` in\n `nvmet_ctrl_free()`.\nAC:L -An attacker fully controls both sides of the race by\n connecting, issuing an Async Event Request (which queues\n `async_event_work` on `nvmet-wq`), and then disconnecting to force\n controller teardown on the same workqueue.\nPR:N -Exploitation requires only network reachability to an exposed\n nvmet-tcp port; the discovery subsystem accepts any host NQN\n without Linux credentials, and no CAP_SYS_ADMIN or other local\n privileges are needed on the target.\nUI:N -The deadlock is triggered entirely through automated NVMe-oF\n protocol interaction (connect, admin command, disconnect) with no\n action required from a local user or administrator.\nS:U -Impact is confined to the kernel NVMe target subsystem\n (workqueue worker hang and nvmet service disruption); it does not\n cross a VM, container, or IOMMU security boundary.\nC:N -This is a recursive workqueue flush deadlock, not memory\n corruption; there is no out-of-bounds access, use-after-free, or\n information disclosure primitive.\nI:N -The flaw causes a worker to block during teardown but does not\n modify arbitrary kernel or user data and provides no write or\n code-execution primitive.\nA:H -Calling `flush_work()` on `nvmet-wq` from\n `nvmet_tcp_release_queue_work()` running on the same workqueue can\n permanently hang an nvmet worker (lockdep reports \"DEADLOCK\"),\n denying NVMe target service and stalling further nvmet workqueue\n processing.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "993fff3cb01550fd5fb4ddb730470440129abf6e", "tree": "efab9ce5339d0f6530b02586055fb9f2a15381fc", "parents": [ "7bbeba411cb70e76a6b3611a1906ffbd9627636e" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:55:01 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46311: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is reached only through local DRM ioctls\n (DRM_IOCTL_AMDGPU_USERQ and DRM_IOCTL_AMDGPU_GEM_VA) on an AMDGPU\n render node (/dev/dri/renderD*), not via any network-facing path.\nAC:L -An attacker controls both sides of the race by running\n concurrent threads that issue USERQ_CREATE and GEM_VA UNMAP/REPLACE\n on the same wptr VA; amdgpu_vm_bo_unmap proceeds even when\n userq_va_mapped is set, making the window reliably triggerable.\nPR:L -Exploitation requires only access to the AMDGPU render node\n (DRM_AUTH|DRM_RENDER_ALLOW), which is available to unprivileged\n local users in the render/video group, not real root in the init\n namespace.\nUI:N -No victim interaction is required; the attacker automates the\n race with concurrent ioctl calls from their own process.\nS:U -The vulnerability corrupts kernel driver state and can lead to\n standard local kernel privilege escalation; it does not cross a VM,\n sandbox, or IOMMU security boundary.\nC:H -Operating on a stale BO pointer without holding locks can\n cause use-after-free and use attacker-replaced mappings, enabling\n arbitrary kernel memory disclosure through freed-object reuse and\n GART mapping confusion.\nI:H -The stale BO can be pinned and mapped into GART while a\n different BO occupies the VA, letting GPU firmware track wptr at\n the wrong physical address and enabling kernel heap corruption via\n UAF on amdgpu_bo structures.\nA:H -Use-after-free on BO reservation/pinning can kernel-oops the\n system, and incorrect wptr GART setup can hang or reset the GPU\n during queue scheduling.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "7bbeba411cb70e76a6b3611a1906ffbd9627636e", "tree": "deed9198e5c646989947e323a4b944ae75ea9830", "parents": [ "11ae7e8136a1ffd989a606cea18ead1431114a5b" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:52:26 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46316: Add CVSS 3.1 score (9.3 CRITICAL)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H\n\nAV:L -The flaw is reached only from KVM guest MMIO traps on GICv3\n ITS registers (GITS_CTLR/CWRITER command processing) and\n redistributor GICR_CTLR LPI-disable writes, not from any\n network-facing host protocol.\nAC:L -A guest controls all racing contexts by pinning vCPUs to run\n concurrent ITS commands, GITS_CTLR disable, and GICR_CTLR\n LPI-disable on the same ITS translation cache; the attacker creates\n and wins the race rather than depending on uncontrollable host\n timing.\nPR:N -No host privileges are required beyond running code in an\n assigned KVM guest (e.g. a cloud VM tenant on arm64); exploitation\n needs guest-kernel access to GIC MMIO, not host root or\n capabilities in the init namespace.\nUI:N -Exploitation is fully attacker-driven from within the guest\n VM and does not require any victim user or administrator action on\n the host.\nS:C -The use-after-free corrupts host-kernel heap memory (`struct\n vgic_irq`) from guest-controlled VGIC operations, crossing the\n guest-to-host virtualization security boundary with VM-escape\n impact.\nC:H -Premature `vgic_put_irq()` frees the LPI `vgic_irq` while an\n ITE still maps it, yielding a kernel heap use-after-free that can\n be leveraged for arbitrary host memory disclosure via subsequent\n IRQ structure dereferences.\nI:H -The dangling `vgic_irq` pointer allows attacker-influenced\n writes through IRQ state fields (`irq_lock`, `pending_latch`,\n `target_vcpu`, list heads), enabling heap grooming and potential\n host control-flow or data corruption.\nA:H -The refcount underflow frees live kernel objects still in use\n by the ITS, causing host kernel oops/panic or hang during\n subsequent LPI delivery, MSI injection, or ITS command handling.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "11ae7e8136a1ffd989a606cea18ead1431114a5b", "tree": "0d8500e4b17379a4f3c351310ae129c85d5b4595", "parents": [ "6788c36af7f048ab7c8b9135c416eb53c9bc4bfb" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:51:42 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46317: Add CVSS 3.1 score (8.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H\n\nAV:L -The bug is reached only through KVM ioctls on /dev/kvm\n (KVM_CREATE_VCPU and KVM_ARM_VCPU_INIT), which drive\n kvm_vcpu_init_nested() while the MMU notifier path runs in the host\n kernel; this is a local syscall/ioctl attack surface, not a network\n protocol.\nAC:L -Exploitation is a race between KVM_ARM_VCPU_INIT reallocating\n nested_mmus and MMU notifier unmaps, and the attacker controls both\n sides by concurrently creating/initializing vCPUs and manipulating\n guest memory regions to trigger kvm_unmap_gfn_range().\nPR:L -The attacker needs access to /dev/kvm with nested\n virtualization enabled (KVM_ARM_VCPU_HAS_EL2), which a cloud tenant\n with nested-virt-capable AArch64 instances can obtain without host\n init-namespace root; this is not unauthenticated network access but\n is below full host administrator.\nUI:N -No victim interaction is required; the race can be driven\n entirely by the attacker\u0027s own KVM and memory-management ioctls\n from userspace.\nS:C -Successful exploitation corrupts host kernel memory from\n within a guest VM\u0027s KVM context, crossing the VM-to-hypervisor\n isolation boundary and enabling host kernel compromise (VM escape)\n on AArch64 cloud servers running nested virtualization.\nC:H -The freed nested_mmus array is a use-after-free; concurrent\n walkers under mmu_lock dereference kvm_s2_mmu structures and their\n page-table pointers, enabling arbitrary kernel memory disclosure.\nI:H -UAF on kvm_s2_mmu objects that contain kvm_pgtable pointers\n and stage-2 page-table state can be leveraged for arbitrary kernel\n writes and control-flow hijacking, not merely a benign crash.\nA:H -Concurrent access to the freed nested_mmus buffer during\n kvm_nested_s2_unmap() or related MMU walks can cause kernel oopses,\n panics, or hangs on the host.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "6788c36af7f048ab7c8b9135c416eb53c9bc4bfb", "tree": "2363d4b0a99180f53fc69c00a21e00e827c12d10", "parents": [ "c3a858cb128bcd96ca48a56ec66e0bf65e8eb42b" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:50:15 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46319: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The UAF is triggered only during act_ct TC action\n configuration via RTM_NEWACTION/RTM_DELACTION or RTM_NEWTFILTER\n netlink messages, not by processing remote network packets. Per\n kernel guidance, tc/netlink qdisc paths are Local attack vector.\nAC:L -The race is between flow-table lookup and refcount increment\n during concurrent create/delete/replace of ct actions, and an\n attacker with CAP_NET_ADMIN controls both sides by issuing parallel\n netlink operations on actions sharing the same zone. UAF races\n where the attacker controls timing are scored AC:L.\nPR:L -All non-GET rtnetlink TC operations require CAP_NET_ADMIN,\n checked in rtnetlink_rcv_msg() and tc_ctl_action(). CAP_NET_ADMIN\n is obtainable by an unprivileged user inside a user+network\n namespace (unshare -Urn), which per kernel guidance is PR:L not\n PR:H.\nUI:N -Exploitation requires only the attacker\u0027s own netlink\n configuration traffic; no victim user action such as opening a file\n or mounting a filesystem is needed.\nS:U -A successful exploit yields kernel-level privilege escalation\n within the same kernel security domain. This is standard local\n kernel compromise, not a cross-boundary escape such as VM\n guest-to-host or IOMMU bypass.\nC:H -The bug is a heap use-after-free on struct tcf_ct_flow_table\n during refcount_inc_not_zero() on memory that\n tcf_ct_flow_table_cleanup_work() may have already kfree()\u0027d. UAF on\n kernel heap objects enables arbitrary memory read primitives and is\n scored C:H.\nI:H -Freed tcf_ct_flow_table slabs can be reallocated and corrupted\n via the dangling refcount operation, providing heap manipulation\n primitives that ZDI and the fix commit describe as leading to\n privilege escalation. Memory corruption UAF is scored I:H.\nA:H -Hitting the UAF during refcount manipulation on freed memory\n can cause kernel oops/panic or deliberate denial of service, and\n UAF bugs inherently threaten availability even when exploitation is\n attempted. Any kernel crash or UAF is scored A:H.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "c3a858cb128bcd96ca48a56ec66e0bf65e8eb42b", "tree": "f1d1299b41e10ea74b068b49230c313b61b32747", "parents": [ "f1147af5ed1e688f1316884504acf9d6f5aeca5c" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:49:40 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46323: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -Exploitation requires a local attacker to inject\n zerocopy/managed-frags skbs via io_uring SEND_ZC, TUN/TAP, or\n similar local APIs; ordinary remote wire packets processed by GRO\n do not carry SKBFL_MANAGED_FRAG_REFS, so a network-only attacker\n cannot reach the buggy merge path.\nAC:L -The attacker fully controls both sides of the GRO merge (seed\n and zerocopy TCP segments over a veth pair), timing (netem delay,\n RST race), and buffer setup; a public working LPE exploit exists,\n so success does not depend on conditions outside attacker control.\nPR:L -Triggering requires only a basic unprivileged local account\n with io_uring and user-namespace access (unshare -Urn), which is\n the default on many distributions; no init-namespace root or\n CAP_NET_ADMIN is needed.\nUI:N -No victim user action is required; the attacker drives the\n entire exploit autonomously through syscalls and local network\n namespace setup.\nS:U -Impact is standard host-kernel privilege escalation (root on\n the same kernel); it does not cross a distinct hypervisor/IOMMU\n security boundary such as VM-guest-to-host escape.\nC:H -The flaw is a use-after-free on page structures; the known\n exploit leverages the refcount underflow to obtain stale read\n access to freed physical pages and extract kernel PTE contents,\n enabling arbitrary memory disclosure primitives.\nI:H -UAF page refcount corruption enables crafting writable PTE\n entries against read-only page-cache pages; the public exploit\n demonstrates integrity compromise by rewriting /etc/passwd and\n obtaining root via su.\nA:H -Use-after-free of page structures can cause kernel oops/panic\n during skb teardown; even failed exploitation attempts can crash\n the system.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "f1147af5ed1e688f1316884504acf9d6f5aeca5c", "tree": "c2bf074860b54cd6541f33e89fd20c3b53ebc34c", "parents": [ "4c3c0976250fac68cb7a5b4063ad2b79d48e5721" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:49:25 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46320: Add CVSS 3.1 score (7.4 HIGH)\n\nCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H\n\nAV:A -The bug is reached when guest-originated TX data crosses the\n virtio/vhost-net/macvtap boundary into the host tap driver; this is\n the same adjacent virtual-network path as CVE-2024-41090, not a\n remote Internet packet to the host stack.\nAC:L -An attacker controls the virtio TX virtqueue and can reliably\n submit frames shorter than ETH_HLEN or force build_skb failures;\n each batch can leak up to 64 page-frags and be repeated in a tight\n loop without race conditions.\nPR:N -In the highest-impact cloud-KVM scenario, a malicious VM\n tenant needs no host credentials or capabilities—only the ability\n to send packets from inside an already-provisioned guest using\n virtio-net.\nUI:N -Exploitation requires no action from the host administrator\n or any other user beyond normal VM operation; the guest attacker\n drives the virtqueue directly.\nS:C -The leak occurs in the host kernel while processing\n guest-supplied descriptors, crossing the VM/host security boundary\n and degrading host-wide availability beyond the guest’s own\n security scope.\nC:N -This is a missing put_page on error paths causing page-frag\n retention; there is no out-of-bounds read, use-after-free, or other\n memory corruption that could disclose kernel data.\nI:N -No memory is corrupted or written beyond the leaked page\n allocation; the bug cannot be leveraged for arbitrary write, code\n execution, or integrity compromise.\nA:H -Sustained submission of short or failing frames leaks one\n page-frag per rejected buffer; at scale this exhausts host memory\n and can trigger OOM kills or host panic, matching the identical\n tun-side fix analysis.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "4c3c0976250fac68cb7a5b4063ad2b79d48e5721", "tree": "aa913ca8cede102d4e38687841b713880dc057bd", "parents": [ "e67d5ea2ed6d990cba56e5e7d6248400b93a6ed9" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:49:11 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46325: Add CVSS 3.1 score (9.8 CRITICAL)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nAV:N -The bug is reached when rxe processes incoming RoCE packets\n over UDP (port 4791) on the responder path for RDMA Read, Write,\n and Atomic operations, which is the standard network-facing\n deployment for software RoCE storage targets and RDMA services.\nAC:L -Once a victim host runs rxe with an FMR whose page_size\n differs from PAGE_SIZE, a remote peer can reliably trigger the\n defective iova-to-VA conversion by sending RDMA operations with\n IOVAs that cross MR page boundaries, as demonstrated in the fix\n commit\u0027s worked examples.\nPR:N -Exploitation requires no OS privileges on the victim host; a\n remote attacker only needs network reachability to an established\n RDMA session (e.g., NVMe-oF or rtrs client) and a valid rkey from\n that connection, not local root or CAP_NET_ADMIN on the target\n system.\nUI:N -No victim user action is required beyond normal operation of\n an RDMA-connected service; the attacker triggers the flaw by\n sending crafted RDMA packets over an existing queue pair.\nS:U -Impact is confined to kernel memory corruption and crashes\n within the same kernel security boundary; this is not a VM escape,\n IOMMU bypass, or cross-authority sandbox breakout.\nC:H -Incorrect iova-to-VA mapping causes memcpy and atomic handlers\n to read from the wrong struct page, enabling disclosure of data\n from unintended pages within the MR mapping and constituting\n out-of-bounds kernel memory read.\nI:H -RDMA Write and Atomic Write operations using the buggy\n conversion write to incorrectly resolved virtual addresses,\n corrupting kernel memory outside the intended MR buffer and\n providing a memory-corruption primitive exploitable for further\n compromise.\nA:H -The fix commit cites a confirmed kernel panic from this\n defect, and misresolved page mappings in rxe_mr_copy() can cause\n oopses or crashes when accessing invalid or misaligned memory.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "e67d5ea2ed6d990cba56e5e7d6248400b93a6ed9", "tree": "e4e6ac7a8e70b53176cd5f5758287efc9db2029e", "parents": [ "170d7cba8038d70a4951c5024dd95459ffab622c" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:48:47 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46322: Add CVSS 3.1 score (7.1 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H\n\nAV:L -The bug is reached only through the TUN `sendmsg()` path with\n `TUN_MSG_PTR`, which in production is driven by host `vhost-net`\n processing virtio-net TX descriptors from a VM guest or a local\n process holding a TUN/vhost-net fd—not by the host parsing remote\n network packets.\nAC:L -An attacker can reliably trigger `build_skb()` failure by\n first pressuring the `sk_buff` slab (e.g., flooding virtio TX or\n other allocations) and then sending batched virtio TX frames; they\n control both the memory-pressure side and the batch submission side.\nPR:N -In the highest-impact scenario—a malicious tenant in a\n cloud/KVM guest with virtio-net and vhost-net—the attacker needs no\n host privileges; any guest process that can transmit on the virtio\n TX queue can drive this path.\nUI:N -Exploitation requires no victim interaction beyond normal VM\n networking; the guest attacker can trigger the leak\n programmatically without the host user performing any action.\nS:C -The leak consumes host kernel memory from a guest VM security\n context, crossing the VM/host boundary and impacting resources\n outside the attacker\u0027s guest security authority.\nC:N -This is a pure page reference leak with no out-of-bounds\n access, use-after-free, or attacker-readable disclosure; leaked\n pages remain in the kernel allocator and are not exposed to the\n attacker.\nI:N -No memory corruption, arbitrary write, or control-flow hijack\n occurs; the only defect is failing to `put_page()` on the\n `build_skb()` error path.\nA:H -Each failed `build_skb()` leaks a page-frag (~4 KiB), batches\n can hold up to 64 XDP buffers, and `tun_sendmsg()` masks per-buffer\n errors so leaks are unbounded and repeatable, enabling sustained\n host kernel memory exhaustion and OOM/DoS.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "170d7cba8038d70a4951c5024dd95459ffab622c", "tree": "a63d3d578256f7c18baf71708215c012b77db2ce", "parents": [ "f2f4d2d597f4217bcd4113866e6d3a645fddee94" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:48:40 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46321: Add CVSS 3.1 score (7.1 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H\n\nAV:L -The flaw is reached via local host interfaces (/dev/net/tun\n and /dev/vhost-net ioctls/sendmsg) or from a KVM guest through\n virtio-net TX descriptors processed by vhost-net, not via remote\n network packets to the host stack.\nAC:L -An attacker reliably triggers the leak by repeatedly\n submitting TX frames whose length minus the virtio-net header is\n below ETH_HLEN; no races or attacker-uncontrollable layout\n conditions are required.\nPR:N -A malicious KVM guest on a host using vhost-net with a\n tun/tap backend needs no host privileges—only the ability to craft\n short virtio-net TX descriptors—while a direct host attacker can\n also obtain CAP_NET_ADMIN via unprivileged user namespaces.\nUI:N -Exploitation requires no victim interaction beyond normal VM\n or namespace operation; the attacker drives the vhost TX path\n directly in a tight loop.\nS:C -In the highest-impact cloud/KVM deployment, an unprivileged\n guest VM crosses the hypervisor security boundary to exhaust host\n kernel memory and panic the host, affecting resources outside the\n guest\u0027s security scope.\nC:N -The bug is a page-fragment memory leak with no out-of-bounds\n access, use-after-free, or information disclosure; freed pages are\n simply never returned to the allocator.\nI:N -No kernel memory corruption or data modification occurs; the\n only effect is unbounded consumption of page-frags leading to\n denial of service.\nA:H -Sustained submission of short batched frames leaks one\n page-frag per frame, exhausts host memory, and can trigger an OOM\n kernel panic as described in the fix commit.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "f2f4d2d597f4217bcd4113866e6d3a645fddee94", "tree": "92daafe9e761eaabc624193ec9c0069b31309b60", "parents": [ "1e65403729075bede1065bedd38f4a9d0e0439f7" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:47:13 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46324: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is in nf_tables netdev hook teardown reached only via\n Netfilter netlink (nft) syscalls—chain/flowtable updates, dumps,\n netns teardown, and netlink socket release—not from remote packet\n handling alone. Per kernel guidance, nftables/netfilter is Local\n (L).\nAC:L -Exploitation is a race between hook-list removal\n (`list_del()` + RCU free) and concurrent RCU walkers\n (`nft_dump_basechain_hook_list`, flowtable dump, or packet-path\n `list_for_each_entry_rcu`). An attacker with CAP_NET_ADMIN can\n drive both sides concurrently (e.g., one thread dumping\n chains/flowtables while another deletes hooks or tears down the\n netns).\nPR:L -All nf_tables netlink operations are gated by\n `netlink_net_capable(skb, CAP_NET_ADMIN)` in `nfnetlink_rcv()`.\n CAP_NET_ADMIN is obtainable by an unprivileged user via\n user+network namespaces (`unshare -Urn`), not real init-namespace\n root.\nUI:N -No victim interaction is required; the attacker triggers hook\n teardown and concurrent dumps or traffic entirely through their own\n netlink sockets and namespace lifecycle.\nS:U -Impact is confined to kernel memory corruption and privilege\n escalation within the same kernel security domain; it does not\n inherently cross VM, container, or IOMMU boundaries.\nC:H -Using `list_del()` instead of `list_del_rcu()` on lists walked\n under `rcu_read_lock()` is a use-after-free/list-corruption bug;\n concurrent dumpers dereference `nft_hook` fields (e.g., `ifname`)\n after unlink/free, enabling arbitrary kernel memory read via heap\n grooming.\nI:H -The freed `nft_hook` kmalloc object can be reallocated and\n corrupted through the dangling RCU list pointers, providing a\n standard kernel UAF primitive exploitable for arbitrary write and\n control-flow hijacking.\nA:H -The race reliably causes kernel list corruption and\n use-after-free, leading to oops/panic during hook dumps, flowtable\n lookups, or netns cleanup; UAF in this path has inherent high\n availability impact even when not fully weaponized.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "1e65403729075bede1065bedd38f4a9d0e0439f7", "tree": "bd18e08c151ef4834042f5e231257b4b24b4df2a", "parents": [ "949c544901165dcfd43da0c0c5cc4b908aff072b" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:46:53 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46328: Add CVSS 3.1 score (7.3 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H\n\nAV:L -The vulnerable code is only reached via the execve()\n credential-commit path (security_bprm_committing_creds →\n apparmor_bprm_committing_creds → __aa_transition_rlimits),\n requiring a local syscall with no network-facing entry point.\nAC:L -An attacker who can exec between AppArmor profiles with\n differing RLIMIT_CPU rules controls both the transition timing and\n CPU consumption beforehand, making the stale\n posix_cputimers.nextevt condition reliably triggerable whenever\n policy permits the exec.\nPR:L -Exploitation requires only an unprivileged local process\n already confined by AppArmor that is permitted to exec into a\n different profile; no real root or capabilities beyond what the\n AppArmor policy already grants are needed.\nUI:N -No victim interaction is required; the attacker triggers the\n bug by executing a binary that causes an AppArmor profile\n transition on their own process.\nS:C -The bug breaches the AppArmor MAC security boundary by\n allowing a confined process to exceed administrator-defined\n RLIMIT_CPU constraints that policy intended to enforce, impacting\n host resources beyond what the profile permits.\nC:N -The flaw desynchronizes a timer expiration cache from rlimit\n values; it does not read kernel memory, leak pointers, or provide\n any information disclosure primitive.\nI:L -While not arbitrary memory write, bypassing AppArmor-enforced\n CPU hard limits is a limited but real integrity failure of the\n security policy’s resource enforcement, allowing a confined process\n to exceed mandated constraints.\nA:H -A stale high nextevt lets confined workloads exceed CPU caps\n and exhaust CPU on shared Ubuntu/cloud hosts, and a stale low\n nextevt can deliver premature SIGXCPU that terminates confined\n services; both constitute high availability impact even without a\n kernel panic.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "949c544901165dcfd43da0c0c5cc4b908aff072b", "tree": "60e8becafcbb3f73063890f6f1a2fd56c51b13e1", "parents": [ "0087f31ef54d22e27ec5f2996078048329083bb0" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:46:52 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46326: Add CVSS 3.1 score (8.4 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is reached only through local kernel interfaces (IIO\n sysfs reads or buffered IIO character-device access) that invoke\n mpr_spi_xfer(); there is no network-facing or pre-auth remote code\n path to this driver.\nAC:L -On any system with the SPI driver bound to a Honeywell MPR\n sensor, an attacker can trigger the uninitialized spi_transfer on\n every pressure read with a simple, repeatable sysfs access; no race\n or attacker-uncontrollable memory layout is required.\nPR:N -IIO in_pressure_raw sysfs attributes are world-readable\n (0444), so any local unprivileged user can invoke the vulnerable\n SPI transfer without capabilities or namespace elevation.\nUI:N -Exploitation requires only the attacker reading the sensor\n sysfs node; no victim interaction such as plugging hardware or\n mounting filesystems is needed.\nS:U -Impact is confined to kernel memory and SPI subsystem state on\n the same host; it does not cross a VM, container, or IOMMU security\n boundary.\nC:H -Stack garbage in spi_transfer fields (especially transfer_list\n and DMA mapping flags) corrupts SPI core linked lists and mapping\n state, enabling arbitrary kernel memory reads during exploitation\n of the resulting corruption primitive.\nI:H -The same uninitialized fields produce out-of-bounds\n linked-list manipulation and potential erroneous DMA unmap\n operations, which are classic kernel memory-corruption primitives\n that can be leveraged for arbitrary write and code execution.\nA:H -Corrupting spi_message transfer lists or SPI/DMA teardown\n paths can cause immediate kernel oops/panic or sustained denial of\n service via malformed CS/delay handling on the SPI bus.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "0087f31ef54d22e27ec5f2996078048329083bb0", "tree": "d540ee859e8fbdb3a0a9bac6aecaa5800a1bb50e", "parents": [ "47c71f94ac9e3a3450b756d20fcb656f3de793ff" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:46:31 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46327: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The vulnerable code is reached only through local block-layer\n ioctls (BLKREPORTZONE/BLKREPORTZONEV2 via\n blkdev_report_zones_ioctl) and device-mapper control ioctls that\n trigger dm_swap_table/dm_revalidate_zones; there is no\n network-facing entry point.\nAC:L -Exploitation is a TOCTOU race between concurrent\n BLKREPORTZONE calls and a zoned dm table activation/revalidation;\n an attacker can control both sides by running parallel threads and\n retrying until the window is hit, without depending on\n uncontrollable timing or memory layout.\nPR:L -Triggering dm table load/swap and zone revalidation requires\n CAP_SYS_ADMIN, which is obtainable by an unprivileged user inside a\n user namespace (unshare -Urn); BLKREPORTZONE additionally requires\n read access to the dm block device, which the same attacker can\n grant when creating the device.\nUI:N -No victim interaction is required once the attacker has the\n needed privileges and device access; the race can be driven\n entirely by attacker-controlled ioctl threads during dm-crypt zoned\n table setup.\nS:U -The use-after-free corrupts kernel heap metadata and\n zone-write-plug structures within kernel memory; it does not cross\n a VM, container, or IOMMU security boundary to affect a separate\n authority.\nC:H -The bug revives the CVE-2025-38141 class use-after-free where\n disk_free_zone_resources() can free zone_wplugs_hash/zones_cond\n while dm_blk_report_zones() still reads them through the live table\n path, enabling disclosure of freed kernel heap contents.\nI:H -Use-after-free on zone write plug and zone-condition\n structures provides attacker-influencable heap corruption\n primitives that can be developed into arbitrary kernel memory\n writes or control-flow hijack, not merely a bounded modification.\nA:H -Concurrent access to freed zone resources during failed\n blk_revalidate_disk_zones() can cause kernel oops/panic from\n dereferencing freed zone_wplugs_hash, zones_cond, or related\n structures, even when full exploitation is not attempted.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "47c71f94ac9e3a3450b756d20fcb656f3de793ff", "tree": "d83aa40850e09dd38b58e8b92be1274d84463b43", "parents": [ "2f5c8d6dcdace7df5018cd92578d8024ad04a22b" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:45:22 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46330: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The vulnerable code is reached only via the local\n setsockopt(TCP_ULP, \"smc\") syscall on a TCP socket owned by the\n caller; smc_ulp_init() is not invoked from packet receive or any\n remote network path.\n The bug is triggered exclusively through the setsockopt(2) syscall\n on a TCP socket owned by the attacker; smc_ulp_init() is registered\n as a TCP ULP handler and is invoked from do_tcp_setsockopt() →\n tcp_set_ulp(), not from any network packet-receive or remote\n protocol path.\nAC:L -On systems with CONFIG_SMC enabled, an attacker fully\n controls socket creation, the pre-connect setsockopt call, and\n subsequent close/dup/fork races needed to trigger the corrupted VFS\n state and resulting UAF.\n An attacker fully controls socket creation, the setsockopt(TCP_ULP,\n \"smc\") call, and subsequent lifecycle operations (close, dup,\n connect); once preconditions are met the VFS corruption in\n smc_ulp_init() is deterministic and UAF/double-free can be provoked\n on demand without conditions outside attacker control.\nPR:L -Any unprivileged local user who can open a TCP socket may\n call setsockopt(TCP_ULP); module autoload uses CAP_NET_ADMIN which\n is obtainable in user namespaces, and no real-root capability is\n required when SMC is already loaded.\n No real-root capability is required—any unprivileged local user who\n can create a SOCK_STREAM TCP socket and call setsockopt on it can\n reach smc_ulp_init(), including via user namespaces; TCP_ULP has no\n CAP_NET_ADMIN gate (unlike TCP congestion control), and module\n autoload is only needed if SMC is not already loaded.\nUI:N -Exploitation requires no action from another user or\n administrator; the attacker triggers the bug directly through their\n own socket file descriptor.\n Exploitation requires no action from a victim user; a local\n attacker can open a socket, invoke setsockopt(TCP_ULP, \"smc\"), and\n trigger the corrupted VFS state through normal close/dup operations\n in their own process.\nS:U -Impact is confined to kernel memory corruption and privilege\n escalation within the same kernel security boundary, not a\n cross-boundary escape such as guest-to-host or IOMMU bypass.\n Impact is confined to kernel memory corruption and privilege\n escalation within the same kernel security authority; this is not a\n VM escape, IOMMU bypass, or cross-security-boundary escape.\nC:H -The in-place swapping of file, dentry, and inode pointers\n breaks VFS lifetime invariants and creates use-after-free\n conditions that can be leveraged for arbitrary kernel memory\n disclosure.\n The in-place swapping of file, dentry, and inode pointers breaks\n VFS lifetime invariants and creates use-after-free conditions that\n can be leveraged for arbitrary kernel memory disclosure.\n The fix commit and Al Viro\u0027s report explicitly identify\n use-after-free risk from in-place modification of struct file,\n dentry, and inode on an open file descriptor, which can yield\n arbitrary kernel memory read primitives through corrupted\n inode/file reference counting.\nI:H -UAF and broken VFS reference counting on live file descriptors\n enable heap grooming and arbitrary kernel write/control-flow\n hijacking, not merely a bounded or cosmetic corruption.\nA:H -The design flaw causes use-after-free, double-free, and\n general system instability during file close/__fput paths, readily\n producing kernel oops/panic and complete denial of service on\n affected IBM Z/RoCE systems running SMC.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "2f5c8d6dcdace7df5018cd92578d8024ad04a22b", "tree": "c7461b6c52741fe48c2ca38f642bd164904c6a8f", "parents": [ "2d303c149f3530bf31768cbd102a2a9d09ecd9e6" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:44:39 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-46332: Add CVSS 3.1 score (8.0 HIGH)\n\nCVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\n\nAV:A -The bug is reached only when the onboard CC1352 co-processor\n delivers bootloader UART data to `gb_tty_receive()` via serdev\n during `flashing_mode`; on BeaglePlay/BeagleConnect deployments\n that co-processor is a sub-GHz/BLE radio bridge, so an attacker in\n adjacent wireless range who compromises or replaces it can supply\n the malicious serial responses that trigger the overflow.\nAC:L -Once firmware flashing is active, an attacker controlling\n CC1352 bootloader replies can reliably exceed the 259-byte\n `rx_buffer` by combining leftover staged bytes with oversized\n serdev chunks across callbacks, making the `memcpy()` overflow\n deterministic rather than race-dependent.\nPR:N -Exploitation does not require Linux credentials on the host;\n a physical or radio-adjacent attacker only needs the co-processor\n to send malicious bootloader bytes while `flashing_mode` is active,\n which can occur during an administrator-initiated update without\n the attacker holding any local account.\nUI:R -The vulnerable `cc1352_bootloader_rx()` path is gated on\n `flashing_mode`, which is set only when an operator initiates\n CC1352 firmware upload through the sysfs firmware-upload interface,\n so a separate privileged maintenance action must occur first.\nS:U -Corruption is confined to the `gb_beagleplay` driver\u0027s\n kmalloc\u0027d private structure and enables standard kernel privilege\n escalation within the same security domain, not a cross-boundary\n escape such as guest-to-host or IOMMU bypass.\nC:H -The unchecked append is a heap out-of-bounds write past\n `rx_buffer[MAX_RX_HDLC]` into adjacent driver fields (pointers,\n completions, control flags), which is memory corruption that can be\n leveraged for arbitrary kernel memory disclosure.\nI:H -Overflowing `rx_buffer` overwrites kernel pointers and control\n structures in the same allocation (`fwl`, GPIO descriptors,\n completion objects), providing a credible path to arbitrary kernel\n writes and control-flow hijacking beyond a simple crash.\nA:H -Writing past the fixed receive buffer can immediately corrupt\n critical in-structure kernel data and cause kernel oops/panic, and\n repeated malicious bootloader chunks can be used to trigger\n persistent denial of service during flashing.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "2d303c149f3530bf31768cbd102a2a9d09ecd9e6", "tree": "3db776caddf65fa86fa616d11104845adade00a6", "parents": [ "2623262550ec6f09a716f870bc7096d46131aefe" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:44:35 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-52906: Add CVSS 3.1 score (7.7 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\n\nAV:L -The flaw is reached through local mount and VFS\n file-operation syscalls (open, read, write, setattr) on a 9p client\n mount, not through remote packet handling. Even when 9p uses virtio\n or TCP transport, exploitation requires local access to the mounted\n filesystem or local CAP_SYS_ADMIN to mount with the triggering\n options.\nAC:L -An attacker who can mount 9p with 9P2000.L and `access\u003duser`\n or `access\u003d\u003cuid\u003e` reliably triggers the bug on every fid lookup. On\n systems where virtio-9p is already mounted with those options,\n exploitation requires only normal filesystem access with no race or\n special timing.\nPR:N -Exploitation against an already-mounted vulnerable 9p share\n requires no elevated privileges—only local shell access to the\n mount point. The worst case (`access\u003d\u003cuid\u003e` SINGLE mode) is meant\n to block all other users, yet any unprivileged local user can still\n obtain fids and access the share.\nUI:N -Once a vulnerable 9p filesystem is mounted, no further victim\n interaction is required; the attacker simply performs normal file\n operations. Mounting with the triggering options is\n attacker-controlled or a one-time administrative setup, not ongoing\n user interaction at exploitation time.\nS:U -Impact is confined to unauthorized access within the\n guest/kernel filesystem boundary (bypassing 9p access-mode\n isolation between local users or against a single-user mount\n restriction). It does not cross VM-to-host, IOMMU, or sandbox\n security boundaries beyond the shared 9p export itself.\nC:H -The mangled access mask forces all operations through a shared\n INVALID_UID attach instead of per-user attaches, breaking\n confidentiality guarantees of `access\u003duser` and completely\n defeating `access\u003d\u003cuid\u003e` SINGLE-mode isolation. Unprivileged users\n can read data on mounts explicitly restricted to another user.\nI:H -The same fid-lookup failure lets unauthorized users perform\n writes through the shared INVALID_UID attach on mounts where SINGLE\n or per-user modes should have prevented any access. Server-side\n authorization keyed to attach identity is undermined, enabling\n unauthorized modification of files on the export.\nA:N -The bug is a logic error in access-mode handling that\n misroutes fid lookups; it does not cause kernel oops, panic, hang,\n or repeatable denial of service. Root losing chown capability on\n the mount is a localized authorization failure, not system-wide\n availability loss.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "2623262550ec6f09a716f870bc7096d46131aefe", "tree": "6ccee64cd3e6456b8b46e15d463817e3091f1494", "parents": [ "04e3f6bc4080bdd4a579598fc596f1d3039b4bfe" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 09:44:05 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 10:28:00 2026 -0400" }, "message": "CVE-2026-52907: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The vulnerable register helpers are reached only through\n local V4L2 capture device access (open/ioctl/streamon) on Rockchip\n RK3568 VICAP MIPI nodes, not via any network protocol.\nAC:L -No races or special memory layout are required; once\n out-of-range block/id/index values reach the helpers, the\n off-by-one access and resulting MMIO operations occur\n deterministically during normal streaming or IRQ handling.\nPR:L -Exploitation requires only local access to the V4L2 video\n capture device node (typically granted to unprivileged users in the\n video group), not root in the init namespace or special\n capabilities.\nUI:N -An attacker with access to the capture device can trigger the\n code path themselves via standard V4L2 streaming ioctls without\n requiring action from another user.\nS:U -Impact is confined to kernel/driver memory and Rockchip VICAP\n hardware programming within the same security authority; there is\n no VM, container, or IOMMU boundary crossing.\nC:H -The flaw is an out-of-bounds read of kernel match_data\n register tables; per guidance, OOB reads can leak adjacent kernel\n memory and enable crafting unintended MMIO offsets.\nI:H -The OOB-read value is summed into a hardware register address\n used by writel(), enabling misdirected MMIO writes including DMA\n address registers programmed during buffer queue operations.\nA:H -Out-of-bounds access can trigger KASAN/KFENCE faults or\n misprogrammed capture hardware leading to kernel oops, panic, or\n hung capture on affected Rockchip embedded systems.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "04e3f6bc4080bdd4a579598fc596f1d3039b4bfe", "tree": "63cf34b0c74a0e3999a19c929ea7ab4b3ad4bbcc", "parents": [ "89bb68d9009996aa05388c91e42c1dbc96bce1de" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 08:49:57 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Wed Jun 10 08:49:57 2026 -0400" }, "message": "sasha: review v7.0.12\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "89bb68d9009996aa05388c91e42c1dbc96bce1de", "tree": "cfece4ecfad57df22a67f9147c606c504722626e", "parents": [ "98d258a280f715db91eb2a40230523dfc087f2e3" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:36:16 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:36:16 2026 +0200" }, "message": "strip the new mbox files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "98d258a280f715db91eb2a40230523dfc087f2e3", "tree": "fe4bc157bcd58c042bdec0ec25d27a04f03fb02f", "parents": [ "0524da57752e84d7166509014ecebb8ffbceeff1" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:35:41 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:35:41 2026 +0200" }, "message": "mark 7.0.4 as done\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "0524da57752e84d7166509014ecebb8ffbceeff1", "tree": "0cdadbfd5fc6b6d4b6518b6a465b4f7eb2fd77d2", "parents": [ "e0d12ee722d875810d1895c4f71fc7cb86c7f73d" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:35:21 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:35:21 2026 +0200" }, "message": "some final 7.0.4 cve ids assigned\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "e0d12ee722d875810d1895c4f71fc7cb86c7f73d", "tree": "6794167ef1dc74311c6162bc92706c44254b994c", "parents": [ "124b31825976b5025bced62242a8eb50867c2863" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:33:30 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:33:30 2026 +0200" }, "message": "update the 7.0.4 review from greg\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "124b31825976b5025bced62242a8eb50867c2863", "tree": "f44708b9f3c6b6501dad6aba21079f3baca05351", "parents": [ "5d1fc020aa156738767878f68b325f309e6aa2c1" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:28:04 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:28:04 2026 +0200" }, "message": "move 6.19 reviews to their own subdir\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "5d1fc020aa156738767878f68b325f309e6aa2c1", "tree": "c8f5f617870c6cc1da8a353c1560548a7e7c415a", "parents": [ "7cfa45ba5a2cfb128c0de3ce8aeaaf54330441ae" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:27:31 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:27:31 2026 +0200" }, "message": "mark 6.19.4 review as completed\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "7cfa45ba5a2cfb128c0de3ce8aeaaf54330441ae", "tree": "3e89903d7d4b34d96b19de5e319c9d0d8ed261c5", "parents": [ "925318309121b730c6777cf969f1b302ee49e28d" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:25:16 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:25:16 2026 +0200" }, "message": "assign some more 6.19.4 cve ids\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "925318309121b730c6777cf969f1b302ee49e28d", "tree": "baa5122bb3c30c6c11fad779fc506515e2a3224c", "parents": [ "a496f2c25c09edb0cba31c1983514ed85f9b1df0" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:21:16 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:21:16 2026 +0200" }, "message": "update the 6.19.4 reviews from greg\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "a496f2c25c09edb0cba31c1983514ed85f9b1df0", "tree": "5dad520318d1963d5caddb2e08bfb12577635c9a", "parents": [ "218531520f0f62f6da053622f76f455a8a579b32" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:11:28 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:11:28 2026 +0200" }, "message": "strip the new mbox files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "218531520f0f62f6da053622f76f455a8a579b32", "tree": "c6c2f624a8de43c4b54b75c4cee8a7d48355572a", "parents": [ "1a3c8d1c270e1c69fed8bb2c5533adcb0613fe19" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:10:32 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 14:10:32 2026 +0200" }, "message": "assign some more CVE ids on request\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "1a3c8d1c270e1c69fed8bb2c5533adcb0613fe19", "tree": "c79b132076bd3c668b4925eb8199618b77e30946", "parents": [ "b0632c81f2f7a8bed9ed6f36aa5ad97a71a61284" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:55:26 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:55:26 2026 +0200" }, "message": "strip new mbox files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "b0632c81f2f7a8bed9ed6f36aa5ad97a71a61284", "tree": "54e7b980ca97cf2a0f300acbdb6a5ba201b3f987", "parents": [ "efdc55fb0d59dc221f7c79e30ea0c7c4a0339825" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:52:10 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:52:10 2026 +0200" }, "message": "actually add the new cve ids...\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "efdc55fb0d59dc221f7c79e30ea0c7c4a0339825", "tree": "c78880e778a2939e21a02a344f49ed9a02bc0157", "parents": [ "a1e3de8fbc213024fe5207dd6b8fcace098fa5f4" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:51:42 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:51:42 2026 +0200" }, "message": "assign some CVE ids on request\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "a1e3de8fbc213024fe5207dd6b8fcace098fa5f4", "tree": "476a1887a2225c8c2c73ebaf935fc9a7658120f7", "parents": [ "1c9cd9cfae0169e8cb8c005fb9cc76954b298e7b" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:49:53 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 13:49:53 2026 +0200" }, "message": "updates based on new stable releases\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "1c9cd9cfae0169e8cb8c005fb9cc76954b298e7b", "tree": "450b5b3a70febfe2b8130c03eeb3279ef6db9284", "parents": [ "8c934adcd3e4fe846c2993d4854b5015eee8050b" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:43:56 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:43:56 2026 +0200" }, "message": "reserve some more 2026 cve ids\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "8c934adcd3e4fe846c2993d4854b5015eee8050b", "tree": "5b0a7ec919ae0aa931db38302f26e0206647d28b", "parents": [ "c7ba9abee433be6e73eb0b86828de129e7e6e53e" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:42:56 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:42:56 2026 +0200" }, "message": "strip the new mbox file\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "c7ba9abee433be6e73eb0b86828de129e7e6e53e", "tree": "5b527cdb56ac9a2ed0b6bb7d383b198d99920a75", "parents": [ "af7a1582110ac6ff2fc84ecf00509477cc9426aa" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:41:46 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:41:46 2026 +0200" }, "message": "assign a CVE id on request\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "af7a1582110ac6ff2fc84ecf00509477cc9426aa", "tree": "15f5af549a1b26dcea9d4065cd5cf22bfa2fc100", "parents": [ "82739d4d285c68edf1334df2b65fcc8589dbf911" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:36:45 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Tue Jun 09 09:36:45 2026 +0200" }, "message": "updates based on new .vulnerable files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "82739d4d285c68edf1334df2b65fcc8589dbf911", "tree": "4d5cf144458f301f29c6dffe23d56ca0c880847b", "parents": [ "2ab8e982e902fd3c44e7360dc5bcb031b0cdaa62" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:52:02 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:52:02 2026 -0400" }, "message": "CVE-2026-46311: Add .vulnerable file\n\nThe fix (6da7b1242da4455b11c24ce667d1cab1a348c8ea) is the cherry-pick\nof upstream 1fc6c8ab45dbee096469c08c13f6099d57a52d6c (\"drm/amdgpu/userq:\nfix access to stale wptr mapping\", Cc: stable). It rewrites\nmes_userq_create_wptr_mapping() in\ndrivers/gpu/drm/amd/amdgpu/mes_userqueue.c.\n\nWhen a usermode queue is created, the MES firmware needs the queue\u0027s\nwptr buffer object mapped into GART. mes_userq_create_wptr_mapping()\ntranslates the user-supplied wptr GPU virtual address into a BO and pins\nit. The vulnerable code did:\n\n\tamdgpu_bo_reserve(wptr_vm-\u003eroot.bo, false); // lock VM page-dir\n\twptr_mapping \u003d amdgpu_vm_bo_lookup_mapping(wptr_vm, wptr \u003e\u003e PAGE_SHIFT);\n\tamdgpu_bo_unreserve(wptr_vm-\u003eroot.bo); // \u003c-- lock DROPPED here\n\tif (!wptr_mapping) { ... }\n\n\twptr_obj-\u003eobj \u003d wptr_mapping-\u003ebo_va-\u003ebase.bo; // \u003c-- mapping used UNLOCKED\n\t... wptr_obj-\u003eobj-\u003etbo.base.size ...\n\tret \u003d mes_userq_map_gtt_bo_to_gart(wptr_obj-\u003eobj); // reserves wptr_obj separately, later\n\nThe VM page-directory reservation that protects the VM\u0027s mapping tree\nis released immediately after the lookup, but the returned wptr_mapping\n(and wptr_mapping-\u003ebo_va-\u003ebase.bo) is then dereferenced, size-checked,\nref\u0027d, pinned and GART-mapped outside any lock. The wptr_obj BO itself\nis never locked during the lookup-\u003euse window.\n\nThis is a classic TOCTOU. From another thread, a process can issue\namdgpu_gem_va_ioctl(...UNMAP...) on that wptr VA while the queue\ncreation is in flight: the amdgpu_bo_va_mapping gets freed (stale\npointer / use-after-free), and a different BO can be mapped at the same\nvirtual address. The in-progress queue creation then pins and hands the\nfirmware whatever BO now sits at that address - exactly what the commit\nmessage describes: \"unmap the wptr_obj while a queue creation is in\nprogress and passing other bo at same address.\"\n\nThe fix uses drm_exec to hold both the VM root page-directory and the\nwptr_obj BO reservation across the entire lookup -\u003e amdgpu_bo_ref -\u003e\nsize check -\u003e amdgpu_bo_pin -\u003e amdgpu_ttm_alloc_gart sequence, so the\nmapping cannot be torn down or substituted mid-operation.\n\nRoot-cause commit: 5fb2f7fc21a3668e5794cc0d153641b9719713e1\n\n\"drm/amdgpu: map wptr BO into GART\" - Shashank Sharma, 2024-04-22,\nfirst released in v6.16-rc1.\n\nThis commit introduced the function (originally\nmes_v11_0_create_wptr_mapping() in mes_v11_0_userqueue.c) with the buggy\nunreserve-before-use pattern present verbatim from day one. The flaw is\nessentially the same lines the fix removes:\n\n\twptr_mapping \u003d amdgpu_vm_bo_lookup_mapping(wptr_vm, wptr \u003e\u003e PAGE_SHIFT);\n\tamdgpu_bo_unreserve(wptr_vm-\u003eroot.bo); // dropped before use\n\twptr_obj-\u003eobj \u003d wptr_mapping-\u003ebo_va-\u003ebase.bo;\n\nNotably, the commit\u0027s own changelog records Christian Konig\u0027s V5 review\nfeedback - \"All the handling must be done with the VM locks held\" - yet\nthe implementation drops the lock right after the lookup, defeating\nexactly that requirement.\n\nTrace-back proof that nothing earlier is responsible:\n\n- git log -S \u0027amdgpu_bo_unreserve(wptr_vm-\u003eroot.bo)\u0027 -- \u0027*userqueue.c\u0027\n returns exactly two commits: the introduction 5fb2f7fc21a366 and its\n removal by the fix (336a9186f3a4b6 on master). No commit in between\n ever touched the lock-drop line.\n- The function was renamed/moved by 79819d9a0ac38b (\"drm/amdgpu/uq: make\nMES UQ setup generic\", mes_v11_0_* -\u003e mes_userq_*, relocated into\nmes_userqueue.c) - pure code movement that preserved the buggy logic.\n- Later churn only changed cosmetics (amdgpu_bo_gpu_offset_no_check -\u003e\n amdgpu_bo_gpu_offset, the function signature). The lock semantics were\n never altered between introduction and fix.\n\nThe root cause was introduced by\n5fb2f7fc21a3668e5794cc0d153641b9719713e1, which added\nmes_v11_0_create_wptr_mapping() releasing the VM page-directory\nreservation before consuming the looked-up mapping and without ever\nlocking the wptr BO - creating the stale/substitutable-mapping race that\nCVE-2026-46311 fixes.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "2ab8e982e902fd3c44e7360dc5bcb031b0cdaa62", "tree": "a5661539edeb83a5c5a00deb80cc5418aee94385", "parents": [ "a286a8ee96fa68827a8e5fbe2c12c2ef1f53392a" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:47:26 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:47:26 2026 -0400" }, "message": "CVE-2026-46302: Add .vulnerable file\n\nCVE-2026-46302 is a denial-of-service in SELinux\u0027s\n/sys/fs/selinux/policy file.\n\nThe bug: sel_open_policy() in security/selinux/selinuxfs.c enforced a\nsingle-open restriction via a policy_opened flag -- if the file was\nalready open, a second open() returned -EBUSY. Since the file is\nreadable by any process holding the read_policy permission, any such\nprocess could hold the file open indefinitely and block every other\nprocess from reading the kernel policy (breaking semodule, sesearch,\nlibsemanage read-back, etc.). The mutex was also held across the entire\nopen including the large policy-buffer allocation.\n\nThe fix (a02cd6805562) eliminates policy_opened, shrinks the\npolicy_mutex critical section so each open takes its own consistent\nsnapshot, and drops two extraneous BUG_ONs.\n\nRoot-cause commit: cee74f47a6baba0ac457e87687fdcf0abd599f0a -- \"SELinux:\nallow userspace to read policy back out of the kernel\" (Eric Paris,\n2010-10-13, first in v2.6.37-rc1).\n\nThis commit created the /selinux/policy file and, in the same patch,\nintroduced the policy_opened flag, the -EBUSY exclusivity, the oversized\nsel_mutex span, and both BUG_ONs -- the entire defect verbatim.\nConfirming evidence:\n\n- git log -S \"policy_opened\" -- security/selinux/selinuxfs.c returns\n exactly two commits: this introduction and the fix\u0027s removal. There is\n no prior code to trace through -- the file did not exist before this\n commit.\n\n- The fix\u0027s Link: points to\n lore...20100726193414...@paris.rdu.redhat.com, the July-2010 posting\n of this very patch series.\n\n- The ~15 years of intervening churn only renamed/relocated the same\n logic (sel_mutex-\u003epolicy_mutex, file-scope static char-\u003e\n per-superblock bool in struct selinux_fs_info,\n task_has_security-\u003eavc_has_perm,\n/selinux-\u003e/sys/fs/selinux) without ever altering the exclusivity\nsemantics.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "a286a8ee96fa68827a8e5fbe2c12c2ef1f53392a", "tree": "130bb26597a39e774c516fd6c17e26d667a7cfd9", "parents": [ "9606d59b08695f05095fee21c144b90c62204321" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:45:05 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:45:05 2026 -0400" }, "message": "CVE-2026-46294: Add .vulnerable file\n\nRoot-cause analysis for CVE-2026-46294.\n\nThe fix\n\nFix commit 2fa49cc884f6 (local twin 8daa6c708ef524), \"dm: fix a buffer\noverflow in ioctl processing\" by Mikulas Patocka, reported by Tony\nAsleson (using Claude). It adds four lines to retrieve_status() in\ndrivers/md/dm-ioctl.c:\n\n\t\toutptr \u003d align_ptr(outptr);\n+\t\tif (!outptr || outptr \u003e outbuf + len) {\n+\t\t\tparam-\u003eflags |\u003d DM_BUFFER_FULL_FLAG;\n+\t\t\tbreak;\n+\t\t}\n\t\tspec-\u003enext \u003d outptr - outbuf;\n\nThe bug mechanism\n\nretrieve_status() serializes each device-mapper target\u0027s status into a\nuser-supplied output buffer (outbuf, of size len). Per iteration it:\n\n1. Computes free space: remaining \u003d len - (outptr - outbuf); — and\n remaining is declared size_t, i.e. unsigned.\n2. Bounds-checks if (remaining \u003c\u003d sizeof(struct dm_target_spec))\n break;, writes the dm_target_spec header, advances outptr, then\n writes the status string.\n3. At the end of the iteration aligns the cursor to the next 8-byte\n boundary:\n outptr \u003d align_ptr(outptr); // (ptr + 7) \u0026 ~7\n\nThe defect: align_ptr() rounds outptr up by as much as 7 bytes with no\nbounds check. If the status string ended very close to outbuf + len, the\nrounding pushes outptr past the end of the buffer (outptr \u003e outbuf +\nlen).\n\nOn the next loop iteration, remaining \u003d len - (outptr - outbuf) is then\ncomputed where (outptr - outbuf) \u003e len. Because remaining is unsigned,\nthe subtraction wraps around to a huge value. The guard if (remaining \u003c\u003d\nsizeof(struct dm_target_spec)) is therefore false, the code believes it\nhas enormous space available, and proceeds to write the next target\u0027s\nheader and status string past the end of the buffer → heap buffer\noverflow.\n\nThe fix breaks out of the loop (with DM_BUFFER_FULL_FLAG) the moment\nalignment overshoots the buffer end, before the wrap-around can occur.\n\nAs the commit notes, severity is low: only root can issue DM ioctls,\nand the common userspace libraries (libdevmapper, devicemapper-rs) pass\n8-byte-aligned buffer sizes, so align_ptr() never actually overshoots\nin normal use.\n\nTracing the root cause\n\nEvery component of the bug was traced through origin/master:\n\n- git log -S \u0027align_ptr(outptr)\u0027 -- drivers/md/dm-ioctl.c → only\n 1da177e4c3f415\n- git log -S \u0027remaining \u003d len - (outptr - outbuf)\u0027 --\n drivers/md/dm-ioctl.c\n → only 1da177e4c3f415\n\nBoth critical lines resolve to a single commit. Reading the original\nretrieve_status() from 1da177e4c3f415:drivers/md/dm-ioctl.c confirmed\nthat all three ingredients of the vulnerability are present verbatim in\nthat first commit:\n\n1. size_t remaining — unsigned (so subtraction underflows);\n2. remaining \u003d len - (outptr - outbuf) — the wrap-prone arithmetic\n recomputed at loop top;\n3. outptr \u003d align_ptr(outptr) — the unchecked round-up at loop bottom,\n with align_ptr already defined as (ptr + 7) \u0026 ~7.\n\nRoot-cause commit\n\n1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 — \"Linux-2.6.12-rc2\"\n(Linus Torvalds, 2005-04-16).\n\nThis is the initial commit of the Git era. The device-mapper ioctl\ninterface (originally written by Joe Thornber / Alasdair Kergon, merged\ninto mainline around 2.6.9 in 2004) predates Git, so the code was\nactually authored before recorded history begins — 1da177e4c3f415 is the\nearliest identifiable commit in origin/master that contains the flawed\nretrieve_status(). The bug has therefore existed essentially since the\ndevice-mapper ioctl interface was created — roughly 21 years.\n\nWhy no later commit is the culprit\n\nThe function saw two decades of churn, but none of it touched the\nvulnerable logic:\n- strncpy → strscpy_pad (target_type copy) — cosmetic;\n- ti-\u003etype-\u003estatus() changed from int-returning (loop broke on nonzero)\n to void, adding the l \u003d\u003d remaining check — orthogonal path;\n- addition of DM_IMA_MEASUREMENT_FLAG / STATUSTYPE_IMA;\n- dm_table_get_num_targets() accessor → direct table-\u003enum_targets.\n\nThe align_ptr(outptr) round-up and the unsigned remaining \u003d len -\n(outptr - outbuf) recomputation were never modified between\n1da177e4c3f415 and the fix.\n\nThe nearby hardening commits b60528d9e68113 (\"Check dm_target_spec is\nsufficiently aligned\") and 13f4a697f8b4fe (\"Avoid pointer arithmetic\noverflow\") are not related — they harden the input-parsing path\n(next_target()/table population), a different code path from the\noutput-serialization overflow fixed here.\n\nConclusion: The root cause was introduced with the original\ndevice-mapper ioctl implementation, recorded in origin/master at commit\n1da177e4c3f415 (Linux 2.6.12-rc2).\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "9606d59b08695f05095fee21c144b90c62204321", "tree": "41292c3abe06948eea58df98fec76dd11a8d89c7", "parents": [ "e8bb2737d17bad6d24afec2fbd263950c25939bd" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:41:34 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:41:34 2026 -0400" }, "message": "CVE-2026-46286: Add .vulnerable file\n\nRoot cause commit: b00d2ed37617b5f2f091c98acf542fbedefcbf9b\n(\"leds: rgb: leds-qcom-lpg: Add support for high resolution PWM\",\nAnjelique Melendez, merged 2023-04-20, first in v6.4).\n\nThe bug: In lpg_pwm_get_state(), the high-resolution clock select is\nread from a 3-bit register field (PWM_CLK_SELECT_HI_RES_MASK \u003d\nGENMASK(2, 0), values 0-7) and used directly to index\nlpg_clk_rates_hi_res[], which has only 5 entries (valid indices 0-4).\nRegister encodings 5/6/7 cause an out-of-bounds array read; the garbage\nvalue becomes refclk and is fed into the period/duty-cycle computation\nand chip setup. The fix d45963a93c1495 adds\n\"if (clk_idx \u003e\u003d ARRAY_SIZE(lpg_clk_rates_hi_res)) return -EINVAL;\".\n\nWhy this is the root: The introducing commit b00d2ed37617b5 added, in\none shot, all three components of the defect - the GENMASK(2,0) mask,\nthe undersized 5-element lpg_clk_rates_hi_res[] table, and the unchecked\nindexing line (which the fix replaces verbatim). \"git log -S\nlpg_clk_rates_hi_res\" confirms only two commits ever touched the symbol\n(the fix and b00d2ed37617b5), with no intervening refactor or code\nmovement. Before this commit, no hi-res code existed; the only\nclock-rate lookup was the correctly-sized non-hi-res path\n(PWM_CLK_SELECT_MASK \u003d GENMASK(1,0) \u003c-\u003e 4-entry lpg_clk_rates[]). There\nis nothing earlier to trace to - the mismatch was born in\nb00d2ed37617b5.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "e8bb2737d17bad6d24afec2fbd263950c25939bd", "tree": "17a74940928a21263ae1bafeefd8d33346ab8f70", "parents": [ "642241f939e4ce105e0dcbd1f7f3aa483ccf1d1d" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:38:54 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:38:54 2026 -0400" }, "message": "CVE-2026-46276: Add .vulnerable file\n\nRoot-cause commit: c832c346cdf9022872655be621880e0f66f4135d\n(\"drm/amdgpu: initialize GDS/GWS/OA domains even when they are zero\nsized\", Christian König, 2018-09-14).\n\nThe fix (095a8b0ad3c3b5cdc3850d961adb8a8f735220bb, a cherry-pick of\nupstream 5719ce5865279cad4fd5f01011fe037168503f2d, tagged for stable) is\na three-line guard added to amdgpu_ttm_init_on_chip() in\ndrivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:\n\n\tstatic int amdgpu_ttm_init_on_chip(struct amdgpu_device *adev,\n\t\t\t\t\t unsigned int type,\n\t\t\t\t\t uint64_t size_in_page)\n\t{\n\t+\tif (!size_in_page)\n\t+\t\treturn 0;\n\t+\n\t\treturn ttm_range_man_init(\u0026adev-\u003emman.bdev, type,\n\t\t\t\t\t false, size_in_page);\n\t}\n\nThe crash chain:\n\n1. RDNA4 / GFX12 has no on-chip memory. GFX12 hardware physically\n removed the GDS, GWS, and OA scratch memories. gfx_v12_0.c reflects\n this by not touching adev-\u003egds at all -- a grep for gds in that file\n returns nothing -- so adev-\u003egds.gds_size, gws_size, and oa_size all\n remain 0 from the zero-initialized device struct.\n\n2. amdgpu_ttm_init() initializes those pools unconditionally. At\n amdgpu_ttm.c:2202/2208/2214:\n\n\tr \u003d amdgpu_ttm_init_on_chip(adev, AMDGPU_PL_GDS, adev-\u003egds.gds_size); // size \u003d 0\n\tr \u003d amdgpu_ttm_init_on_chip(adev, AMDGPU_PL_GWS, adev-\u003egds.gws_size); // size \u003d 0\n\tr \u003d amdgpu_ttm_init_on_chip(adev, AMDGPU_PL_OA, adev-\u003egds.oa_size); // size \u003d 0\n\n There is no if (size) check around these calls.\n\n3. Zero forwards into TTM and then DRM MM.\namdgpu_ttm_init_on_chip(..., 0) -\u003e ttm_range_man_init(...,\nsize_in_page\u003d0)\n -\u003e drm_mm_init(mm, 0, 0).\n\n4. The assertion fires. drm_mm_init() (drivers/gpu/drm/drm_mm.c) opens\n with:\n\n\tDRM_MM_BUG_ON(start + size \u003c\u003d start); // 0 + 0 \u003c\u003d 0 -\u003e true\n\nWith start \u003d size \u003d 0 this is trivially true, so the kernel oopses\nduring modprobe amdgpu on an RX 9070 XT. The assertion only compiles to\na real BUG() when CONFIG_DRM_DEBUG_MM is enabled, which is why the bug\nstayed hidden for over a year.\n\nTracing the root cause -- the fix re-introduces a \"skip when\nzero-sized\" guard. The history of that guard tells the whole story.\ngit log -L :amdgpu_ttm_init_on_chip plus git log -S on the GDS init\nblock surface these milestones:\n\n- d38ceaf99ed015 (2015, \"add core driver\") -- original code initialized\nGDS/GWS/OA pools unconditionally, but at that time no supported ASIC\nhad a zero-sized pool and DRM_MM_BUG_ON did not yet exist.\n\n- 6259a56ba0e1c3 (Chris Wilson, Dec 2016) -- \"drm: Add asserts to catch\n overflow in drm_mm_init()\" added DRM_MM_BUG_ON(start + size \u003c\u003d start).\nThis is the assertion that now fires, but it is a generic sanity check,\nnot the root cause.\n\n- d2d51d8192f1e4 (Alex Deucher, Mar 2017, \"don\u0027t init GDS pool if GDS\n size is 0 (v2)\") -- wrapped each pool init in if\n (adev-\u003egds.mem.total_size) / gws / oa. SI cards don\u0027t expose GDS as a\n separate pool, so this guard correctly prevented initializing a\n zero-sized manager. In this state the tree was not vulnerable.\n\n- c832c346cdf9022872655be621880e0f66f4135d (Christian König,\nSep 14 2018, \"drm/amdgpu: initialize GDS/GWS/OA domains even when they\nare zero sized\", \"Stops crashing on SI\") -- this is the root cause. It\ndeleted all three if (...total_size) guards (and the matching guards in\namdgpu_ttm_fini), making the manager init unconditional again:\n\n\t-\tif (adev-\u003egds.mem.total_size) {\n\t-\t\tr \u003d ttm_bo_init_mm(\u0026adev-\u003emman.bdev, AMDGPU_PL_GDS,\n\t-\t\t\t\t adev-\u003egds.mem.total_size);\n\t-\t\t...\n\t-\t}\n\t+\tr \u003d ttm_bo_init_mm(\u0026adev-\u003emman.bdev, AMDGPU_PL_GDS,\n\t+\t\t\t adev-\u003egds.mem.total_size);\n\t+\t...\n\nWhy c832c346 is the introducing commit:\n\n- The DRM_MM_BUG_ON (Dec 2016) already existed when c832c346 landed\n(Sep 2018) -- confirmed with git merge-base --is-ancestor. So removing\nthe guard immediately reopened the drm_mm_init(0,0) path; the BUG_ON\nitself is just a pre-existing tripwire.\n\n- Between d2d51d8192f1e4 (Mar 2017) and c832c346 (Sep 2018) the tree\n had the protective guard and was not vulnerable. c832c346 is therefore\n the regression point -- the commit that knowingly traded the guard for\n unconditional init (\"even when they are zero sized\"). Any tree\n containing c832c346 but not the fix is exposed; a tree with d2d51d and\n without c832c346 is not. This is exactly the bisection boundary a\n Fixes: tag should point at.\n\n- Every later refactor merely carried the unconditional behavior\n forward without ever re-adding a guard: 158d20d1857fe5 (init managers\n from the driver side -- created the amdgpu_ttm_init_on_chip wrapper,\n calls still unconditional), and 030c5b52d4c122 (size -\u003e size_in_page).\n They are noise; none reintroduced the check.\n\n- The fix (5719ce58/095a8b0a) re-adds essentially the same if (size)\n guard that c832c346 removed, just one level lower (inside\n amdgpu_ttm_init_on_chip rather than at the call sites).\n\nNote on which hardware exposed it -- the latent hazard has been\ntriggerable on any zero-sized pool since 2018: SI (the motivation for\nc832c346) and later Aldebaran / GFX 9.4.2 (gfx_v9_0.c:7771 sets gds_size\n\u003d 0 while gws_size/oa_size stay 64/16, so only the GDS call would hit\nthe BUG_ON). RDNA4 / GFX12 is simply the first ASIC where all three\nsizes are zero, so all three amdgpu_ttm_init_on_chip calls trip the\nassertion. The bug was only reported now because\nCONFIG_DRM_DEBUG_MM is rarely enabled in shipping kernels.\n\nConclusion: c832c346cdf9022872655be621880e0f66f4135d removed the if\n(adev-\u003egds.{mem,gws,oa}.total_size) guards that had been added by\nd2d51d8192f1e4, making the on-chip TTM range-manager initialization\nunconditional. Combined with the pre-existing\nDRM_MM_BUG_ON(start + size \u003c\u003d start) in drm_mm_init() (added by\n6259a56ba0e1c3), this opened the drm_mm_init(mm, 0, 0) crash path that\nRDNA4/GFX12 -- with all of GDS/GWS/OA sized at zero -- finally exercises\nin full.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "642241f939e4ce105e0dcbd1f7f3aa483ccf1d1d", "tree": "bdc17d62a0e0ef8783f8715d5958e206a10df8a6", "parents": [ "b80b66defdd73175479901549b6ce4ded93cd4aa" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:32:58 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:32:58 2026 -0400" }, "message": "CVE-2026-46250: Add .vulnerable file\n\nAdd the offending commit for CVE-2026-46250.\n\nRoot-cause analysis\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nThe fix commit\n--------------\n\n30bfc2d6a1132a89a5f1c3b96c59cf3e4d076ea3 (\"MIPS: Work around LLVM bug\nwhen gp is used as global register variable\") touches a single line in\narch/mips/kernel/relocate.c::relocate_kernel(). It wraps this\nassignment:\n\n\t/* The current thread is now within the relocated image */\n\t__current_thread_info \u003d RELOCATED(\u0026init_thread_union);\n\nin a #ifndef CONFIG_CC_IS_CLANG / #else block, replacing the plain C\nassignment under Clang with explicit inline assembly\n(asm volatile(\"move $28, %0\" ...)).\n\nWhat the bug actually is\n------------------------\n\nOn MIPS, __current_thread_info is not an ordinary variable -- it is a\nglobal register variable permanently bound to register $28/$gp\n(arch/mips/include/asm/thread_info.h:64):\n\n\tregister struct thread_info *__current_thread_info __asm__(\"$28\");\n\nrelocate_kernel() runs very early during boot when\nCONFIG_RELOCATABLE/KASLR copies and relocates the kernel image to a new\naddress. After the copy + relocation, the function reassigns $gp so that\nthe current thread pointer points into the relocated image:\n\n\t__current_thread_info \u003d RELOCATED(\u0026init_thread_union);\n\nPer GCC\u0027s documented contract for global register variables, a\ncallee-saved register (which $gp is) that has been deliberately\nclobbered through a global register variable must not be restored in the\nfunction epilog. GCC honors this. LLVM/Clang does not -- it sees $gp\nclobbered, decides it must preserve the ABI-callee-saved register, and\nemits epilog code that restores the original $gp when relocate_kernel()\nreturns.\n\nConsequence: as soon as relocate_kernel() returns, $gp once again\npoints at the unrelocated kernel\u0027s init_thread_union. The thread pointer\nis now stale/wrong, and the first code that dereferences thread-local\nstate through $gp crashes -- in the reported case a NULL-pointer paging\nfault in init_idle() -\u003e sched_init() -\u003e start_kernel().\n\nThis is fundamentally an LLVM compiler defect (reported as llvm-project\nissue #176546, affecting Clang 18-21). But the kernel-side root cause --\nthe code pattern that triggers it -- is the act of assigning the\n$gp-bound global register variable inside an ordinary, returning C\nfunction.\n\nTracing the root cause to its origin\n------------------------------------\n\nThe fix modifies exactly one line. Tracing that line\u0027s entire history\nwith git log -L:\n\n\tgit log -L \u0027/__current_thread_info \u003d RELOCATED/,+1:arch/mips/kernel/relocate.c\u0027\n\t-\u003e 279b991b24d243 MIPS: Kernel: Add relocate.c (only result)\n\nThe line __current_thread_info \u003d RELOCATED(\u0026init_thread_union); has\nexisted byte-for-byte unchanged since relocate.c was first created.\nThere was no later code movement, refactor, or relocation of this\nassignment -- git log --follow on the file and the -L line history both\nterminate at the same single commit.\n\nThat commit is:\n\nRoot cause: 279b991b24d2439fbe9d2f093988b9c8aed2603d\n---------------------------------------------------\n\n\"MIPS: Kernel: Add relocate.c\" -- Matt Redfearn, 2016-03-31, first\nreleased in v4.7-rc1.\n\nWhy this is the introducing commit\n----------------------------------\n\n279b991b24d243 created arch/mips/kernel/relocate.c and, in the\nbrand-new relocate_kernel() function, introduced the assignment of the\n$gp-bound global register variable __current_thread_info directly via a\nC statement (relocate.c:233 in that original version):\n\n\t/* The current thread is now within the relocated image */\n\t__current_thread_info \u003d RELOCATED(\u0026init_thread_union);\n\nEvery ingredient of the bug was present from this commit:\n\n1. The trigger statement -- a write to $gp through the\n__current_thread_info global register variable inside a normal C\nfunction that has a prolog/epilog. (The pre-existing register ...\n__asm__(\"$28\") declaration in thread_info.h is the long-standing MIPS\narchitectural design; the new code path that exercises it in a returning\nfunction is what 279b991b24d243 added.)\n2. The reliance on GCC\u0027s \"don\u0027t restore a clobbered global register\n variable\" guarantee -- the code is only correct because the compiler\n is expected to leave the new $gp value intact across the epilog.\n\nThe bug lay dormant for ~10 years because MIPS was historically built\nwith GCC, which honors the global-register-variable contract. It only\nbecame observable once the kernel was compiled with LLVM/Clang (which\ngained MIPS support and is now a first-class compiler), exposing LLVM\u0027s\nnon-conforming epilog behavior. The defect is therefore a latent\ncompiler-contract dependency baked into the original code, not something\na later refactor introduced.\n\nSummary\n-------\n\n- Defect class: stale $gp/thread pointer after relocate_kernel() returns\n-\u003e early-boot kernel paging fault (DoS / boot failure) on Clang-built\nrelocatable MIPS kernels.\n- Immediate cause: LLVM wrongly restores $gp in the function epilog\n despite the intentional global-register-variable clobber (llvm\n #176546).\n- Kernel root-cause commit (the line the fix patches, unchanged since\n creation): 279b991b24d2439fbe9d2f093988b9c8aed2603d -- \"MIPS: Kernel:\n Add relocate.c\" (v4.7-rc1, 2016), which first introduced\n__current_thread_info \u003d RELOCATED(\u0026init_thread_union); in\nrelocate_kernel().\n- Fix: 30bfc2d6a1132a -- emit explicit \"move $28, %0\" inline asm under\nClang (deliberately not listing $gp as output/clobber, so LLVM has no\nreason to restore it).\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "b80b66defdd73175479901549b6ce4ded93cd4aa", "tree": "611a05c6b0d39a17fd91a052fd33a4e0b5c63a64", "parents": [ "20f83b9bd35458d8bbdb06463ffe7fa89cd3b71e" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:29:41 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Mon Jun 08 12:29:41 2026 -0400" }, "message": "CVE-2025-71315: Add .vulnerable file\n\nRecord commit 3a0709928b172a4123a76078f70e0a706265690c (\"drm/vkms: Add\nvblank events simulated by hrtimers\") as the commit that introduced this\nvulnerability.\n\nWhat the fix commit actually fixes\n\nCommit 02e2681ffe1addde1fc8c35d05657b16bfa79613 (\"drm/vkms: Convert to\nDRM\u0027s vblank timer\") looks like a pure refactor -- it deletes vkms\u0027s\nhand-rolled vblank hrtimer and switches to the new generic\nDRM_CRTC_VBLANK_TIMER_FUNCS helper. But it is the third patch of a\nseries whose companion commit 74afeb8128502a (\"drm/vblank: Add vblank\ntimer\") states the real motive plainly:\n\n \"There\u0027s a possible deadlock between drm_crtc_handle_vblank() and\n hrtimer_cancel(). The implementation avoids to call hrtimer_cancel()\n directly and instead signals to the timer function to not restart\n itself.\"\n\nAnd the new helper\u0027s drm_crtc_vblank_cancel_timer() names the exact\nlocks involved:\n\n \"Calling hrtimer_cancel() can result in a deadlock with DRM\u0027s\n vblank_time_lock and hrtimers\u0027 softirq_expiry_lock. So clear interval\n and indicate cancellation. The timer function will cancel itself on\n the next invocation.\"\n\nSo the security bug is an ABBA deadlock (CWE-833 / deadlock -\u003e DoS, the\nmachine hangs). The conversion fixes it by never calling\nhrtimer_cancel() synchronously while a DRM vblank lock is held.\n\nThe exact lock cycle\n\nvkms drove its fake vblank with a self-rearming hrtimer. Two code paths\nform the cycle:\n\nHalf A -- the timer callback acquires vblank_time_lock:\nThe hrtimer callback vkms_vblank_simulate() calls\ndrm_crtc_handle_vblank(crtc) -\u003e drm_handle_vblank(), which takes\ndev-\u003eevent_lock and then dev-\u003evblank_time_lock\n(drivers/gpu/drm/drm_vblank.c:1936). The callback runs in\nhrtimer/softirq context, during which the hrtimer core holds the per-CPU\nsoftirq_expiry_lock (the lock hrtimer_cancel() waits on to know the\ncallback has finished).\n\nHalf B -- the disable path holds vblank_time_lock and calls\nhrtimer_cancel():\nWhen DRM tears down vblank, drm_vblank_disable_and_save() grabs\ndev-\u003evblank_time_lock (spin_lock_irqsave, drm_vblank.c:472) and, still\nholding it, calls __disable_vblank() -\u003e\ncrtc-\u003efuncs-\u003edisable_vblank(crtc)\n-\u003e vkms_disable_vblank() -\u003e hrtimer_cancel(\u0026out-\u003evblank_hrtimer).\nhrtimer_cancel() blocks until the running callback completes (on\nPREEMPT_RT via softirq_expiry_lock; on mainline via busy-wait on the\nstill-running timer).\n\nPut together:\n\n CPU0 (vblank disable) CPU1 (hrtimer softirq)\n holds vblank_time_lock running vkms_vblank_simulate\n hrtimer_cancel() drm_crtc_handle_vblank()\n wait for callback to finish wants vblank_time_lock\n (softirq_expiry_lock / (held by CPU0)\n busy-wait) callback can\u0027t finish\n\nCPU0 waits for the callback to finish; the callback can\u0027t finish\nbecause it\u0027s blocked on vblank_time_lock, which CPU0 holds. Classic\ndeadlock.\nIt\u0027s reachable from userspace simply by enabling vblank (a compositor /\nDRM client) and then triggering a modeset/vblank-disable -- a virtual\ndriver available in any kernel with CONFIG_DRM_VKMS.\n\nTracing back to the commit that introduced the root cause\n\nFollowing the history of drivers/gpu/drm/vkms/vkms_crtc.c back through\nevery refactor:\n\n- c38e753abee274 -- hrtimer_init -\u003e hrtimer_setup (cosmetic; same\n callback, same cancel).\n- a0e6a017ab5693 + revert 7908632f2927b6 -- the enabled_lock mutex.\n This was a different bug (a mutex_unlock() from the hrtimer callback,\n illegal in atomic context) and was reverted; it has nothing to do with\n this deadlock.\n- The spin_lock(\u0026output-\u003elock) later wrapped around\n drm_crtc_handle_vblank() is vkms\u0027s own lock -- not part of the\n deadlock, which runs through DRM\u0027s internal vblank_time_lock.\n\nBefore all of that, the hrtimer machinery did not exist. The\nimmediately preceding commit on the file (854502fa0a38dc, \"drm/vkms: Add\nbasic CRTC initialization\") had no timer at all.\n\nThe root cause is commit 3a0709928b172a4123a76078f70e0a706265690c\n(\"drm/vkms: Add vblank events simulated by hrtimers\", Rodrigo Siqueira,\nlanded v4.19-rc1, July 2018).\n\nThat single commit introduced both halves of the deadlock at once:\n\n1. vkms_vblank_simulate() -- the self-rearming hrtimer callback that\n calls drm_crtc_handle_vblank(crtc) (which takes vblank_time_lock).\n2. vkms_disable_vblank() -- calls hrtimer_cancel(\u0026out-\u003evblank_hrtimer),\n and is registered as .disable_vblank in vkms_crtc_funcs, so DRM core\n invokes it from drm_vblank_disable_and_save() while holding\n vblank_time_lock.\n\nThe flawed design -- a vblank-generating hrtimer whose callback grabs\nthe very lock that the synchronous hrtimer_cancel() teardown path holds\n-- has been present unchanged from 4.19 all the way to the fix.\n3a0709928b17 is an ancestor of the fix commit and no earlier vkms\ncommit contained any hrtimer code.\n\nA note on the \"made it more obvious\" caveat: the PREEMPT_RT\nsoftirq_expiry_lock synchronization inside hrtimer_cancel() (added years\nlater) is what makes lockdep flag this cleanly, but it is not the root\ncause -- even on a non-RT kernel, hrtimer_cancel() busy-waits for a\ncallback that can never complete, so the deadlock was latent from day\none. The originating commit remains 3a0709928b17.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "20f83b9bd35458d8bbdb06463ffe7fa89cd3b71e", "tree": "6220a8ecbb788fdadd2a3029bbfe4f0f78ae777b", "parents": [ "fec91c3282cb0f4861534c0890533904e24cde23" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:51:14 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:51:14 2026 +0200" }, "message": "strip the new mbox files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "fec91c3282cb0f4861534c0890533904e24cde23", "tree": "c703f0f017f4c97be4b0503b0aeff609fef686a6", "parents": [ "b44cb1bc70833add953892406e876e49bfc0510b" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:50:00 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:50:00 2026 +0200" }, "message": "assign some more 7.0.9 cve ids\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "b44cb1bc70833add953892406e876e49bfc0510b", "tree": "2492b16d842209908a62145d165b410453d2a32e", "parents": [ "3e2a9b33c5afaa410784c9e32112b89b20ca884f" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:46:07 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:46:07 2026 +0200" }, "message": "assign some more 7.0.7 cve ids\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "3e2a9b33c5afaa410784c9e32112b89b20ca884f", "tree": "1f4dbb2c014562daf1c094cc96e3878035c4bc6c", "parents": [ "96c470ab2bb5ea9f61c8d879ba2f27b67aafc6e2" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:40:52 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 17:40:52 2026 +0200" }, "message": "assign some more 7.0.4 cve ids\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "96c470ab2bb5ea9f61c8d879ba2f27b67aafc6e2", "tree": "0dc37fe1e3d2ea670fec7916c1a5791e3dc12717", "parents": [ "225417a653651491145c3c4a3adcd7fc0416a677" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 16:38:06 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 16:38:06 2026 +0200" }, "message": "strip the new mbox files\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "225417a653651491145c3c4a3adcd7fc0416a677", "tree": "cd4c6b29aa6b1494004978667b6e9ab19b8178a8", "parents": [ "06f74ac0874786641623a1d8b48a744daf8576cb" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 16:30:10 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Mon Jun 08 16:30:10 2026 +0200" }, "message": "assign some cve ids on request.\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "06f74ac0874786641623a1d8b48a744daf8576cb", "tree": "bdf96f677709e247eab22aee68ce2c1879136aee", "parents": [ "90ddf2452d5e6a3d8e0370e7b869cee913ff1295" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 07 09:10:37 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 07 09:10:37 2026 +0200" }, "message": "update after new reference\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "90ddf2452d5e6a3d8e0370e7b869cee913ff1295", "tree": "b78b5bd2208034c5e9d2382726a378e64c34c150", "parents": [ "6e565978630569b90e174ec32129ab70a40995fb" ], "author": { "name": "Salvatore Bonaccorso", "email": "carnil@debian.org", "time": "Sat Jun 06 15:19:35 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Sun Jun 07 09:09:55 2026 +0200" }, "message": "CVE-2026-43073: Provide Google p0 cross-reference\n\nLink: https://project-zero.issues.chromium.org/issues/496923375\nSigned-off-by: Salvatore Bonaccorso \u003ccarnil@debian.org\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "6e565978630569b90e174ec32129ab70a40995fb", "tree": "58825da33bd3ba0036b10696550caaf24911b34b", "parents": [ "59103b6e19f2e68b97016e5979754dff78456f1d" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 05 08:10:02 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 05 08:10:02 2026 +0200" }, "message": "update based on new cvss scores\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "59103b6e19f2e68b97016e5979754dff78456f1d", "tree": "be0a1a95c86efa4061c267b3db6d83b44acf3da3", "parents": [ "1cadb0a2f5d8c54d998518fd8f57d87e4c9dce45", "17085f4d980f29c017d2f2e0dcdb884043588a65" ], "author": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 05 08:04:47 2026 +0200" }, "committer": { "name": "Greg Kroah-Hartman", "email": "gregkh@linuxfoundation.org", "time": "Fri Jun 05 08:04:47 2026 +0200" }, "message": "Merge branch \u0027sasha-cvss-important\u0027\n\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\n" }, { "commit": "1cadb0a2f5d8c54d998518fd8f57d87e4c9dce45", "tree": "323e31b62e5ab4ee6f84c60ef8065e3a6ab36e71", "parents": [ "6f0714bb9248d2973fd197f3fd8aa9ca2ecc4fa6" ], "author": { "name": "Lee Jones", "email": "lee@kernel.org", "time": "Thu Jun 04 16:02:16 2026 +0100" }, "committer": { "name": "Lee Jones", "email": "lee@kernel.org", "time": "Thu Jun 04 16:02:45 2026 +0100" }, "message": "proposed: Add Lee\u0027s v7.0.9 results\n\nSigned-off-by: Lee Jones \u003clee@kernel.org\u003e\n" }, { "commit": "6f0714bb9248d2973fd197f3fd8aa9ca2ecc4fa6", "tree": "596ecfceeb0b364b6e35aec37cc98f710c25831f", "parents": [ "23696e4e73127df1ce102f2e7e6d378c2dbcbac1" ], "author": { "name": "Lee Jones", "email": "lee@kernel.org", "time": "Thu Jun 04 16:02:08 2026 +0100" }, "committer": { "name": "Lee Jones", "email": "lee@kernel.org", "time": "Thu Jun 04 16:02:45 2026 +0100" }, "message": "proposed: Add Lee\u0027s v7.0.7 results\n\nSigned-off-by: Lee Jones \u003clee@kernel.org\u003e\n" }, { "commit": "23696e4e73127df1ce102f2e7e6d378c2dbcbac1", "tree": "be00a8ee1f72ff2a9bad17acfef88798120485fd", "parents": [ "01e6262d8ad30279f316286a2ec521e210cf196d" ], "author": { "name": "Lee Jones", "email": "lee@kernel.org", "time": "Thu Jun 04 16:01:59 2026 +0100" }, "committer": { "name": "Lee Jones", "email": "lee@kernel.org", "time": "Thu Jun 04 16:02:45 2026 +0100" }, "message": "proposed: Add Lee\u0027s v7.0.4 results\n\nSigned-off-by: Lee Jones \u003clee@kernel.org\u003e\n" }, { "commit": "17085f4d980f29c017d2f2e0dcdb884043588a65", "tree": "48a20fb26d922238ec24309fd6406f2f831853ac", "parents": [ "29b651a0a3095e5194dca86af752a076e3dba1b4" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:26:14 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:30 2026 -0400" }, "message": "CVE-2026-46244: Add CVSS 3.1 score (9.1 CRITICAL)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\n\nAV:N -Exploitation is triggered when a remote attacker sends\n crafted tunneled packets (GRE/Geneve/VXLAN/UDP/TCP) that are\n evaluated on netfilter ingress/forward hooks, not via netlink rule\n installation.\nAC:L -The attacker fully controls packet layout including inner\n IPv6 extension headers and can reliably desynchronize inner_thoff\n from the real transport header without races or rare layout\n conditions.\nPR:N -The attacker needs no privileges on the victim; only\n pre-existing nftables rules using the inner expression must be\n present, which is victim infrastructure rather than attacker\n privilege.\nUI:N -No victim user action is required beyond normal network\n traffic processing once vulnerable firewall rules exist.\nS:U -Impact is bypass of host netfilter policy within the kernel\n network security boundary, not VM escape, container breakout, or\n crossing a separate hardware/IOMMU authority.\nC:H -Bypassing inner-header filtering can expose confidential\n services and data on protected internal networks that the firewall\n was meant to block from the attacker’s network position.\nI:H -The desync allows forged inner transport matches so traffic\n can be misclassified, defeating integrity of nftables filtering\n decisions and permitting unauthorized flows.\nA:N -The bug misdirects skb_copy_bits reads within\n attacker-supplied packet data and yields NFT_BREAK on failure; it\n does not corrupt kernel memory or cause panics/oops.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "29b651a0a3095e5194dca86af752a076e3dba1b4", "tree": "c176d5a231c66817b8ea31be8023fb12e6b798c7", "parents": [ "9f28e7ca49fc126d6a6d9193ea256ac9a0ff0452" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:23:37 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:30 2026 -0400" }, "message": "CVE-2026-46250: Add CVSS 3.1 score (7.3 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H\n\nAV:L -The vulnerable code runs only during early boot in\n `relocate_kernel()` (`arch/mips/kernel/head.S` →\n `arch/mips/kernel/relocate.c`), before any network stack or syscall\n interface exists; the only way to reach it is to boot or reboot the\n MIPS system locally.\nAC:L -When the kernel is built with LLVM/Clang,\n `CONFIG_RELOCATABLE`, and KASLR relocation (`offset !\u003d 0`), LLVM\n deterministically restores `$gp` in the `relocate_kernel()` epilog,\n causing a reliable crash in `init_idle()` on every affected boot\n without races or attacker-uncontrollable timing.\nPR:N -Execution occurs in the pre-authentication boot path (PID 0\n swapper during `start_kernel()` → `sched_init()` → `init_idle()`),\n before any user login or privilege checks; no attacker credentials\n are required at the time the bug triggers.\nUI:N -No victim user action is required beyond normal system\n power-on or reboot; the fault occurs automatically during kernel\n initialization on affected builds.\nS:U -Impact is confined to kernel boot failure on the same machine;\n there is no crossing of security boundaries such as VM escape,\n sandbox escape, or IOMMU bypass.\nC:L -The stale `$gp`/`__current_thread_info` causes `current` to\n resolve from the unrelocated `init_thread_union`, leading to\n dereferences of invalid kernel memory and limited kernel-address\n information exposure in the oops before the paging fault at address\n 0.\nI:L -Before the fatal fault, `init_idle()` performs writes through\n the mis-resolved `current` pointer (e.g., task state and scheduler\n fields), enabling limited unintended modification of kernel\n structures even though the immediate outcome is a crash rather than\n controlled code execution.\nA:H -The bug produces a kernel oops during early boot in\n `init_idle()` with \"Unable to handle kernel paging request at\n virtual address 0000000000000000\", preventing the system from\n completing initialization and rendering it unavailable.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "9f28e7ca49fc126d6a6d9193ea256ac9a0ff0452", "tree": "15fba11d4b5973c03b682738dfdbf7e2d974f3b1", "parents": [ "886a6e86eb4408d0ecbc3e9586db73b2f2a67510" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:23:26 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:30 2026 -0400" }, "message": "CVE-2026-46251: Add CVSS 3.1 score (8.4 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The flaw is in btrfs transaction commit\n (`btrfs_commit_transaction` → `switch_commit_roots`), reached only\n through local VFS/syscall paths (writes, `fsync`,\n `sync`/`btrfs_sync_fs`), not through a network protocol handler.\nAC:L -On a filesystem with `EXTENT_TREE_V2`, any transaction that\n allocates and dirties the block-group root followed by a commit\n reliably hits the invalid second `list_add_tail`; the attacker\n controls writes and when commit runs without races or\n victim-specific timing.\nPR:N -Exploitation needs only normal local access to perform\n allocating writes and trigger commit (e.g. `write`/`fallocate` plus\n `sync`/`fsync`); no root, `CAP_SYS_ADMIN`, or other elevated\n capability is required on an already-mounted affected btrfs volume.\nUI:N -No victim interaction is required beyond the attacker (or any\n concurrent writer) performing filesystem I/O that dirties metadata\n and causes a transaction commit.\nS:U -Impact stays within the kernel/filesystem security domain\n (metadata corruption, possible further kernel list misuse); it does\n not cross a VM, container, or IOMMU boundary.\nC:H -The bug corrupts kernel `struct list_head` linkage in\n `switch_commits`/`dirty_cowonly_roots`; such heap/list corruption\n can be turned into arbitrary kernel reads even though the primary\n symptom is filesystem failure.\nI:H -List corruption can mis-route commit processing and, as\n demonstrated, leads to btrfs transaction abort, “filesystem\n corrupted” errors, and forced read-only state—arbitrary integrity\n loss on the affected volume.\nA:H -Successful trigger forces the btrfs filesystem into a\n corrupted, read-only state and can emit kernel warnings during\n `list_del`, denying normal read/write availability for all users of\n that filesystem.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "886a6e86eb4408d0ecbc3e9586db73b2f2a67510", "tree": "236074e7bcc3444afd85f06828ab92afd65a80aa", "parents": [ "791da7f19997b2e4716902e9dad596f5cfb931a8" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:21:52 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:30 2026 -0400" }, "message": "CVE-2026-46259: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -Exploitation requires local `open()`/`read()` on procfs\n (`/proc/[pid]/stat` or thread `stat`); there is no network,\n adjacent-radio, or physical-device path to `do_task_stat()`.\nAC:L -An attacker can reliably race by running concurrent `read()`\n loops on `/proc/child/stat` while another thread exits and reaps\n the parent via `wait4()`, controlling both sides of the\n `release_task()`/`call_rcu()` window.\nPR:L -Triggering the bug needs only an unprivileged local account\n that can read procfs (default `hidepid\u003doff` allows reading other\n users’ `stat`); no real root or init-namespace-only capability is\n required.\nUI:N -Exploitation is fully attacker-driven through syscalls and\n process lifecycle control; no victim user action (clicks, mounts,\n etc.) is needed.\nS:U -Impact is confined to kernel memory corruption and privilege\n escalation within the same kernel security domain, not a\n cross-boundary escape such as VM guest-to-host.\nC:H -The UAF dereferences freed `task_struct` memory via\n `task_pid_ptr()`/`__task_pid_nr_ns()`, enabling disclosure of stale\n slab contents and kernel pointers that can be groomed into an\n arbitrary-read primitive.\nI:H -Use-after-free on a `task_struct` slab object can be leveraged\n with heap grooming for control of freed memory and potential\n arbitrary write or code execution, not merely a bounded or cosmetic\n change.\nA:H -Concurrent UAF access to a freed parent `task_struct` can\n cause kernel oops/panic (KASAN reports slab-use-after-free class\n failures) even when full exploitation is not attempted.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "791da7f19997b2e4716902e9dad596f5cfb931a8", "tree": "67ff02112cae0d016e98d972226b665c7c24e395", "parents": [ "a305744f84f11d5a67aedc5165702fb7b7ad9916" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:21:50 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:30 2026 -0400" }, "message": "CVE-2026-46253: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The overflow is reached only from in-kernel pstore/ramoops\n paths (boot init, kmsg-dump oops handling, pstore timer workqueue,\n or pstore filesystem rescan via mount), not from any network,\n adjacent-radio, or physical-device interface.\nAC:L -Once ramoops is present (common on Android, ChromeOS, and\n embedded targets), a local actor who can trigger a survivable oops\n and influence kmsg volume can drive the size mismatch; the second\n `persistent_ram_save_old()` call is then triggered\n deterministically by the pstore update timer or a pstore\n remount/rescan without depending on uncontrollable memory layout or\n victim timing.\nPR:L -Exploitation does not require real init-namespace root: an\n unprivileged local user (or sandboxed code with a kernel bug\n primitive) can provoke the non-fatal oops that enlarges the\n persistent RAM record, while the actual overflow fires later in\n kernel context during automatic pstore rescan or when crash-log\n collection runs.\nUI:N -No end-user or administrator action is required on the\n timer-driven path (`pstore_update_ms` enabled): after the oops is\n logged, the kernel timer/workqueue automatically rescans records\n and invokes the vulnerable copy without further interaction.\nS:U -The bug corrupts kernel heap memory inside the same kernel\n security domain; it does not by itself cross a VM, container, or\n IOMMU boundary to affect a separate authority.\nC:H -The flaw performs an out-of-bounds heap write via\n `memcpy_fromio()` and then exposes an out-of-bounds read through\n the inflated `old_log_size` in `ramoops_pstore_read()`, giving\n memory-corruption primitives that can disclose adjacent kernel heap\n contents.\nI:H -The out-of-bounds write into a `kvzalloc()`-allocated shadow\n buffer is classic kernel heap corruption that can be leveraged for\n arbitrary memory modification and potential control-flow hijack,\n not merely a bounded data alteration.\nA:H -The overflow is detected as a slab out-of-bounds condition\n (KASAN splat) and can panic or oops the kernel during the copy or\n subsequent read, causing complete loss of availability on affected\n systems.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "a305744f84f11d5a67aedc5165702fb7b7ad9916", "tree": "1e42ad92e0c089da584bd1f6f79eab46aba73b59", "parents": [ "9c672269bc10a1790d8229a82374b52aa5e62191" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:19:03 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:29 2026 -0400" }, "message": "CVE-2026-46260: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The bug is reached only via RTNETLINK (`inet6_rtm_newroute` →\n `ip6_route_add` → `fib6_add_rt2node`) through a local `sendmsg` on\n a netlink socket, not from processing remote IPv6 packets.\nAC:L -syzbot reproduced this reliably with crafted `RTM_NEWROUTE`\n messages; an attacker can create the required `RTA_NH_ID` routes\n and duplicate-nexthop state in their own network namespace without\n depending on victim timing or layout.\nPR:L -`rtnetlink_rcv_msg()` requires `CAP_NET_ADMIN` for\n `RTM_NEWROUTE`, which unprivileged users can hold inside a\n user+network namespace (`unshare -Urn`), not only real\n init-namespace root.\nUI:N -Exploitation is fully attacker-driven through netlink route\n configuration and does not require any action by another user or\n administrator.\nS:U -Impact stays within the kernel/network namespace of the\n attacker; it does not cross a VM, container runtime, or hardware\n security boundary on its own.\nC:H -The flaw is a slab out-of-bounds read of `fib_nh_gw_family`\n past the end of a `fib6_info` allocated without the trailing\n `fib6_nh`, exposing adjacent heap/redzone bytes that can include\n kernel pointers.\nI:H -The out-of-bounds byte read controls whether\n `RTF_ADDRCONF`/`RTF_PREFIX_RT` are cleared on an existing route,\n enabling attacker-influenced routing-table corruption and the same\n `fib6_add_rt2node()` family of integrity failures seen in related\n ECMP bugs.\nA:H -The bug triggers a KASAN slab-out-of-bounds fault and can\n corrupt IPv6 FIB state in ways that lead to further kernel failures\n (including `BUG_ON` in this function on related misconfigured ECMP\n paths).\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "9c672269bc10a1790d8229a82374b52aa5e62191", "tree": "d00b843df500559224e44c39ad54f9e4d8b04a48", "parents": [ "b8796254fdf43fdc539eb42b24860b6a473b8a6c" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:17:53 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:29 2026 -0400" }, "message": "CVE-2026-46263: Add CVSS 3.1 score (7.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -The flaw is in AMDGPU display core initialization\n (dc_create/resource_construct during GPU probe), reachable only\n from the local kernel context, not from the network or physical\n buses.\nAC:L -When an out-of-range eng_id is passed, the out-of-bounds\n index is deterministic with no race; the off-by-one check reliably\n allows ENGINE_ID_DIGF (5) past validation.\nPR:L -Exploitation requires local access on a system with a\n vulnerable AMD DCN3.x GPU driver loaded; typical desktop/cloud-GPU\n tenants have local DRM access without real root, though module\n reload generally needs elevated privileges.\nUI:N -No victim interaction is required; the bug fires during\n driver/display-core initialization, not from opening a file or\n approving a prompt.\nS:U -Impact stays within kernel/GPU driver context (wrong MMIO\n register maps, memory corruption); it does not cross a\n VM/hypervisor or IOMMU security boundary by itself.\nC:H -Out-of-bounds indexing of stream_enc_regs[] reads adjacent\n kernel memory into encoder register descriptors, which is an\n unbounded kernel memory disclosure primitive per kernel CVSS\n guidance.\nI:H -The corrupted register block pointer is used for subsequent\n GPU MMIO writes through stream-encoder helpers, enabling\n misdirected hardware register modification and potential control of\n display hardware state.\nA:H -Invalid register mappings and out-of-bounds kernel reads can\n cause kernel oops/panic or GPU hang when display paths are\n exercised, matching kernel guidance for crash-class availability\n impact.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "b8796254fdf43fdc539eb42b24860b6a473b8a6c", "tree": "4415b8de10fade5fddba75b315ae6a86d7177977", "parents": [ "23b4abc2b81139639bb61e1afb5f238895a277a1" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:17:18 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:29 2026 -0400" }, "message": "CVE-2026-46264: Add CVSS 3.1 score (8.8 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H\n\nAV:L -The bug is reached only from the local PCI/driver probe path\n (xe_pci_probe → xe_device_probe → xe_sriov_pf_sysfs_init), not from\n any network protocol handler.\nAC:L -Triggering devm_add_action_or_reset failure is primarily\n ENOMEM from devres allocation, which an attacker can influence with\n sustained memory pressure; no rare layout or victim-state race is\n required beyond that.\nPR:L -No capability beyond a local login is needed to pressure the\n kernel into ENOMEM during probe on shared hosts; reaching the\n SR-IOV PF sysfs init path does not require init-namespace root if\n the Xe PF is already probing (boot, hotplug, or admin rebind).\nUI:N -Exploitation does not depend on a victim opening files or\n clicking anything; it occurs during automatic driver probe when the\n failure path runs.\nS:C -The flaw runs in the SR-IOV PF host driver that administers VF\n isolation; host kernel memory corruption during PF sysfs setup can\n break the virtualization boundary and impact tenant VFs on\n cloud/datacenter GPU hosts.\nC:H -Calling kobject_put() on an uninitialized kobject drives\n refcount underflow on uninitialized kref state, which the fix\n commit and kernel warnings classify as use-after-free with\n potential for arbitrary read primitives.\nI:H -The same uninitialized kobject_put()/refcount corruption can\n corrupt kernel heap metadata and be developed into arbitrary write\n or code execution, consistent with UAF-class impact.\nA:H -The observed failure mode includes kernel WARN/oops on\n kobject_put, refcount underflow warnings, and probe/setup failure\n that can deny GPU/SR-IOV availability on the host.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "23b4abc2b81139639bb61e1afb5f238895a277a1", "tree": "81682705c6ad2d6e777b9e2b4759c946a0df1a00", "parents": [ "caa9dc6f3df2bb11e51d3c11e94ba20764215d15" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:17:01 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:29 2026 -0400" }, "message": "CVE-2026-46265: Add CVSS 3.1 score (7.5 HIGH)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n\nAV:N -The bug is reached when an RPC-over-RDMA path tears down a\n HiSilicon HNS queue pair; remote NFS/RDMA peers can force\n disconnect/reconnect and QP destruction on internet- or\n fabric-facing storage nodes (svc_rdma / rpcrdma), which is\n network-driven rather than purely local ioctl access.\nAC:L -Once NFS-over-RDMA and HNS RoCE are enabled, a remote peer\n can repeatedly trigger disconnect and failed reconnect work;\n combined with routine memory-reclaim pressure (PF_MEMALLOC on the\n NFS swap path) or NIC reset, the WARN/deadlock path is\n attacker-influenceable without rare one-off victim state.\nPR:N -On an NFS-over-RDMA server the vulnerable\n ib_destroy_qp/flush_work path runs while handling RDMA CM\n disconnects from network clients, before any per-file NFS\n authorization; no local UNIX privileges on the victim are required\n beyond the service already being exposed.\nUI:N -Exploitation requires only network traffic and kernel-side\n RPC/RDMA handling; no end-user actions such as mounting a\n filesystem or clicking a link are needed on the victim.\nS:U -Impact is confined to kernel workqueue forward-progress and\n availability on the host running the HNS driver; it does not cross\n VM, container, or IOMMU security boundaries.\nC:N -The flaw is a missing WQ_MEM_RECLAIM flag leading to\n check_flush_dependency WARN_ONCE and possible reclaim deadlock;\n there is no memory corruption, out-of-bounds access, or\n use-after-free that could yield information disclosure.\nI:N -No attacker-controlled writes, type confusion, or\n code-execution primitive exist; the failure mode is a workqueue\n dependency violation during QP flush/destroy, not integrity\n compromise of data or code.\nA:H -Violating the workqueue forward-progress rule can deadlock\n memory reclaim, and the observed WARN_ONCE becomes a kernel panic\n when panic_on_warn is enabled; even without panic, a stuck reclaim\n path is a full host availability failure.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "caa9dc6f3df2bb11e51d3c11e94ba20764215d15", "tree": "d5a009df9fc791e0c84ad29b8ed7c369156b52cf", "parents": [ "0f6a28ba95caf60ffa0ee6dacdca646ce6bc48ff" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:16:37 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:29 2026 -0400" }, "message": "CVE-2026-46266: Add CVSS 3.1 score (9.1 CRITICAL)\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H\n\nAV:N -The bug is reached when a remotely sourced ICMP error\n (DEST_UNREACH/FRAG_NEEDED or REDIRECT) is received and processed\n through icmp_rcv() → icmp_unreach()/icmp_redirect() →\n icmp_socket_deliver(), which is standard internet-facing IPv4 input\n on any host accepting ICMP.\nAC:L -Exploitation is a single, deterministic crafted ICMP packet\n (inner IP proto\u003d255, attacker-chosen daddr/PMTU) matching an open\n IPPROTO_RAW socket; an attacker can reliably create that socket via\n CAP_NET_RAW in a user+network namespace (unshare -Urn) without\n winning a race.\nPR:N -The network trigger requires no authentication or victim\n credentials—only delivery of forged ICMP to the target IP; the\n remote attacker does not need local privileges even though a local\n IPPROTO_RAW socket must exist on the victim (typically opened by a\n daemon or a co-resident userns holder).\nUI:N -No victim user action is required beyond normal network\n operation; the attacker sends ICMP directly to the host without\n tricking anyone into clicking, mounting, or opening files.\nS:U -Impact is confined to the kernel IPv4 routing/FNHE cache\n within the same network namespace; it does not cross a\n VM/hypervisor or IOMMU security boundary.\nC:N -This is a missing validation/logic bug that poisons\n route-cache metadata (PMTU/gateway); there is no memory read,\n pointer leak, or information-disclosure primitive.\nI:H -Before the fix, raw_err() unconditionally calls\n ipv4_sk_update_pmtu()/ipv4_sk_redirect(), letting a remote attacker\n inject attacker-controlled PMTU and gateway values into the\n system-wide FNHE exception cache for arbitrary destination\n addresses, altering forwarding for all local traffic to those\n destinations.\nA:H -Repeated forged ICMP FRAG_NEEDED packets can persistently\n force minimum PMTU entries in FNHE for chosen destinations, causing\n severe throughput collapse and connectivity failure for affected\n flows across the entire host or shared network namespace.\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" }, { "commit": "0f6a28ba95caf60ffa0ee6dacdca646ce6bc48ff", "tree": "13cfa79d3c6e3b157894272e52cb266492921af8", "parents": [ "bff814b876af00b8790d77426f0337b32d427286" ], "author": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:15:08 2026 -0400" }, "committer": { "name": "Sasha Levin", "email": "sashal@kernel.org", "time": "Thu Jun 04 07:34:29 2026 -0400" }, "message": "CVE-2026-46270: Add CVSS 3.1 score (8.4 HIGH)\n\nCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\n\nAV:L -Exploitation requires local driver teardown (module unload,\n sysfs unbind, or shutdown/reboot) that runs `devres_release_all()`;\n the vulnerable `power_supply_changed()` path is only reachable from\n the on-chip IRQ handler during that window, not from any\n network-facing protocol.\nAC:L -An attacker who can initiate driver removal can repeatedly\n assert charger interrupts (USB plug/unplug, charge events) to hit\n the narrow race between `power_supply_unregister()` and IRQ\n release; this is a standard attacker-controlled UAF race, not a\n layout-dependent condition.\nPR:N -On battery-powered embedded/mobile platforms with this IC, an\n attacker with brief physical possession can force power-off/reboot\n (no Linux account or capability) while manipulating the charging\n port to fire IRQs during devm teardown; explicit unbind/rmmod also\n works but is not the only path.\nUI:N -No victim interaction is required beyond the attacker’s own\n physical control of the device and charging port; exploitation does\n not depend on the victim opening files, mounting filesystems, or\n approving prompts.\nS:U -Impact is confined to kernel memory corruption and privilege\n escalation within the kernel security boundary; it does not cross\n VM, container, or IOMMU isolation boundaries.\nC:H -The IRQ handler calls `power_supply_changed()` on a freed\n `struct power_supply`, performing spinlock operations and\n `schedule_work()` on freed heap memory, which is a classic UAF that\n can be turned into arbitrary kernel memory disclosure.\nI:H -The same UAF writes to freed object fields (`changed`, locks,\n workqueue) and can be combined with heap grooming for arbitrary\n kernel writes or control-flow hijack, as noted by the fix author\n (“silently corrupts the memory”).\nA:H -Use-after-free in interrupt context typically causes immediate\n kernel oops/panic or silent memory corruption; the commit\n explicitly states this “usually crashes the system.”\n\nSigned-off-by: Sasha Levin \u003csashal@kernel.org\u003e\n" } ], "next": "bff814b876af00b8790d77426f0337b32d427286" }