HIGH8.8
Уязвимость компонента xfrm ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
ALT-PU-2026-8289-23Package update kernel-image-6.12 in branch c10f2
Severity:
Closed issues (400)
HIGH7.8
Уязвимость функции skb_try_coalesce() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции get_dumpable() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость реализации сетевого протокола RDS ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии и вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0
CVSS:2.0/AV:L/AC:M/Au:N/C:C/I:C/A:CReferences
HIGH7.1
Уязвимость функции rds_message_purge ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:HCVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:P/A:CHIGH8.8
Уязвимость сетевого компонента skbuff ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функций remove_waiter(), futex_requeue(), rt_mutex_adjust_prio_chain() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CCRITICAL9.8
Уязвимость функции ipv6_rpl_srh_rcv компонента RFC 6554 Source Routing Header Handler ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:CHIGH8.8
Уязвимость функции t7xx_port_enum_msg_handler() ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCVSS 2.0HIGH 8.3
CVSS:2.0/AV:A/AC:L/Au:N/C:C/I:C/A:CReferences
MEDIUM5.5
Уязвимость функции dlfb ops mmap() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CMEDIUM5.5
Уязвимость функции qdisc_peek_dequeued() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:CReferences
HIGH7.0
Уязвимость компонента drivers/net/ppp/ppp_generic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:CReferences
HIGH7.8
Уязвимость функции bond_xmit_broadcast компонента drivers/net/bonding/bond_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:CReferences
HIGH7.5
Уязвимость модуля net/core/flow_dissector.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CReferences
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2723e6851309531ce61aed74e93a0cd268cc862a
- https://git.kernel.org/stable/c/5ce4a38e6c2488949e373d5066303f9c128db614
- https://git.kernel.org/stable/c/6270b1a5dab94665d7adce3dc78bc9066ed28bdd
- https://git.kernel.org/stable/c/c833d6c7199c5b5fca9ec95593acd539ec9c171c
- https://git.kernel.org/stable/c/e620378aab78d415bd8a15a2f91c145906520288
- https://git.kernel.org/stable/c/f462624a6e4b5f1ec2664c2c53e408b2f4fb53e9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix use-after-free in bond_xmit_broadcast()
bond_xmit_broadcast() reuses the original skb for the last slave
(determined by bond_is_last_slave()) and clones it for others.
Concurrent slave enslave/release can mutate the slave list during
RCU-protected iteration, changing which slave is "last" mid-loop.
This causes the original skb to be double-consumed (double-freed).
Replace the racy bond_is_last_slave() check with a simple index
comparison (i + 1 == slaves_count) against the pre-snapshot slave
count taken via READ_ONCE() before the loop. This preserves the
zero-copy optimization for the last slave while making the "last"
determination stable against concurrent list mutations.
The UAF can trigger the following crash:
==================================================================
BUG: KASAN: slab-use-after-free in skb_clone
Read of size 8 at addr ffff888100ef8d40 by task exploit/147
CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY
Call Trace:
dump_stack_lvl (lib/dump_stack.c:123)
print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:597)
skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108)
bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334)
bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593)
dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887)
__dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838)
ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136)
ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219)
ip6_output (net/ipv6/ip6_output.c:250)
ip6_send_skb (net/ipv6/ip6_output.c:1985)
udp_v6_send_skb (net/ipv6/udp.c:1442)
udpv6_sendmsg (net/ipv6/udp.c:1733)
__sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Allocated by task 147:
Freed by task 147:
The buggy address belongs to the object at ffff888100ef8c80
which belongs to the cache skbuff_head_cache of size 224
The buggy address is located 192 bytes inside of
freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)
Memory state around the buggy address:
ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2884bf72fb8f03409e423397319205de48adca16
- https://git.kernel.org/stable/c/2de5c8eea0a9db99dae7c36f4b541b74b41d3a04
- https://git.kernel.org/stable/c/a0f661918edc79d7a75e468128af8d41e2a1a83a
- https://git.kernel.org/stable/c/d4cc7e4c80b1634c7b1497574a2fdb18df6c026c
- https://git.kernel.org/stable/c/f5b94654a4a19891a8108d66ef166de6c028c6cd
- https://access.redhat.com/errata/RHSA-2026:13566
- https://access.redhat.com/errata/RHSA-2026:19521
- https://access.redhat.com/errata/RHSA-2026:21209
- https://access.redhat.com/errata/RHSA-2026:22334
- https://access.redhat.com/errata/RHSA-2026:22900
- https://access.redhat.com/errata/RHSA-2026:22940
- https://access.redhat.com/errata/RHSA-2026:23224
- https://access.redhat.com/errata/RHSA-2026:25191
- https://access.redhat.com/errata/RHSA-2026:25217
- https://access.redhat.com/errata/RHSA-2026:27353
- https://access.redhat.com/errata/RHSA-2026:27354
- https://access.redhat.com/errata/RHSA-2026:35870
- https://access.redhat.com/errata/RHSA-2026:36172
- https://access.redhat.com/errata/RHSA-2026:36530
- https://access.redhat.com/errata/RHSA-2026:36531
- https://access.redhat.com/errata/RHSA-2026:36532
- https://access.redhat.com/errata/RHSA-2026:36533
- https://access.redhat.com/errata/RHSA-2026:36534
- https://access.redhat.com/security/cve/CVE-2026-31419
- https://bugzilla.redhat.com/show_bug.cgi?id=2457829
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-31419.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: af_key: zero aligned sockaddr tail in PF_KEY exports PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/11cbf294bac623bd57296f231199193087f57b4a
- https://git.kernel.org/stable/c/2e74f974359b5382ecbe8536abbb5b837eb6c724
- https://git.kernel.org/stable/c/3c19cb8a84ef709d57943bd6664cf31cb91ba6ec
- https://git.kernel.org/stable/c/426c355742f02cf743b347d9d7dbdc1bfbfa31ef
- https://git.kernel.org/stable/c/edd446ee7cd3d02cac246168063d5b3e9ea68460
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/50ed1e7873100f77abad20fd31c51029bc49cd03
- https://git.kernel.org/stable/c/52646cbd00e765a6db9c3afe9535f26218276034
- https://git.kernel.org/stable/c/5d55c7336f8032d434adcc5fab987ccc93a44aec
- https://git.kernel.org/stable/c/71a1d9d985d26716f74d21f18ee8cac821b06e97
- https://git.kernel.org/stable/c/8253aab4659ca16116b522203c2a6b18dccacea7
- https://git.kernel.org/stable/c/a6cb440f274a22456ef3e86b457344f1678f38f9
- https://git.kernel.org/stable/c/ab8b995323e5237041472d07e5055f5f7dcdf15b
- https://git.kernel.org/stable/c/b54edf1e9a3fd3491bdcb82a21f8d21315271e0d
- https://git.kernel.org/stable/c/f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
- https://git.kernel.org/stable/c/fe785bb3a8096dffcc4048a85cd0c83337eeecad
- http://www.openwall.com/lists/oss-security/2026/05/08/7
- http://www.openwall.com/lists/oss-security/2026/05/13/6
- http://www.openwall.com/lists/oss-security/2026/05/14/2
- http://www.openwall.com/lists/oss-security/2026/05/14/4
- https://www.vicarius.io/vsociety/posts/cve-2026-43284-detection-script-dirty-frag-linux-kernel-local-privilege-escalation
- https://www.vicarius.io/vsociety/posts/cve-2026-43284-mitigation-script-dirty-frag-linux-kernel-local-privilege-escalation
- https://access.redhat.com/errata/RHSA-2026:16061
- https://access.redhat.com/errata/RHSA-2026:16062
- https://access.redhat.com/errata/RHSA-2026:16100
- https://access.redhat.com/errata/RHSA-2026:16155
- https://access.redhat.com/errata/RHSA-2026:16157
- https://access.redhat.com/errata/RHSA-2026:16160
- https://access.redhat.com/errata/RHSA-2026:16161
- https://access.redhat.com/errata/RHSA-2026:16171
- https://access.redhat.com/errata/RHSA-2026:16176
- https://access.redhat.com/errata/RHSA-2026:16180
- https://access.redhat.com/errata/RHSA-2026:16195
- https://access.redhat.com/errata/RHSA-2026:16196
- https://access.redhat.com/errata/RHSA-2026:16201
- https://access.redhat.com/errata/RHSA-2026:16202
- https://access.redhat.com/errata/RHSA-2026:16203
- https://access.redhat.com/errata/RHSA-2026:16204
- https://access.redhat.com/errata/RHSA-2026:16206
- https://access.redhat.com/errata/RHSA-2026:16254
- https://access.redhat.com/errata/RHSA-2026:16312
- https://access.redhat.com/errata/RHSA-2026:16314
- https://access.redhat.com/errata/RHSA-2026:16328
- https://access.redhat.com/errata/RHSA-2026:17795
- https://access.redhat.com/errata/RHSA-2026:18025
- https://access.redhat.com/errata/RHSA-2026:19074
- https://access.redhat.com/errata/RHSA-2026:19225
- https://access.redhat.com/errata/RHSA-2026:19564
- https://access.redhat.com/errata/RHSA-2026:19568
- https://access.redhat.com/errata/RHSA-2026:19569
- https://access.redhat.com/errata/RHSA-2026:19572
- https://access.redhat.com/errata/RHSA-2026:19573
- https://access.redhat.com/errata/RHSA-2026:19574
- https://access.redhat.com/errata/RHSA-2026:19575
- https://access.redhat.com/errata/RHSA-2026:19577
- https://access.redhat.com/errata/RHSA-2026:21695
- https://access.redhat.com/errata/RHSA-2026:23233
- https://access.redhat.com/errata/RHSA-2026:26542
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/errata/RHSA-2026:34098
- https://access.redhat.com/security/cve/CVE-2026-43284
- https://bugzilla.redhat.com/show_bug.cgi?id=2467771
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
- https://cert-portal.siemens.com/productcert/html/ssa-082556.html
- https://github.com/V4bel/dirtyfrag
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43284.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate inherited ACE SID length smb_inherit_dacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.num_subauth is fully contained in the ACE. A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. compare_sids() may then read past the ACE. smb_set_ace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and nt_size accounting past the allocated buffer. Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smb_acl.size or the security descriptor allocation size.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1aa60fea7f637c071f529ad6784aecca2f2f0c5f
- https://git.kernel.org/stable/c/47c6e37a77b10e74f70d845ba4ea5d3cafa00336
- https://git.kernel.org/stable/c/996454bc0da84d5a1dedb1a7861823087e01a7ae
- https://git.kernel.org/stable/c/a7fb771314fb3a265d30f8ac245869a367ab065c
- https://git.kernel.org/stable/c/c1d95c995d5bcb24b639200a899eda59cb1e6d64
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/35fb4a0c077c5d1049c2628b769e0a1b1e65df0d
- https://git.kernel.org/stable/c/3efaad55cad1ded429e3a873bfece389058a526b
- https://git.kernel.org/stable/c/868202aa2adae427060a42d5bd663b4d782ec02c
- https://git.kernel.org/stable/c/d5ee2ff98322337951c56398e79d51815acbf955
- https://git.kernel.org/stable/c/e6f6cd501fb54060940a6eb3f4103eeb5e426ae7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting "lzeros" from the unsigned "nbytes". For this to happen, the scatterlist "sgl" needs to occupy more bytes than the "nbytes" parameter and the first "nbytes + 1" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than "nbytes", subtract the number of zeroes from "nbytes" and cause the underflow. When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to "nbytes". However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger "out_len" than "in_len" and filling the "in" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the "src" and "dst" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1abd50fc3cfa16fc2074a3c8c2729c50fd9d7043
- https://git.kernel.org/stable/c/26d3a97ad46c7a9226ec04d4bf35bd4998a97d16
- https://git.kernel.org/stable/c/2aa77a18dc7f2670497fe3ee5acbeda0b57659e5
- https://git.kernel.org/stable/c/30e513e755bb381afce6fb57cdc8694136193f22
- https://git.kernel.org/stable/c/6d63615c796c085b4984e3031b9fa77fffb47360
- https://git.kernel.org/stable/c/8637dfb4c1d8a7026ef681f2477c6de8b71c4003
- https://git.kernel.org/stable/c/8c2f1288250a90a4b5cabed5d888d7e3aeed4035
- https://git.kernel.org/stable/c/a1793a48881ec8d26e9c79b0ee65753f1c6846a4
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1d7f07df450bac3301938fbc4251f2611be4084e
- https://git.kernel.org/stable/c/46271895ddfb1ba41f89f7e0dffbe9c2bcf7380a
- https://git.kernel.org/stable/c/76641449b28979ebd6c02e9598367e119e385236
- https://git.kernel.org/stable/c/77d55bc8675ee851ed639dc9be77325a8024cf67
- https://git.kernel.org/stable/c/915b692e6cb723aac658c25eb82c58fd81235110
- https://git.kernel.org/stable/c/9f1cbca178c03188e201ed175251372149bb25f2
- https://git.kernel.org/stable/c/ae7e95638d956d556d74b9abb9e780d3bd3dcd9e
- https://git.kernel.org/stable/c/eb34e243df57e32f4c08fa191f3602ea19076276
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/rds: reset op_nents when zerocopy page pin fails When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/03014551938a0887fa55f18ce49b70158a9c0113
- https://git.kernel.org/stable/c/0bbbff00a15b1df2cac9014d6cf4b6890f473353
- https://git.kernel.org/stable/c/290e833d1acb1093bc121fcdc97f5e6161157479
- https://git.kernel.org/stable/c/640e37f58f991546a87540d067279c2c1fa9fe51
- https://git.kernel.org/stable/c/9115669faedccdda100428e2d26fd0aac8c50799
- https://git.kernel.org/stable/c/c6e51512a784c4a7b86e1a044988696e3b3721fa
- https://git.kernel.org/stable/c/d84ce1786ce40fdd3dd98db47aec5527817e1ef6
- https://git.kernel.org/stable/c/e174929793195e0cd6a4adb0cad731b39f9019b4
- https://github.com/v12-security/pocs/tree/main/pintheft
- http://www.openwall.com/lists/oss-security/2026/05/21/2
- https://access.redhat.com/security/cve/CVE-2026-43494
- https://bugzilla.redhat.com/show_bug.cgi?id=2480434
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43494.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as a loop bound over port_msg->data[] without checking that the message buffer contains sufficient data. A modem sending port_count=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes. Add a sizeof(*port_msg) check before accessing the port message header fields to guard against undersized messages. Add a struct_size() check after extracting port_count and before the loop. In t7xx_parse_host_rt_data(), guard the rt_feature header read with a remaining-buffer check before accessing data_len, validate feat_data_len against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset. Pass msg_len from both call sites: skb->len at the DPMAIF path after skb_pull(), and the validated feat_data_len at the handshake path.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0e7c074cfcd9bd93765505f9eb8b42f03ed2a744
- https://git.kernel.org/stable/c/2b56d7903ab804481f5233a259d5f341e9fd513c
- https://git.kernel.org/stable/c/307c5d0f36a5c74042217136da5bfbd9f7504650
- https://git.kernel.org/stable/c/9855e063e063158cc5bded576382599dc3133202
- https://git.kernel.org/stable/c/dd4f4c93c1488d7100b9964f2da4c8b3c29652f1
- https://git.kernel.org/stable/c/f94450ce5053b36002995b72d1fa1db3bb08c5bf
- http://www.openwall.com/lists/oss-security/2026/06/18/1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_red: Replace direct dequeue call with peek and qdisc_dequeue_peeked
When red qdisc has children (eg qfq qdisc) whose peek() callback is
qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such
qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from
its child (red in this case), it will do the following:
1a. do a peek() - and when sensing there's an skb the child can offer, then
- the child in this case(red) calls its child's (qfq) peek.
qfq does the right thing and will return the gso_skb queue packet.
Note: if there wasnt a gso_skb entry then qfq will store it there.
1b. invoke a dequeue() on the child (red). And herein lies the problem.
- red will call the child's dequeue() which will essentially just
try to grab something of qfq's queue.
[ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]
[ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full)
[ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 78.668486][ T363] RIP: 0010:qfq_dequeue+0x446/0xc90 [sch_qfq]
[ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d
[ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216
[ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048
[ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078
[ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000
[ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200
[ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000
[ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0
[ 78.671585][ T363] PKRU: 55555554
[ 78.671713][ T363] Call Trace:
[ 78.671843][ T363]
[ 78.671936][ T363] ? __pfx_qfq_dequeue+0x10/0x10 [sch_qfq]
[ 78.672148][ T363] ? __pfx__printk+0x10/0x10
[ 78.672322][ T363] ? srso_alias_return_thunk+0x5/0xfbef5
[ 78.672496][ T363] ? lockdep_hardirqs_on_prepare+0xa8/0x1a0
[ 78.672706][ T363] ? srso_alias_return_thunk+0x5/0xfbef5
[ 78.672875][ T363] ? trace_hardirqs_on+0x19/0x1a0
[ 78.673047][ T363] red_dequeue+0x65/0x270 [sch_red]
[ 78.673217][ T363] ? srso_alias_return_thunk+0x5/0xfbef5
[ 78.673385][ T363] tbf_dequeue.cold+0xb0/0x70c [sch_tbf]
[ 78.673566][ T363] __qdisc_run+0x169/0x1900
The right thing to do in #1b is to grab the skb off gso_skb queue.
This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked()
method instead.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/03b0aaeba082ae981a0dfe96cdd03d02050537a1
- https://git.kernel.org/stable/c/36aa34f42cb6842cf371f3a2d3e855d24fd57a50
- https://git.kernel.org/stable/c/458d5615272d3de535748342eb68ca492343048c
- https://git.kernel.org/stable/c/45cd83c5c470ba49fe261489c8358ad7b9df7c45
- https://git.kernel.org/stable/c/587dcf970a525f543d8b5855d9f37a4ca97b76ef
- https://git.kernel.org/stable/c/8d09618840b99ef00154d3e731ce9b11e096196d
- https://git.kernel.org/stable/c/c7335f4dc0fa21f7015b910c6fc2f4d599732328
- https://git.kernel.org/stable/c/ce051eede433f876d322ac3550a36a3c6fc4c231
HIGH7.3
In the Linux kernel, the following vulnerability has been resolved: fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages. Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs. Tested with PoC using dummy_hcd + raw_gadget USB device emulation.
CVSS 3.xHIGH 7.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/18dd358de72d57993422cbb5dfb29ccd74efe192
- https://git.kernel.org/stable/c/4f312c30f0368e8d2a76aa650dff73f23490b5e7
- https://git.kernel.org/stable/c/5931f5651ee32bd41b3323256b31fcc8e71336ed
- https://git.kernel.org/stable/c/60f711cfd580f86fea8284146ac133804e728f9a
- https://git.kernel.org/stable/c/8de779dc40d35d39fa07387b6f921eb11df0f511
- https://git.kernel.org/stable/c/a2c53a3822ee26e8d758071815b9ed3bf6669fc1
- https://git.kernel.org/stable/c/da9b065cedfd3b574f229d5be594e6aa47a27ae6
- https://git.kernel.org/stable/c/e3d9865dacd7435b8465848428210d0f0c673311
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the latter case waiter::task is not current, but remove_waiter() operates on current for the dequeue operation. That results in several problems: 1) the rbtree dequeue happens without waiter::task::pi_lock being held 2) the waiter task's pi_blocked_on state is not cleared, which leaves a dangling pointer primed for UAF around. 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter task Use waiter::task instead of current in all related operations in remove_waiter() to cure those problems. [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the changelog ]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
- https://git.kernel.org/stable/c/3fb7394a837740770f0d6b4b30567e60786a63f2
- https://git.kernel.org/stable/c/6d52dfcb2a5db86e346cf51f8fcf2071b8085166
- https://git.kernel.org/stable/c/838ce5cb5d93c3ab8b27e75bc6ad905a94b752fd
- https://git.kernel.org/stable/c/88614876370aac8ad1050ad785a4c095ba17ac11
- https://git.kernel.org/stable/c/8a1fc8d698ac5e5916e3082a0f74450d71f9611f
- https://git.kernel.org/stable/c/d8cce4773c2b23d819baf5abedc62f7b430e8745
- https://git.kernel.org/stable/c/f3fa3424bceb128d2be4b3745506b22844b87db7
- http://www.openwall.com/lists/oss-security/2026/07/08/12
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0a9e8053f1f8a8e1bfc1dd61ffe67be6c1180402
- https://git.kernel.org/stable/c/4babc2d9fda2df43823b85d08a0180b68f1b0854
- https://git.kernel.org/stable/c/7398ebefbfd4f8a31d4f665a4213302fa995494b
- https://git.kernel.org/stable/c/8e8be63465a5e80394c70324603dfea1bfdad48f
- https://git.kernel.org/stable/c/9e6bf146b55999a095bb14f73a843942456d1adc
- https://git.kernel.org/stable/c/bde199c72d319a4e207f88daabc888317504e2fb
- https://git.kernel.org/stable/c/be1fa0aa9b4fdd5a8b7a61ba520a690a68391e6e
- https://git.kernel.org/stable/c/c261d07a80576dc8ccf394ef8f074f8c67a06b37
- https://access.redhat.com/errata/RHSA-2026:25191
- https://access.redhat.com/errata/RHSA-2026:25217
- https://access.redhat.com/errata/RHSA-2026:27713
- https://access.redhat.com/errata/RHSA-2026:27731
- https://access.redhat.com/errata/RHSA-2026:33900
- https://access.redhat.com/errata/RHSA-2026:34094
- https://access.redhat.com/errata/RHSA-2026:34095
- https://access.redhat.com/security/cve/CVE-2026-43501
- https://bugzilla.redhat.com/show_bug.cgi?id=2480457
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43501.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0f5c185fc79a59ee9991234dd6d2a3e5afa6e75b
- https://git.kernel.org/stable/c/14ef6fd18db2494098b21e0471bf27a1d8e9993e
- https://git.kernel.org/stable/c/1e262db7675e27f42c3f3f47d6011855f4454f24
- https://git.kernel.org/stable/c/21d70744e6d3bbf9293aa1ee6fba7c53ad75275e
- https://git.kernel.org/stable/c/3abc8983b2bae3f487f77d9da5527d7d6b210d46
- https://git.kernel.org/stable/c/44b550d88b267320459d518c0743a241ab2108fa
- https://git.kernel.org/stable/c/46662f7dc59475995609bf3e9d27eb36f4acf26f
- https://git.kernel.org/stable/c/e9aefdc5c53fe9aed108c14e3d155710a1bb14c9
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination. __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched. As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.
The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data(). ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to ' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source. skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list. Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb. The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb. Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/12401fcfb01f53ccc63ab0a3246570fe8f3105ee
- https://git.kernel.org/stable/c/179f1852bdedc300e373e807cc102cd81feff196
- https://git.kernel.org/stable/c/48f6a5356a33dd78e7144ae1faef95ffc990aae0
- https://git.kernel.org/stable/c/989214c66884d70716d83dc1d0bf5e16287bf349
- https://git.kernel.org/stable/c/9bc9d6d6967a2239aa57af2aa53554eddd640d20
- https://git.kernel.org/stable/c/fbeab9555564a1b98e8582cd106dfe46c4606991
- https://git.kernel.org/stable/c/fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8
- https://git.kernel.org/stable/c/ff375cc75f9167168db38e0464a482d5fbc8d81d
- https://access.redhat.com/errata/RHSA-2026:19521
- https://access.redhat.com/errata/RHSA-2026:19540
- https://access.redhat.com/errata/RHSA-2026:19568
- https://access.redhat.com/errata/RHSA-2026:19569
- https://access.redhat.com/errata/RHSA-2026:19664
- https://access.redhat.com/errata/RHSA-2026:19666
- https://access.redhat.com/errata/RHSA-2026:19705
- https://access.redhat.com/errata/RHSA-2026:19711
- https://access.redhat.com/errata/RHSA-2026:19875
- https://access.redhat.com/errata/RHSA-2026:20051
- https://access.redhat.com/errata/RHSA-2026:20054
- https://access.redhat.com/errata/RHSA-2026:20087
- https://access.redhat.com/errata/RHSA-2026:20129
- https://access.redhat.com/errata/RHSA-2026:20130
- https://access.redhat.com/errata/RHSA-2026:20299
- https://access.redhat.com/errata/RHSA-2026:20593
- https://access.redhat.com/errata/RHSA-2026:21656
- https://access.redhat.com/errata/RHSA-2026:21690
- https://access.redhat.com/errata/RHSA-2026:21695
- https://access.redhat.com/errata/RHSA-2026:21702
- https://access.redhat.com/errata/RHSA-2026:23233
- https://access.redhat.com/errata/RHSA-2026:23240
- https://access.redhat.com/errata/RHSA-2026:23245
- https://access.redhat.com/errata/RHSA-2026:23468
- https://access.redhat.com/errata/RHSA-2026:23469
- https://access.redhat.com/errata/RHSA-2026:23470
- https://access.redhat.com/errata/RHSA-2026:23471
- https://access.redhat.com/errata/RHSA-2026:24814
- https://access.redhat.com/errata/RHSA-2026:25044
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/security/cve/CVE-2026-43503
- https://bugzilla.redhat.com/show_bug.cgi?id=2480902
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43503.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0c17c8832562b2aac288e89cefd0f46074f54bcb
- https://git.kernel.org/stable/c/1810e42ff6716f320c7269d5850eca48b07b7427
- https://git.kernel.org/stable/c/1b1c0da227bf63479bac9982fc8d12df9aaea0fb
- https://git.kernel.org/stable/c/2ff1a41a912de8517b4482e946dd951b7d80edbf
- https://git.kernel.org/stable/c/5105f3e6b2df619c635b5f6a49fac131a36c7952
- https://git.kernel.org/stable/c/85426e97dc72f2088ba6d27e74cd58c3fbd43e31
- https://git.kernel.org/stable/c/a2dcf1a61d056aef15b63c6eae9441344d624389
- https://git.kernel.org/stable/c/c88c185ae0a1067823661b220aeea613df2c127b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_new_connection_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a120d96166301d7a95be75b52f843837dbd1219
- https://git.kernel.org/stable/c/140b63cb46f2855ac4ec8fba2f1e974a9c2974e8
- https://git.kernel.org/stable/c/2422eaed0925973c0f318c94eb13e76f14c7381e
- https://git.kernel.org/stable/c/684a1f9ee2325437ae18ac5371884e4c6a25ae73
- https://git.kernel.org/stable/c/741e6024e31587b0c021b6616a9e428a4ea0b64a
- https://git.kernel.org/stable/c/76083fb80f5a38ac13326b2d810f66bd07771eea
- https://git.kernel.org/stable/c/ab77c8bc30269bee15d917059a66bea48909f5f0
- https://git.kernel.org/stable/c/bc3bb9f40da8e53896abc2d29c6d0c6686fe4ab9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() Add the same NULL guard already present in l2cap_sock_resume_cb() and l2cap_sock_ready_cb().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/32bd343803d4ba47cc516f9d5f037f01b855d767
- https://git.kernel.org/stable/c/58dc5e3d8768e121907608e6e196a908512fb083
- https://git.kernel.org/stable/c/6e8d1a2a677a81caa60cf0aabd4217bd585fbba1
- https://git.kernel.org/stable/c/78a88d43dab8d23aeef934ed8ce34d40e6b3d613
- https://git.kernel.org/stable/c/a93d66907dd4d29b65c9797a93784bf61906d6d6
- https://git.kernel.org/stable/c/cf1fd517f892ded88168df878f834b625133f86d
- https://git.kernel.org/stable/c/e1863e7480feddb90125d0dd5a1b572972d75908
- https://git.kernel.org/stable/c/fd072f833147b0bc10c43a454624cb99d02f3fc7
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in arena_vm_close on fork arena_vm_open() only bumps vml->mmap_count but never registers the child VMA in arena->vma_list. The vml->vma always points at the parent VMA, so after parent munmap the pointer dangles. If the child then calls bpf_arena_free_pages(), zap_pages() reads the stale vml->vma triggering use-after-free. Fix this by preventing the arena VMA from being inherited across fork with VM_DONTCOPY, and preventing VMA splits via the may_split callback. Also reject mremap with a .mremap callback returning -EINVAL. A same-size mremap(MREMAP_FIXED) on the full arena VMA reaches copy_vma() through the following path: check_prep_vma() - returns 0 early: new_len == old_len skips VM_DONTEXPAND check prep_move_vma() - vm_start == old_addr and vm_end == old_addr + old_len so may_split is never called move_vma() copy_vma_and_data() copy_vma() vm_area_dup() - copies vm_private_data (vml pointer) vm_ops->open() - bumps vml->mmap_count vm_ops->mremap() - returns -EINVAL, rollback unmaps new VMA The refcount ensures the rollback's arena_vm_close does not free the vml shared with the original VMA.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: fix end-of-list detection in cgroup_storage_get_next_key() list_next_entry() never returns NULL -- when the current element is the last entry it wraps to the list head via container_of(). The subsequent NULL check is therefore dead code and get_next_key() never returns -ENOENT for the last element, instead reading storage->key from a bogus pointer that aliases internal map fields and copying the result to userspace. Replace it with list_entry_is_head() so the function correctly returns -ENOENT when there are no more entries.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0f3d9dd5e1fd52b39e25328307c6a694e994ffe3
- https://git.kernel.org/stable/c/26d3339e465e54107bd85884341d1609c5300d6a
- https://git.kernel.org/stable/c/2c88b2d96e1d4d0c7c4589a4593d4cdee6d332d6
- https://git.kernel.org/stable/c/32ce55d424395904986f5066f8755f6cb9993377
- https://git.kernel.org/stable/c/5828b9e5b272ecff7cf5d345128d3de7324117f7
- https://git.kernel.org/stable/c/85a2f30e40f7468db732f55659bc6318874f49af
- https://git.kernel.org/stable/c/b4b5a20bed82130da2f2818f04d52378952fbd0b
- https://git.kernel.org/stable/c/fc39753b7f92e09177777e9c648afe5aa3abb81f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
bpf: reject negative CO-RE accessor indices in bpf_core_parse_spec()
CO-RE accessor strings are colon-separated indices that describe a path
from a root BTF type to a target field, e.g. "0:1:2" walks through
nested struct members. bpf_core_parse_spec() parses each component with
sscanf("%d"), so negative values like -1 are silently accepted. The
subsequent bounds checks (access_idx >= btf_vlen(t)) only guard the
upper bound and always pass for negative values because C integer
promotion converts the __u16 btf_vlen result to int, making the
comparison (int)(-1) >= (int)(N) false for any positive N.
When -1 reaches btf_member_bit_offset() it gets cast to u32 0xffffffff,
producing an out-of-bounds read far past the members array. A crafted
BPF program with a negative CO-RE accessor on any struct that exists in
vmlinux BTF (e.g. task_struct) crashes the kernel deterministically
during BPF_PROG_LOAD on any system with CONFIG_DEBUG_INFO_BTF=y
(default on major distributions). The bug is reachable with CAP_BPF:
BUG: unable to handle page fault for address: ffffed11818b6626
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 85 Comm: poc Not tainted 7.0.0-rc6 #18 PREEMPT(full)
RIP: 0010:bpf_core_parse_spec (tools/lib/bpf/relo_core.c:354)
RAX: 00000000ffffffff
Call Trace:
bpf_core_calc_relo_insn (tools/lib/bpf/relo_core.c:1321)
bpf_core_apply (kernel/bpf/btf.c:9507)
check_core_relo (kernel/bpf/verifier.c:19475)
bpf_check (kernel/bpf/verifier.c:26031)
bpf_prog_load (kernel/bpf/syscall.c:3089)
__sys_bpf (kernel/bpf/syscall.c:6228)
CO-RE accessor indices are inherently non-negative (struct member index,
array element index, or enumerator index), so reject them immediately
after parsing.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1c22483a2c4bbf747787f328392ca3e68619c4dc
- https://git.kernel.org/stable/c/36a9012f76ba8d9189ae56a1f8bb7c87c07a1f3a
- https://git.kernel.org/stable/c/3ff85ae79e1a74baeb916b78a63d821f6d19a994
- https://git.kernel.org/stable/c/669349b4612c26b3d7aacfa99d7174681bd19223
- https://git.kernel.org/stable/c/76f2ebaf79a9ae6d0737b87f045fe769e425d78f
- https://git.kernel.org/stable/c/99dbab7b5a12d8f58d5b0aa2f7a1fe656a70f4b2
- https://git.kernel.org/stable/c/a9e777f856cd2f1efc106afc7bf21aef868509d5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
openvswitch: cap upcall PID array size and pre-size vport replies
The vport netlink reply helpers allocate a fixed-size skb with
nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
array via ovs_vport_get_upcall_portids(). Since
ovs_vport_set_upcall_portids() accepts any non-zero multiple of
sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
array large enough to overflow the reply buffer, causing nla_put() to
fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with
unprivileged user namespaces enabled (e.g., Ubuntu default), this is
reachable via unshare -Urn since OVS vport mutation operations use
GENL_UNS_ADMIN_PERM.
kernel BUG at net/openvswitch/datapath.c:2414!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1
RIP: 0010:ovs_vport_cmd_set+0x34c/0x400
Call Trace:
genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)
genl_rcv_msg (net/netlink/genetlink.c:1194)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
genl_rcv (net/netlink/genetlink.c:1219)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
__sys_sendto (net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Kernel panic - not syncing: Fatal exception
Reject attempts to set more PIDs than nr_cpu_ids in
ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply
size in ovs_vport_cmd_msg_size() based on that bound, similar to the
existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already
used by the per-CPU dispatch configuration on the datapath side
(ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the
two sides stay consistent.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1d6c02b86329883aa467a3a61f8d34369db73a2f
- https://git.kernel.org/stable/c/2091c6aa0df6aba47deb5c8ab232b1cb60af3519
- https://git.kernel.org/stable/c/8d59b80e69dddb665eb2de36e62859ab2073470e
- https://git.kernel.org/stable/c/b39f763d720d623218bc1d95ace6855d7b474e81
- https://git.kernel.org/stable/c/d9e47e29aacb9f8a9d59feb6ab5b128a9bbb40b0
- https://git.kernel.org/stable/c/f99ac36b5d7c719d08a69fcdecce40f78a874e15
- https://git.kernel.org/stable/c/f9ef3db77a383d66847fd082c2b437d8ae4d9c63
- https://git.kernel.org/stable/c/fa6e90bc443bed8dc0d55bc5ea5b27ffdfe37704
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_osf: fix divide-by-zero in OSF_WSS_MODULO
nf_osf_match_one() computes ctx->window % f->wss.val in the
OSF_WSS_MODULO branch with no guard for f->wss.val == 0. A
CAP_NET_ADMIN user can add such a fingerprint via nfnetlink; a
subsequent matching TCP SYN divides by zero and panics the kernel.
Reject the bogus fingerprint in nfnl_osf_add_callback() above the
per-option for-loop. f->wss is per-fingerprint, not per-option, so
the check must run regardless of f->opt_num (including 0). Also
reject wss.wc >= OSF_WSS_MAX; nf_osf_match_one() already treats that
as "should not happen".
Crash:
Oops: divide error: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)
Call Trace:
nf_osf_match (net/netfilter/nfnetlink_osf.c:220)
xt_osf_match_packet (net/netfilter/xt_osf.c:32)
ipt_do_table (net/ipv4/netfilter/ip_tables.c:348)
nf_hook_slow (net/netfilter/core.c:622)
ip_local_deliver (net/ipv4/ip_input.c:265)
ip_rcv (include/linux/skbuff.h:1162)
__netif_receive_skb_one_core (net/core/dev.c:6181)
process_backlog (net/core/dev.c:6642)
__napi_poll (net/core/dev.c:7710)
net_rx_action (net/core/dev.c:7945)
handle_softirqs (kernel/softirq.c:622)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0694618cf3e9b120666e31f5f383a6e466d95a0d
- https://git.kernel.org/stable/c/2195574dc6d9017d32ac346987e12659f931d932
- https://git.kernel.org/stable/c/26900306a5a2c3e4f75c643a064525526bb6e5f3
- https://git.kernel.org/stable/c/8def8fbd23f40e945febe913d04b731012ce0082
- https://git.kernel.org/stable/c/9a05e195618a6d474f2bcd5b6376d0ffc2f00366
- https://git.kernel.org/stable/c/c55940895245d8ef658ab381248a28755218d625
- https://git.kernel.org/stable/c/cb833bbc1b3c51e08652d3c86298307c07d3f2db
- https://git.kernel.org/stable/c/fb965b1cfe92b28d28b5ebe3116b81dbef9f2d2f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
slip: reject VJ receive packets on instances with no rstate array
slhc_init() accepts rslots == 0 as a valid configuration, with the
documented meaning of 'no receive compression'. In that case the
allocation loop in slhc_init() is skipped, so comp->rstate stays
NULL and comp->rslot_limit stays 0 (from the kzalloc of struct
slcompress).
The receive helpers do not defend against that configuration.
slhc_uncompress() dereferences comp->rstate[x] when the VJ header
carries an explicit connection ID, and slhc_remember() later assigns
cs = &comp->rstate[...] after only comparing the packet's slot number
to comp->rslot_limit. Because rslot_limit is 0, slot 0 passes the
range check, and the code dereferences a NULL rstate.
The configuration is reachable in-tree through PPP. PPPIOCSMAXCID
stores its argument in a signed int, and (val >> 16) uses arithmetic
shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1
is 0 and ppp_generic.c ends up calling slhc_init(0, 1). Because
/dev/ppp open is gated by ns_capable(CAP_NET_ADMIN), the whole path
is reachable from an unprivileged user namespace. Once the malformed
VJ state is installed, any inbound VJ-compressed or VJ-uncompressed
frame that selects slot 0 crashes the kernel in softirq context:
Oops: general protection fault, probably for non-canonical
address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:slhc_uncompress (drivers/net/slip/slhc.c:519)
Call Trace:
ppp_receive_nonmp_frame (drivers/net/ppp/ppp_generic.c:2466)
ppp_input (drivers/net/ppp/ppp_generic.c:2359)
ppp_async_process (drivers/net/ppp/ppp_async.c:492)
tasklet_action_common (kernel/softirq.c:926)
handle_softirqs (kernel/softirq.c:623)
run_ksoftirqd (kernel/softirq.c:1055)
smpboot_thread_fn (kernel/smpboot.c:160)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:164)
Reject the receive side on such instances instead of touching rstate.
slhc_uncompress() falls through to its existing 'bad' label, which
bumps sls_i_error and enters the toss state. slhc_remember() mirrors
that with an explicit sls_i_error increment followed by slhc_toss();
the sls_i_runt counter is not used here because a missing rstate is
an internal configuration state, not a runt packet.
The transmit path is unaffected: the only in-tree caller that picks
rslots from userspace (ppp_generic.c) still supplies tslots >= 1, and
slip.c always calls slhc_init(16, 16), so comp->tstate remains valid
and slhc_compress() continues to work.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3d71c961febddd855d3ae9a519eeb96c8023f430
- https://git.kernel.org/stable/c/4aa9eca6fda2919027dfd7a7cc69334982d89586
- https://git.kernel.org/stable/c/72304fec672e8aac9ee7b9c475db96b37cca8d8d
- https://git.kernel.org/stable/c/7b0d9e878ec2b21d99ae8051b3dda59cdb66c152
- https://git.kernel.org/stable/c/9e1ff0eead073c4f46d874ad2526b7dda5465faf
- https://git.kernel.org/stable/c/c6980e8b1a86288167f34966fa5219031999b6f1
- https://git.kernel.org/stable/c/de42f86e2cf5028a97e74c25869d1a962b13c301
- https://git.kernel.org/stable/c/e76607442d5b73e1ba6768f501ef815bb58c2c0e
HIGH8.2
In the Linux kernel, the following vulnerability has been resolved: slip: bound decode() reads against the compressed packet length slhc_uncompress() parses a VJ-compressed TCP header by advancing a pointer through the packet via decode() and pull16(). Neither helper bounds-checks against isize, and decode() masks its return with & 0xffff so it can never return the -1 that callers test for -- those error paths are dead code. A short compressed frame whose change byte requests optional fields lets decode() read past the end of the packet. The over-read bytes are folded into the cached cstate and reflected into subsequent reconstructed packets. Make decode() and pull16() take the packet end pointer and return -1 when exhausted. Add a bounds check before the TCP-checksum read. The existing == -1 tests now do what they were always meant to.
CVSS 3.xHIGH 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:NReferences
- https://git.kernel.org/stable/c/0511ecb00e61bf28e2fec4bb41fcce385c3a3b2d
- https://git.kernel.org/stable/c/335957df4ed60f02a2ec0432fbedbf0cc7241d8b
- https://git.kernel.org/stable/c/37537e42e6df387398bee85cb85070cc80bb1e10
- https://git.kernel.org/stable/c/4c1367a2d7aad643a6f87c6931b13cc1a25e8ca7
- https://git.kernel.org/stable/c/4cefe32639933d652614b0bd50f818f9af4af78f
- https://git.kernel.org/stable/c/6268f01ae989013671b526c883e92655342c6f6f
- https://git.kernel.org/stable/c/9aafba2f49e1fcccc2018816f5836a609c925879
- https://git.kernel.org/stable/c/d42bec6e4f6d6d658be365539400b3314b76b2a7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
netfilter: arp_tables: fix IEEE1394 ARP payload parsing
Weiming Shi says:
"arp_packet_match() unconditionally parses the ARP payload assuming two
hardware addresses are present (source and target). However,
IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address
field, and arp_hdr_len() already accounts for this by returning a
shorter length for ARPHRD_IEEE1394 devices.
As a result, on IEEE1394 interfaces arp_packet_match() advances past a
nonexistent target hardware address and reads the wrong bytes for both
the target device address comparison and the target IP address. This
causes arptables rules to match against garbage data, leading to
incorrect filtering decisions: packets that should be accepted may be
dropped and vice versa.
The ARP stack in net/ipv4/arp.c (arp_create and arp_process) already
handles this correctly by skipping the target hardware address for
ARPHRD_IEEE1394. Apply the same pattern to arp_packet_match()."
Mangle the original patch to always return 0 (no match) in case user
matches on the target hardware address which is never present in
IEEE1394.
Note that this returns 0 (no match) for either normal and inverse match
because matching in the target hardware address in ARPHRD_IEEE1394 has
never been supported by arptables. This is intentional, matching on the
target hardware address should never evaluate true for ARPHRD_IEEE1394.
Moreover, adjust arpt_mangle to drop the packet too as AI suggests:
In arpt_mangle, the logic assumes a standard ARP layout. Because
IEEE1394 (FireWire) omits the target hardware address, the linear
pointer arithmetic miscalculates the offset for the target IP address.
This causes mangling operations to write to the wrong location, leading
to packet corruption. To ensure safety, this patch drops packets
(NF_DROP) when mangling is requested for these fields on IEEE1394
devices, as the current implementation cannot correctly map the FireWire
ARP payload.
This omits both mangling target hardware and IP address. Even if IP
address mangling should be possible in IEEE1394, this would require
to adjust arpt_mangle offset calculation, which has never been
supported.
Based on patch from Weiming Shi .
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/03ea11dbefaa55c502735ee551c89ef773fe753b
- https://git.kernel.org/stable/c/0f23a1457695f1a61f64367e39f0f9cfa29947d1
- https://git.kernel.org/stable/c/1c55053f8ffdc060006df898fd3664e3d1bfac7b
- https://git.kernel.org/stable/c/1e285362ef7096eb12733370d59e033f4a1d294a
- https://git.kernel.org/stable/c/1e8e3f449b1e73b73a843257635b9c50f0cc0f0a
- https://git.kernel.org/stable/c/84e8536c981338d0d8cc6e712cf71a936a93e13f
- https://git.kernel.org/stable/c/ac698d81fd6619c7504cee913f1cab5285fba1b7
- https://git.kernel.org/stable/c/ad9973df8e0eeb123d9ec4d18828e05b7d44ff4b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: fix NULL pointer dereference in class dump
When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
Subsequent RTM_GETTCLASS dump operations walk all classes via
taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
returning the NULL pointer, then dereferences it to read child->handle,
causing a kernel NULL pointer dereference.
The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
namespaces enabled, an unprivileged local user can trigger a kernel
panic by creating a taprio qdisc inside a new network namespace,
grafting an explicit child qdisc, deleting it, and requesting a class
dump. The RTM_GETTCLASS dump itself requires no capability.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2478)
Call Trace:
tc_fill_tclass (net/sched/sch_api.c:1966)
qdisc_class_dump (net/sched/sch_api.c:2326)
taprio_walk (net/sched/sch_taprio.c:2514)
tc_dump_tclass_qdisc (net/sched/sch_api.c:2352)
tc_dump_tclass_root (net/sched/sch_api.c:2370)
tc_dump_tclass (net/sched/sch_api.c:2431)
rtnl_dumpit (net/core/rtnetlink.c:6864)
netlink_dump (net/netlink/af_netlink.c:2325)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6959)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
Fix this by substituting &noop_qdisc when new is NULL in
taprio_graft(), a common pattern used by other qdiscs (e.g.,
multiq_graft()) to ensure the q->qdiscs[] slots are never NULL.
This makes control-plane dump paths safe without requiring individual
NULL checks.
Since the data-plane paths (taprio_enqueue and taprio_dequeue_from_txq)
previously had explicit NULL guards that would drop/skip the packet
cleanly, update those checks to test for &noop_qdisc instead. Without
this, packets would reach taprio_enqueue_one() which increments the root
qdisc's qlen and backlog before calling the child's enqueue; noop_qdisc
drops the packet but those counters are never rolled back, permanently
inflating the root qdisc's statistics.
After this change *old can be a valid qdisc, NULL, or &noop_qdisc.
Only call qdisc_put(*old) in the first case to avoid decreasing
noop_qdisc's refcount, which was never increased.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3d07ca5c0fae311226f737963984bd94bb159a87
- https://git.kernel.org/stable/c/48b26d48e76221dc90b02bf5428bab53643461ca
- https://git.kernel.org/stable/c/8f1ff8866cb9f655e5faea6994eb902960be8e04
- https://git.kernel.org/stable/c/d02e2fbf60de46678e2ea698a6a904fd21e1cc31
- https://git.kernel.org/stable/c/ec2501e361b08b50bcb1e7b3253fc861abbda28d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()
bareudp_fill_metadata_dst() passes bareudp->sock to
udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check.
The socket is only created in bareudp_open() and NULLed in
bareudp_stop(), so calling this function while the device is down
triggers a NULL dereference via sock->sk.
BUG: kernel NULL pointer dereference, address: 0000000000000018
RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160)
Call Trace:
bareudp_fill_metadata_dst (drivers/net/bareudp.c:532)
do_execute_actions (net/openvswitch/actions.c:901)
ovs_execute_actions (net/openvswitch/actions.c:1589)
ovs_packet_cmd_execute (net/openvswitch/datapath.c:700)
genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114)
genl_rcv_msg (net/netlink/genetlink.c:1209)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
Add a NULL check returning -ESHUTDOWN, consistent with the xmit paths
in the same driver.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/31e010a106ff6cd8ccac4bfee547fd3fa1015574
- https://git.kernel.org/stable/c/35a115a204be08f97450b0389413e218268ef4a2
- https://git.kernel.org/stable/c/51eef9c072aa3405a6823a96ae666d38a3b48750
- https://git.kernel.org/stable/c/55193df8d6d33318435f19572bf5ea47a22eee28
- https://git.kernel.org/stable/c/638905520fc4fae6a80991563f264131545ba3df
- https://git.kernel.org/stable/c/74a02921c48fcd35a7881956c9e5c52b86595f5d
- https://git.kernel.org/stable/c/a0f4e4e8e0f5e24ddd83e3d1221732621cf34636
- https://git.kernel.org/stable/c/aa6c6d9ee064aabfede4402fd1283424e649ca19
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - fix a memory leak in cc_mac_digest() Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/02c64052fad03699b9c6d1df2f9b444d17e4ac50
- https://git.kernel.org/stable/c/22f1dd4ca3bfe77db52cc7df3cc353dc114aab8b
- https://git.kernel.org/stable/c/3061c9bfb3f5b3522ab174e2fa7473b24422d1c6
- https://git.kernel.org/stable/c/502440c235fe34cee02b24d7f893841f7565b3bc
- https://git.kernel.org/stable/c/7c21d58fcd6ad8e15a539347254093c93224a8b2
- https://git.kernel.org/stable/c/7cd17993adb8a5d14a7e84d751316a5fdf0c251f
- https://git.kernel.org/stable/c/910f335786a0a0f0b46c3c8c19a13d25cb4454b6
- https://git.kernel.org/stable/c/f53458c7c756b3e0838d51cf1e9f41b25079801a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2 After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/03bee264f8ebfd39e0254c98e112d033a7aa9055
- https://git.kernel.org/stable/c/0c1f74d8b74d8a31751fb6ea5417e48e02c93b58
- https://git.kernel.org/stable/c/1709418535a8df95532999d61b03d59975280258
- https://git.kernel.org/stable/c/2f950eeb27af6885416232761700b8820cae0a61
- https://git.kernel.org/stable/c/497f6af9679fc9c6ce2f438e11ed5d51b1aa8297
- https://git.kernel.org/stable/c/4b44aa1a134e499c4517597118378b308602a16c
- https://git.kernel.org/stable/c/e0377e52f3c10ee572732d11b04625b7f517a862
- https://git.kernel.org/stable/c/e39a77a9b1e17d2d831c304eafac4c41a784a0be
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response. Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0422e7a4883f25101903f3e8105c0808aa5f4ce9
- https://git.kernel.org/stable/c/76cb9a2d252274adfae6e293a292434631a7d472
- https://git.kernel.org/stable/c/7b89868305052b94a91b708c462bc2281fa42a4a
- https://git.kernel.org/stable/c/d61482be4aae1835b78875761206241835a7510e
- https://git.kernel.org/stable/c/f55b383070170e988e4dec28be2af1714d258521
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: of: unittest: fix use-after-free in testdrv_probe() The function testdrv_probe() retrieves the device_node from the PCI device, applies an overlay, and then immediately calls of_node_put(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to of_platform_default_populate(), leading to a use-after-free. The reference to pdev->dev.of_node is owned by the device model and should not be released by the driver. Remove the erroneous of_node_put() to prevent premature freeing.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/07fd339b2c253205794bea5d9b4b7548a4546c56
- https://git.kernel.org/stable/c/0ba03e06f037df704d9b032e36d417633e2326bc
- https://git.kernel.org/stable/c/5b6122a67a295f8a08b7c18d908a1bd974dfaec8
- https://git.kernel.org/stable/c/6b2023286d2c6ed3bf964fb92e34c9c14d42eb69
- https://git.kernel.org/stable/c/d68347b07b9801791c9eaab8f772770b52b8cd5c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/058b451b1039f056d1362c4fec2229e522366ab0
- https://git.kernel.org/stable/c/08841b06fa64d8edbd1a21ca6e613420c90cc4b8
- https://git.kernel.org/stable/c/08fa5d818e5bf53c7ca234d88ba334f32004e9b6
- https://git.kernel.org/stable/c/68013a9bd4c01acd42073715f00e1a1992f089ee
- https://git.kernel.org/stable/c/ad3c0c4400686f6f37b382aaa48fac2b9aefccbe
- https://git.kernel.org/stable/c/b5597bb83fc37b5b5da74a4453fa920b932cf39a
- https://git.kernel.org/stable/c/e8474cfbac9ada2cdaa4eaedec22aadfa0f58559
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add spectre boundry for syscall dispatch table The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/07040904ad217545be096d4280ed33c02f6a3750
- https://git.kernel.org/stable/c/0c965d2784fbbd7f8e3b96d875c9cfdf7c00da3d
- https://git.kernel.org/stable/c/108f2cd13577a410c0ad6ea00708596d9d0dfc90
- https://git.kernel.org/stable/c/85cbf7fb568af5358aae61925c4e66b8f5e1439d
- https://git.kernel.org/stable/c/bc84a109c2082dd0c4b38e8d923c046b41977533
- https://git.kernel.org/stable/c/c8a8e863928424046b8fd328f02c359baa0a0c3f
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix OOB reads in command_file_write due to missing size checks The command_file_write() handler allocates a kernel buffer of exactly count bytes and copies user data into it, but does not validate the buffer against the dot command protocol before passing it to get_dot_command_size() and get_dot_command_timeout(). Since both the allocation size (count) and the header fields (command_size, data_size) are independently user-controlled, an attacker can cause get_dot_command_size() to return a value exceeding the allocation, triggering OOB reads in get_dot_command_timeout() and an out-of-bounds memcpy_toio() that leaks kernel heap memory to the service processor. Fix with two guards: reject writes smaller than sizeof(struct dot_command_header) before allocation, then after copying user data reject commands where the buffer is smaller than the total size declared by the header (sizeof(header) + command_size + data_size). This ensures all subsequent header and payload field accesses stay within the buffer.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0eb09f737428e482a32a2e31e5e223f2b35a71d3
- https://git.kernel.org/stable/c/44ee19422aa82a6847594866de7e5a31e4ef98b3
- https://git.kernel.org/stable/c/7b8a574da5d7ea99b943f7a3458a17a1d95e8838
- https://git.kernel.org/stable/c/a672682d39dd34e2b5ba4feb436723bed65125ff
- https://git.kernel.org/stable/c/aefc1a97da17d8309974690c8a03e439a91ebb1c
- https://git.kernel.org/stable/c/d0fb4d1dc43f8d5179917a2daaa82680993d4cdf
- https://git.kernel.org/stable/c/d50e2019c9d7c433f56d9dff65703eb904aa1fb1
- https://git.kernel.org/stable/c/ee5737891464030a189837467df3b81a273718ad
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: spi: imx: fix use-after-free on unbind The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed). Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/132e47030b0b5e398e0da6c59df5a5dae9b52cff
- https://git.kernel.org/stable/c/1c78c2002380a1fe31bfb01a3d5f29809e55a096
- https://git.kernel.org/stable/c/385a330083f8dd47c15b02e9a83aef9234a37003
- https://git.kernel.org/stable/c/aa9025a498036b6012769f7af36d421385386c17
- https://git.kernel.org/stable/c/c7c40c3e7b9fb900504aa746de3e53c5275b24bd
- https://git.kernel.org/stable/c/f99165ef067723221472ce1aff632bc74f562643
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: sd: fix missing put_disk() when device_add(&disk_dev) fails If device_add(&sdkp->disk_dev) fails, put_device() runs scsi_disk_release(), which frees the scsi_disk but leaves the gendisk referenced. The device_add_disk() error path in sd_probe() calls put_disk(gd); call put_disk(gd) here to mirror that cleanup.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/13e550fbfccdb311e76ec96892dfe35f0dba0657
- https://git.kernel.org/stable/c/1e111c4b3a726df1254670a5cc4868cedb946d37
- https://git.kernel.org/stable/c/262152ec37101f9dc524743ccdbd6c7641d14573
- https://git.kernel.org/stable/c/2c2c14b7dfccad8c5a28802849e40c21252e4c28
- https://git.kernel.org/stable/c/a95d38c5701431bfc826e7b18acc0785919d5c88
- https://git.kernel.org/stable/c/b64b4f499801b12d0e2785447e4df6c164c608a9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix potential UAF after skb_unshare() failure If skb_unshare() fails to unshare a packet due to allocation failure in rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread()) will be NULL'd out. This will likely cause the call to trace_rxrpc_rx_done() to oops. Fix this by moving the unsharing down to where rxrpc_input_call_event() calls rxrpc_input_call_packet(). There are a number of places prior to that where we ignore DATA packets for a variety of reasons (such as the call already being complete) for which an unshare is then avoided. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1f2740150f904bfa60e4bad74d65add3ccb5e7f8
- https://git.kernel.org/stable/c/8fde6296c4d4da2be7ab761305ab7f232b94eefd
- https://git.kernel.org/stable/c/996b0487b3cdda4c91811dbb1c9564626bc840bd
- https://git.kernel.org/stable/c/bf20f46d94f1db38e6ffc0ca204a5fe0de01b495
- https://git.kernel.org/stable/c/e3bf143b1e98fb3d6d9e6825bcd683974d478e8c
- https://access.redhat.com/errata/RHSA-2026:34911
- https://access.redhat.com/security/cve/CVE-2026-45998
- https://bugzilla.redhat.com/show_bug.cgi?id=2482024
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45998.json
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: "outpages - inpages" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/118ff71ff09ebaf323a09af9e911517321a299f4
- https://git.kernel.org/stable/c/21e161de2dc660b1bb70ef5b156ab8e6e1cca3ab
- https://git.kernel.org/stable/c/43a878639b90e9721ffa5eb616a7e6d8454adef3
- https://git.kernel.org/stable/c/778acd52e9497806fbd2cea7f770c41d6850fc48
- https://git.kernel.org/stable/c/bbbbb3f0d7864238a8da2a94cd6ec013fee06a2e
- https://git.kernel.org/stable/c/c9ce18e6bb2c467ec85756dc7989b547b7584fee
- https://git.kernel.org/stable/c/f1374fa6e57fd836623668d782ded9244cfd2938
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix conn-level packet handling to unshare RESPONSE packets The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/24481a7f573305706054c59e275371f8d0fe919f
- https://git.kernel.org/stable/c/98a2046d155f73f6cf5d2c493c5e09b4963e2e12
- https://git.kernel.org/stable/c/c0428a22daf69714dc042b67ea759956b74c74e5
- https://git.kernel.org/stable/c/ca71ac2de389b01eecdc48bfafbdf073ec232044
- https://git.kernel.org/stable/c/d9b93a0f57ca5f6831bfaa34014b6cd705564a00
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: hwmon: (pt5161l) Fix bugs in pt5161l_read_block_data() Fix two bugs in pt5161l_read_block_data(): 1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2c_smbus_read_block_data() can return up to I2C_SMBUS_BLOCK_MAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2C_SMBUS_BLOCK_MAX. 2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2c_smbus_read_block_data() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()
ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is
zero or i_dtime is set, treating them as deleted. However, the case of
i_nlink == 0 with a non-zero mode and zero dtime slips through. Since
ext2 has no orphan list, such a combination can only result from
filesystem corruption - a legitimate inode deletion always sets either
i_dtime or clears i_mode before freeing the inode.
A crafted image can exploit this gap to present such an inode to the
VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via
ext2_unlink(), ext2_rename() and ext2_rmdir():
WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336
CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1
Call Trace:
inode_dec_link_count include/linux/fs.h:2518 [inline]
ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295
vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477
do_unlinkat+0x53e/0x730 fs/namei.c:4541
__x64_sys_unlink+0xc6/0x110 fs/namei.c:4587
do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336
CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1
Call Trace:
inode_dec_link_count include/linux/fs.h:2518 [inline]
ext2_rename+0x35e/0x850 fs/ext2/namei.c:374
vfs_rename+0xf2f/0x2060 fs/namei.c:5021
do_renameat2+0xbe2/0xd50 fs/namei.c:5178
__x64_sys_rename+0x7e/0xa0 fs/namei.c:5223
do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336
CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1
Call Trace:
inode_dec_link_count include/linux/fs.h:2518 [inline]
ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311
vfs_rmdir+0x204/0x690 fs/namei.c:4348
do_rmdir+0x372/0x3e0 fs/namei.c:4407
__x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577
do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Extend the existing i_nlink == 0 check to also catch this case,
reporting the corruption via ext2_error() and returning -EFSCORRUPTED.
This rejects the inode at load time and prevents it from reaching any
of the namei.c paths.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1b80cf48bcf0e1937af9cd6c7beb188762bbf7c5
- https://git.kernel.org/stable/c/25947cc5b2374cd5bf627fe3141496444260d04f
- https://git.kernel.org/stable/c/2dde6377ab2e46bb80cf066c659ef016f3ad7a9b
- https://git.kernel.org/stable/c/32e0b925572686399243834ec99e2a9d85c62eae
- https://git.kernel.org/stable/c/470264bbec499e276a89a6431144ae58f411ea4d
- https://git.kernel.org/stable/c/9e2d67fb2b73eeff8b601e26b332128eae8147bb
- https://git.kernel.org/stable/c/a69a0c5156b6f0092b9fcf44517f5831a962de2d
- https://git.kernel.org/stable/c/d3af04a43db86379df7438bf8bade71685b8a239
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/27d5e84e810b0849d08b9aec68e48570461ce313
- https://git.kernel.org/stable/c/4665a29c08e1b36bc9db4814f9dde3d23e8fd1b0
- https://git.kernel.org/stable/c/4c46413661431aa60fb134cd4ecdf8beaa39f824
- https://git.kernel.org/stable/c/5cf6d5e5e3b804a44692fbf548a5179442e2e923
- https://git.kernel.org/stable/c/8022876894d09ae485b499058c3357da683bcc5d
- https://git.kernel.org/stable/c/823310645065bd49666e84af689fa95192819f55
- https://git.kernel.org/stable/c/b703ee903b24974aca4bde99c7d25d66309d35dd
- https://git.kernel.org/stable/c/ed29887286aba96d1930f4ddb9f235f6b421073c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: Handle probe errors properly The probe procedure of setup_card() in caiaq driver doesn't treat the error cases gracefully, e.g. the error from snd_card_register() calls snd_card_free() but continues. This would lead to a UAF for the further calls like snd_usb_caiaq_control_init(), as Berk suggested in another patch in the link below. However, the problem is not only that; in general, this function drops the all error handlings (as it's a void function) although its caller can propagate an error to snd_probe(), which eventually calls snd_card_free() as a proper error path. That said, we should treat each error case in setup_card(), and just return the error code promptly, which is then handled later as a fatal error in snd_probe(). This patch achieves it by changing the setup_card() to return an error code. Also, the superfluous snd_card_free() call is removed, too. Note that card->private_free can be set still safely at returning an error. All called functions in card_free() have checks of the unassigned resources or NULL checks.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/09616e25f502080ba684fc7fcf959d1376ab756d
- https://git.kernel.org/stable/c/096dd8519cf2f768e9e14f224b627f7aaee1a9c5
- https://git.kernel.org/stable/c/28abd224db4a49560b452115bca3672a20e45b2f
- https://git.kernel.org/stable/c/6251e3e256337a30160ef59ab1580dde4d1acd28
- https://git.kernel.org/stable/c/b956e48371f2ff72b76be9a829800ecec963bd45
- https://git.kernel.org/stable/c/da938aa9fc7826901921dcea225948ab21a97e45
- https://git.kernel.org/stable/c/e59ecd4ee3a450db6cb4e4ecaa3efdd593f80056
- https://git.kernel.org/stable/c/f537e3ad69609f6924a4db6b4a7f6561f5288bdd
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: xfs: fix a resource leak in xfs_alloc_buftarg() In the error path, call fs_put_dax() to drop the DAX device reference.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/28a6c132b8c6e5eeefa889c4fb43d65b12989d48
- https://git.kernel.org/stable/c/29a7b2614357393b176ef06ba5bc3ff5afc8df69
- https://git.kernel.org/stable/c/5804cb507233ed767a83ac70527b2f6c4566ec75
- https://git.kernel.org/stable/c/5c293a1e1ef0f838772d20ae8afae4cbd87cd3f9
- https://git.kernel.org/stable/c/82fb9da6477d08bdab954dc7bc081a41f2f9cae6
- https://git.kernel.org/stable/c/ed2d6442e61169e565727ba15c4f6a0cb5ce16df
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveau_gem_pushbuf_reloc_apply() validates each relocation with if (r->reloc_bo_offset + 4 > nvbo->bo.base.size) but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2fc87d37be1b730a149b035f9375fdb8cc5333a5
- https://git.kernel.org/stable/c/332884f5eb79dd60a7162b079d09d39208567a31
- https://git.kernel.org/stable/c/3429275684f4bad42876955301f3c5c814aae909
- https://git.kernel.org/stable/c/45a45184b9c0b0b26ead06e370cda2073616a7cc
- https://git.kernel.org/stable/c/573a1104bd36e49c067a9dc62e7c476d5ee7e92a
- https://git.kernel.org/stable/c/d749a9a0ee4014681487e7ae549901aa8c176637
- https://git.kernel.org/stable/c/e441d5c23ec644c8d27593db3b8928e8933512a9
- https://git.kernel.org/stable/c/fa297e919d1680c38ab268ff952b1698dac987f6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Avoid cacheline sharing for DMA buffer Depending on the architecture the transfer buffer may share a cacheline with the following mutex. As the buffer may be used for DMA, that is problematic. Use the high-level DMA helpers to make sure that cacheline sharing can not happen. Also drop the comment, as the helpers are documentation enough. https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3446beddba450c8d6f9aca2f028712ac527fead3
- https://git.kernel.org/stable/c/65fc57c8b8f0b31be62be291cb1bb01755cec85d
- https://git.kernel.org/stable/c/72099f015d3c77bf2eb703d1aab113bd7a60915a
- https://git.kernel.org/stable/c/756ca5e7ed22d9045bb4de4c981f9149278d5cd3
- https://git.kernel.org/stable/c/c3029721b84f59e790285ad27544ed5d3cb0f2a6
- https://git.kernel.org/stable/c/c72f6a7ea638f95c486a5cfd86e567b646027687
- https://git.kernel.org/stable/c/e813c95e4c8edd31599081e6356e20ada30e266d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: fix use-after-free in release path due to uncancelled work The mtk_jpeg_release() function frees the context structure (ctx) without first cancelling any pending or running work in ctx->jpeg_work. This creates a race window where the workqueue callback may still be accessing the context memory after it has been freed. Race condition: CPU 0 (release) CPU 1 (workqueue) ---------------- ------------------ close() mtk_jpeg_release() mtk_jpegenc_worker() ctx = work->data // accessing ctx kfree(ctx) // freed! access ctx // UAF! The work is queued via queue_work() during JPEG encode/decode operations (via mtk_jpeg_device_run). If the device is closed while work is pending or running, the work handler will access freed memory. Fix this by calling cancel_work_sync() BEFORE acquiring the mutex. This ordering is critical: if cancel_work_sync() is called after mutex_lock(), and the work handler also tries to acquire the same mutex, it would cause a deadlock. Note: The open error path does NOT need cancel_work_sync() because INIT_WORK() only initializes the work structure - it does not schedule it. Work is only scheduled later during ioctl operations.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0498b27a1542021d90269d58347501d4c3ccd84e
- https://git.kernel.org/stable/c/2209fdae5c2f615930c9af1379c1cfca199ec5d8
- https://git.kernel.org/stable/c/26506a30e0e26d612f82a7bf0e395626968a44e6
- https://git.kernel.org/stable/c/34c519feef3e4fcff1078dc8bdb25fbbbd10303f
- https://git.kernel.org/stable/c/e78c39f720679fcf3a2eacd82725ec3ea2648301
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix memory leaks in rxkad_verify_response() Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/34f61a07e0cdefaecd3ec03bb5fb22215643678f
- https://git.kernel.org/stable/c/852b9d64cea421336579b2de3d1338dfa677e2dd
- https://git.kernel.org/stable/c/861b9a0a1823bf064a7b810d29502a9ef043f40f
- https://git.kernel.org/stable/c/c4b8f32e73eafd4a5076be890c7c8506ec04567c
- https://git.kernel.org/stable/c/c91f33fb8356dedc82bc56ce210f1a5dbee62a52
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/12625b4da84caf4d84a04988710a7b9bcf702b18
- https://git.kernel.org/stable/c/14e9bb6eba8f59dcc637702e4744ae5e30660d76
- https://git.kernel.org/stable/c/3864c6ba1e041bc75342353a70fa2a2c6f909923
- https://git.kernel.org/stable/c/7aa7933a5607b1e5b56f322d17265c1d0ea02c51
- https://git.kernel.org/stable/c/83bb57635d7cbafde32f865b577ecfd969f02337
- https://git.kernel.org/stable/c/ab5fdcd535645f6dbe6e9e21d96a08d141e88b4b
- https://git.kernel.org/stable/c/bebd058ef40c67a81fe6d9ee8beaa4ede90e0704
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: remoteproc: xlnx: Only access buffer information if IPI is buffered In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/06d0bed2552fd0dae27d374d4492a2b672e24eed
- https://git.kernel.org/stable/c/38dd6ccfdfbbe865569a52fe1ba9fa1478f672e6
- https://git.kernel.org/stable/c/5d1451cb2cf6f3d9884d76035a1460aa9bb4b053
- https://git.kernel.org/stable/c/7ddbf21116770b7011f2bb0a6056b7604b24c497
- https://git.kernel.org/stable/c/8242579859a78c801bb626e9aa4823aca93e28e7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: stop parsing UAC2 rates at MAX_NR_RATES parse_uac2_sample_rate_range() caps the number of enumerated rates at MAX_NR_RATES, but it only breaks out of the current rate loop. A malformed UAC2 RANGE response with additional triplets continues parsing the remaining triplets and repeatedly prints "invalid uac2 rates" while probe still holds register_mutex. Stop the whole parse once the cap is reached and return the number of rates collected so far.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0da05fedf5e1966b7e7d389866cb86fcf09f4b32
- https://git.kernel.org/stable/c/3c318f97dcc50b2e0556a1813bd6958678e881fd
- https://git.kernel.org/stable/c/4d7893a137eadb6163ea4298bf67d74b811d76ef
- https://git.kernel.org/stable/c/5436bc1b07d4656f99412dc72871d250d7d55205
- https://git.kernel.org/stable/c/a0b78639ef09b2e77974a3de3b1c07f6de3c5e56
- https://git.kernel.org/stable/c/ab5ba9fd138758ddc50222264ff246b31e397abf
- https://git.kernel.org/stable/c/ba036305323814ec1f8655313b2fa6a0f7048716
- https://git.kernel.org/stable/c/f14bd323eec4b4f0ef662520ec852e593ece1d4c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanup atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/03e00aafa5f747d07811589e8d5fee638245431b
- https://git.kernel.org/stable/c/230ad8a78fe67266b1ba4685da1abdd61471c5b8
- https://git.kernel.org/stable/c/3fcfff4ed35f963380a68741bcd52742baff7f76
- https://git.kernel.org/stable/c/5ad40cde96d603a88d68f8ed59f6d36407ab1f3c
- https://git.kernel.org/stable/c/61516b4a5b2647dc3f8f67b5dffaf038be997511
- https://git.kernel.org/stable/c/65b3589d39d05699c3850202f8333e5361033ea3
- https://git.kernel.org/stable/c/b63f1e2f0e319ad3fe4a58eb3db4fd50cc98baca
- https://git.kernel.org/stable/c/de6952e0af2acbada900d742437e848285c01d11
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/37a430a2d4e66ec8238da6c7f7e48809bf265e13
- https://git.kernel.org/stable/c/41ff66baf81c6541f4f985dd7eac4494d03d9440
- https://git.kernel.org/stable/c/64d4ebf91d082034bbc5ae3ba2d7fd800bc02d06
- https://git.kernel.org/stable/c/75f8f3c3e09122270986de9d7aa347d701676761
- https://git.kernel.org/stable/c/8e563d8db50f303171aceb79eec0807e7ba06951
- https://git.kernel.org/stable/c/a172fa18bc370b776ac1510abb0dcb50a7a35fac
- https://git.kernel.org/stable/c/d4eb861adde5ce22e459fbd29366f47bb2167977
- https://git.kernel.org/stable/c/f412e541d25a3dfaf3d53e012ade6ff03cae8a45
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: misc: ibmasm: fix OOB MMIO read in ibmasm_handle_mouse_interrupt() ibmasm_handle_mouse_interrupt() performs an out-of-bounds MMIO read when the queue reader or writer index from hardware exceeds REMOTE_QUEUE_SIZE (60). A compromised service processor can trigger this by writing an out-of-range value to the reader or writer MMIO register before asserting an interrupt. Since writer is re-read from hardware on every loop iteration, it can also be set to an out-of-range value after the loop has already started. The root cause is that get_queue_reader() and get_queue_writer() return raw readl() values that are passed directly into get_queue_entry(), which computes: queue_begin + reader * sizeof(struct remote_input) with no bounds check. This unchecked MMIO address is then passed to memcpy_fromio(), reading 8 bytes from unintended device registers. For sufficiently large values the address falls outside the PCI BAR mapping entirely, triggering a machine check exception. Fix by checking both indices against REMOTE_QUEUE_SIZE at the top of the loop body, before any call to get_queue_entry(). On an out-of-range value, reset the reader register to 0 via set_queue_reader() before breaking, so that normal queue operation can resume if the corrupted hardware state is transient.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/07c4f18b303106e6b24492c12b95d48a4b985841
- https://git.kernel.org/stable/c/1ca75f6b74ec7f685464e5745ecfcf3a76d284e9
- https://git.kernel.org/stable/c/22a16d3eafee92a165c756081587c95850127107
- https://git.kernel.org/stable/c/4b6e6ead556734bdc14024c5f837132b1e7a4b84
- https://git.kernel.org/stable/c/6f6ecc9153df176e956d0664b56f93080b0a45f0
- https://git.kernel.org/stable/c/bac8643486f854dd53af9b23aea7dbbd9b7c1865
- https://git.kernel.org/stable/c/f7e5b4eefd7be3e09f8bd5fee63ed478fd7446ab
- https://git.kernel.org/stable/c/fc7e9a74e32299d7e93e178ca482a0b59ef1595b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in create_dirty_log() The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed. The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array. Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/17a08791d428885d00e510864283a7b839792368
- https://git.kernel.org/stable/c/249c831183fb806c8e3b14c7c4c1d2fb68cf37fb
- https://git.kernel.org/stable/c/35f6b3281efd44d19110574663bc17a610bc73b9
- https://git.kernel.org/stable/c/47dad9eea75d33212d3d2cea10e7ed6a1bfc0713
- https://git.kernel.org/stable/c/4c788c6f921b22f9b6c3f316c4a071c05683e7de
- https://git.kernel.org/stable/c/87c99a50e0fdc68a5b9b52a94d49452cd3ff02ca
- https://git.kernel.org/stable/c/ae59b3025609d5a0a39cf5b2b94e2467f6231573
- https://git.kernel.org/stable/c/e5e0ae3237584ebef510366c4cb3d5cc7c22b610
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: libceph: Prevent potential null-ptr-deref in ceph_handle_auth_reply() If a message of type CEPH_MSG_AUTH_REPLY contains a zero value for both protocol and result, this is currently not treated as an error. In case of ac->negotiating == true and ac->protocol > 0, this leads to setting ac->protocol = 0 and ac->ops = NULL. Thereafter, the check for ac->protocol != protocol returns false, and init_protocol() is not called. Subsequently, ac->ops->handle_reply() is called, which leads to a null pointer dereference, because ac->ops is still NULL. This patch changes the check for ac->protocol != protocol to !ac->protocol, as this also includes the case when the protocol was set to zero in the message. This causes the message to be treated as containing a bad auth protocol.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/016bc663657366d386993f63eb31072eb45a2b77
- https://git.kernel.org/stable/c/4b2738b93edad661178340239de657d876b73d3d
- https://git.kernel.org/stable/c/5199c125d25aeae8615c4fc31652cc0fe624338e
- https://git.kernel.org/stable/c/8f2be7285941a33a9f72579a23b96392f83c758e
- https://git.kernel.org/stable/c/927e4bd5692f2a4901808822981fb2c8d4456548
- https://git.kernel.org/stable/c/9ded62c302c0342efdb5eda3bf6e75720caad0df
- https://git.kernel.org/stable/c/f101271fcf55d7eacfefd610b51ec65f46ba8118
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0dbec101a7076e9b1e4bd1876f7cf07c56ff4ce3
- https://git.kernel.org/stable/c/20855cef7e659ef84ac73251256fa530819b2346
- https://git.kernel.org/stable/c/2b930bc77e00cb27e1d6e1d497b3b596283465ef
- https://git.kernel.org/stable/c/5640227d9a21c6a8be249a10677b832e7f40dc55
- https://git.kernel.org/stable/c/6e3675251fcea06caecc61eb76462467558adfa6
- https://git.kernel.org/stable/c/76adf8f69b0bb3ab20be7c58f5d555027332d113
- https://git.kernel.org/stable/c/91cb30b6bb1880ba0748ca059bef50b8ac13793d
- https://git.kernel.org/stable/c/bd69e0e8a7643ba5385f19f479e8e3da71f8d495
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid early lgr access in smc_clc_wait_msg A CLC decline can be received while the handshake is still in an early stage, before the connection has been associated with a link group. The decline handling in smc_clc_wait_msg() updates link-group level sync state for first-contact declines, but that state only exists after link group setup has completed. Guard the link-group update accordingly and keep the per-socket peer diagnosis handling unchanged. This preserves the existing sync_err handling for established link-group contexts and avoids touching link-group state before it is available.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/22546729b96fc873b23065dc49e3d73c45cfb874
- https://git.kernel.org/stable/c/257cdf0c5ced9c0fba8aba501d94b0a5fcef2086
- https://git.kernel.org/stable/c/5a8db80f721deee8e916c2cfdee78decda02ce4f
- https://git.kernel.org/stable/c/5eedbfd82c2884e0010fdfb3c9446a6ebcadb691
- https://git.kernel.org/stable/c/6180a296ca65b08a81914805cbc0f78da5f10a1f
- https://git.kernel.org/stable/c/83bcf9228b0501694fb2589ed1d142855a2887f2
- https://git.kernel.org/stable/c/ea0b5d0fe96356dce38f98375a57c52a04e13712
- https://git.kernel.org/stable/c/f0858e1d5624bb120b198f2a8528f97a9b0ae069
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Reinstate disabling of BHs around IRQ handler If the driver executes ks8851_irq() AND a TX packet has been sent, then the driver enables TX queue via netif_wake_queue() which schedules TX softirq to queue packets for this device. If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to allocate SKBs for the received packets. If netdev_alloc_skb_ip_align() is called with BH enabled, then local_bh_enable() at the end of netdev_alloc_skb_ip_align() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851_start_xmit_par(). The ks8851_start_xmit_par() will try to lock struct ks8851_net_par .lock spinlock, which is already locked by ks8851_irq() from which ks8851_start_xmit_par() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below. If CONFIG_PREEMPT_RT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spin_unlock_bh(&ks->statelock) in ks8851_irq(), which triggers the deadlock as well. Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the net_tx_action() softirq from triggering during these critical sections. The net_tx_action() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed. __schedule from schedule_rtlock+0x1c/0x34 schedule_rtlock from rtlock_slowlock_locked+0x548/0x904 rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8 ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44 netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188 dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c sch_direct_xmit from __qdisc_run+0x1f8/0x4ec __qdisc_run from qdisc_run+0x1c/0x28 qdisc_run from net_tx_action+0x1f0/0x268 net_tx_action from handle_softirqs+0x1a4/0x270 handle_softirqs from __local_bh_enable_ip+0xcc/0xe0 __local_bh_enable_ip from __alloc_skb+0xd8/0x128 __alloc_skb from __netdev_alloc_skb+0x3c/0x19c __netdev_alloc_skb from ks8851_irq+0x388/0x4d4 ks8851_irq from irq_thread_fn+0x24/0x64 irq_thread_fn from irq_thread+0x178/0x28c irq_thread from kthread+0x12c/0x138 kthread from ret_from_fork+0x14/0x28
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1962027a6d223f90df8b372929f9d1a8d321ad6a
- https://git.kernel.org/stable/c/21f1707a8e978558dcb11b053855521e32ac0eec
- https://git.kernel.org/stable/c/518040324067d8efaa2da1992297b7e7bf5640f4
- https://git.kernel.org/stable/c/5c9fcac3c872224316714d0d8914d9af16c76a6d
- https://git.kernel.org/stable/c/640a7631d31db87d5fa1b34cea44a99b6e78854b
- https://git.kernel.org/stable/c/be8aad558b4675f45b43080f81a9ffdeddea73a5
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/2f31cd1e64a079c845bca31d2da7b3c90a311726
- https://git.kernel.org/stable/c/5db6ef9847717329f12c5ea8aba7e9f588a980c0
- https://git.kernel.org/stable/c/67f1f0933cc3d78dde222842bcad2778ec7a0b88
- https://git.kernel.org/stable/c/77f59fb2d3aa33e90ec6cbbf45dcfb20ab82b1a9
- https://git.kernel.org/stable/c/9aff81e8217e9de2929084b03b3c7f81988c112b
- https://git.kernel.org/stable/c/b42821c15445f93daea3e76ada682b2b7181c476
- https://git.kernel.org/stable/c/b69933e97efea238ebbfcf70c2b1be1cd03f13e3
- https://git.kernel.org/stable/c/d4c6a6d08e70bb1083c7c405fc7faacbf19aebc0
- https://access.redhat.com/security/cve/CVE-2026-46033
- https://bugzilla.redhat.com/show_bug.cgi?id=2482000
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46033.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: vfio/cdx: Fix NULL pointer dereference in interrupt trigger path Add validation to ensure MSI is configured before accessing cdx_irqs array in vfio_cdx_set_msi_trigger(). Without this check, userspace can trigger a NULL pointer dereference by calling VFIO_DEVICE_SET_IRQS with VFIO_IRQ_SET_DATA_BOOL or VFIO_IRQ_SET_DATA_NONE flags before ever setting up interrupts via VFIO_IRQ_SET_DATA_EVENTFD. The vfio_cdx_msi_enable() function allocates the cdx_irqs array and sets config_msi to 1 only when called through the EVENTFD path. The trigger loop (for DATA_BOOL/DATA_NONE) assumed this had already been done, but there was no enforcement of this call ordering. This matches the protection used in the PCI VFIO driver where vfio_pci_set_msi_trigger() checks irq_is() before the trigger loop.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: vfio/cdx: Serialize VFIO_DEVICE_SET_IRQS with a per-device mutex vfio_cdx_set_msi_trigger() reads vdev->config_msi and operates on the vdev->cdx_irqs array based on its value, but provides no serialization against concurrent VFIO_DEVICE_SET_IRQS ioctls. Two callers can race such that one observes config_msi as set while another clears it and frees cdx_irqs via vfio_cdx_msi_disable(), resulting in a use-after-free of the cdx_irqs array. Add a cdx_irqs_lock mutex to struct vfio_cdx_device and acquire it in vfio_cdx_set_msi_trigger(), which is the single chokepoint through which all updates to config_msi, cdx_irqs, and msi_count flow, covering both the ioctl path and the close-device cleanup path. This keeps the test of config_msi atomic with the subsequent enable, disable, or trigger operations. Drop the pre-call !cdx_irqs test from vfio_cdx_irqs_cleanup() as part of this change: the optimization it provided is redundant with the !config_msi early-return inside vfio_cdx_msi_disable(), and leaving the test in place would be an unsynchronized read of state the new lock is meant to protect.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH8.2
In the Linux kernel, the following vulnerability has been resolved: ipv4: icmp: validate reply type before using icmp_pointers Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type. That value is outside the range covered by icmp_pointers[], which only describes the traditional ICMP types up to NR_ICMP_TYPES. Avoid consulting icmp_pointers[] for reply types outside that range, and use array_index_nospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.
CVSS 3.xHIGH 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:HReferences
- https://git.kernel.org/stable/c/67bf002a2d7387a6312138210d0bd06e3cf4879b
- https://git.kernel.org/stable/c/92e7c209036dcc0e8ffdf806fdfd3645b263bea5
- https://git.kernel.org/stable/c/93df2af4f491de33827550b9d420f01808c0706b
- https://git.kernel.org/stable/c/b3a88fc5ae024d43c5ecf653f3bbe837e4a6dc99
- https://git.kernel.org/stable/c/bc64a66e0b9ad937d3d49934242ee62b01ba9a94
- https://git.kernel.org/stable/c/c2178ff1c70ebfc2ab9651b230c58a34683db759
- https://git.kernel.org/stable/c/d700c34a5d186b9ba0715bcb19e0ff80ffbfbfc1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/076e4b162d6caba12c229e7f262df5b6881162b0
- https://git.kernel.org/stable/c/154fc7fe3f62c46891c3c4302f4b5b5391c932e6
- https://git.kernel.org/stable/c/25d580a46b079a7963ff024a5195e547baf12b64
- https://git.kernel.org/stable/c/65932f5102bb5377db36c8a4f0c28179a1967a9a
- https://git.kernel.org/stable/c/68efba36446a7774ea5b971257ade049272a07ac
- https://git.kernel.org/stable/c/6c9cca46acb6f22e63f015ea7b2ed6032d2badf5
- https://git.kernel.org/stable/c/a5a454f3364877b22f0e5a165df8b3702ff96ae7
- https://git.kernel.org/stable/c/ff78ed177a66763085e3214d6fbe13ca8f0b3f11
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: inotify: fix watch count leak when fsnotify_add_inode_mark_locked() fails When fsnotify_add_inode_mark_locked() fails in inotify_new_watch(), the error path calls inotify_remove_from_idr() but does not call dec_inotify_watches() to undo the preceding inc_inotify_watches(). This leaks a watch count, and repeated failures can exhaust the max_user_watches limit with -ENOSPC even when no watches are active. Prior to commit 1cce1eea0aff ("inotify: Convert to using per-namespace limits"), the watch count was incremented after fsnotify_add_mark_locked() succeeded, so this path was not affected. The conversion moved inc_inotify_watches() before the mark insertion without adding the corresponding rollback. Add the missing dec_inotify_watches() call in the error path.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/10edf7e0ffdc7faa18e2244b17722c1b882b8273
- https://git.kernel.org/stable/c/3ab58cf42c46bf2366d2f55ae5c59299d5e178b7
- https://git.kernel.org/stable/c/3ad9ccea1b25435f6179b57aa891960beb7ce8f9
- https://git.kernel.org/stable/c/6a320935fa4293e9e599ec9f85dc9eb3be7029f8
- https://git.kernel.org/stable/c/73ddc8518a32baff6bc17afda4ee1ebae5b4ed12
- https://git.kernel.org/stable/c/8bcc1cd237ab5ccfdd102869fa031c541943cf40
- https://git.kernel.org/stable/c/9e48844f708eb48bae4e79cb21edc097c966306d
- https://git.kernel.org/stable/c/fdaa42ca370d056428e5e171247c8fdce8dff36a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames() hdlc_append() calls usleep_range() to wait for circular buffer space, but it is called with tx_producer_lock (a spinlock) held via hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc. Sleeping while holding a spinlock is illegal and can trigger "BUG: scheduling while atomic". Fix this by moving the buffer-space wait out of hdlc_append() and into hdlc_tx_frames(), before the spinlock is acquired. The new flow: 1. Pre-calculate the worst-case encoded frame length. 2. Wait (with sleep) outside the lock until enough space is available, kicking the TX consumer work to drain the buffer. 3. Acquire the spinlock, re-verify space, and write the entire frame atomically. This ensures that sleeping only happens without any lock held, and that frames are either fully enqueued or not written at all. This bug is found by CodeQL static analysis tool (interprocedural sleep-in-atomic query) and my code review.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. However, payload_size() subtracts both the attacker-controlled BTH pad field and RXE_ICRC_SIZE from pkt->paylen: payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt) - RXE_ICRC_SIZE This means a short packet can still make payload_size() underflow even if it includes enough bytes for the fixed headers. Simply requiring header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payload_size() negative and pass an underflowed value to later receive-path users. Fix this by validating pkt->paylen against the full minimum length required by payload_size(): header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/2c0d71ef12f46c57d37bc571f3f2797db7eb50cc
- https://git.kernel.org/stable/c/2fd4f8b749309a61c3f3f88ee8891d94f79e1240
- https://git.kernel.org/stable/c/5fedefec757192dcaad29a664ac332c7601be144
- https://git.kernel.org/stable/c/7244491dab347f648e661da96dc0febadd9daec3
- https://git.kernel.org/stable/c/9b924f3a26b21330a837cfe72e819b6393bbeeaa
- https://git.kernel.org/stable/c/c4376c672c3648d5bdc31dfffc329d07164f93c4
- https://git.kernel.org/stable/c/e8ee0e792d475b1067c199ef0af1b6221fa6f43d
- https://git.kernel.org/stable/c/f83519a4c122c9c7a850a2197648a9ff4c67c520
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all() The commit c8e008b60492 ("ext4: ignore xattrs past end") introduced a refcount leak in when block_csum is false. ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to get iloc.bh, but never releases it with brelse().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/097227f1ffe1a85bc3c359f81c71e3d40e06e920
- https://git.kernel.org/stable/c/153ab2c52355fbebcae622db8e7b506492c73a29
- https://git.kernel.org/stable/c/1bc1107a3a403a6d440673ed6666f7b07ef868a8
- https://git.kernel.org/stable/c/1e6b0a69bf2c9c819255c7566e4355536d81d9cf
- https://git.kernel.org/stable/c/77d059519382bd66283e6a4e83ee186e87e7708f
- https://git.kernel.org/stable/c/b706d00206a9e82362a9633efbd8b5775650169b
- https://git.kernel.org/stable/c/dd98a5603a212ea9c96c6982ccdbcc748fdb9a56
- https://git.kernel.org/stable/c/f072906688933bf47fabbaf63560be03357c8298
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove() In the remove callback, if a packet arrives after destroy_workqueue() is called, but before sock_release(), the qrtr_ns_data_ready() callback will try to queue the work, causing use-after-free issue. Fix this issue by saving the default 'sk_data_ready' callback during qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at the start of remove(). This ensures that even if a packet arrives after destroy_workqueue(), the work struct will not be dereferenced. Note that it is also required to ensure that the RX threads are completed before destroying the workqueue, because the threads could be using the qrtr_ns_data_ready() callback.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0f313eb6a8f6dffa491373cf3afab979fa1c02f4
- https://git.kernel.org/stable/c/2e127ceb1c415e246076d8e09e23e443a7a2038f
- https://git.kernel.org/stable/c/4ae0bd51bf7079e9c2a06b5de0ae04ba70d10167
- https://git.kernel.org/stable/c/65168712c216584ff482a7d1a67589f2079b2634
- https://git.kernel.org/stable/c/7809fea20c9404bfcfa6112ec08d1fe1d3520beb
- https://git.kernel.org/stable/c/db3c60ec772de30acae92d560dfcc5258e58dbe8
- https://git.kernel.org/stable/c/dff081c3602f2fd810f69ef47945a226980dd05d
- https://git.kernel.org/stable/c/f96779e916576e81430ebb326baff6e433fef8ae
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix usb_dev refcount leak on probe failure create_card() takes a reference on the USB device with usb_get_dev() and stores the matching usb_put_dev() in card_free(), which is installed as the snd_card's ->private_free destructor. However, ->private_free is only assigned near the end of init_card(), after several failure points (usb_set_interface(), EP type checks, usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its timeout). When any of those fail, init_card() returns an error to snd_probe(), which calls snd_card_free(card). Because ->private_free is still NULL, card_free() never runs, the usb_get_dev() reference is not dropped, and the struct usb_device leaks along with its descriptor allocations and device_private. syzbot reproduces this with a malformed UAC3 device whose only valid altsetting is 0; init_card()'s usb_set_interface(usb_dev, 0, 1) call fails with -EIO and triggers the leak. Move the ->private_free assignment into create_card(), immediately after usb_get_dev(), so that every error path reaching snd_card_free() balances the reference. card_free()'s callees (snd_usb_caiaq_input_free, free_urbs, kfree) already tolerate the partially-initialized state because the chip private area is zero-initialized by snd_card_new().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/21ca595aafa40d3ac70eab1f4cb62cc00ca21657
- https://git.kernel.org/stable/c/50c6a1f05973f56d23280c9d7645a7a5734e0907
- https://git.kernel.org/stable/c/6153878c5255bb69b7d0868105ca078ef13cbcf8
- https://git.kernel.org/stable/c/6fa8dff64fb6c401ced40a05797b327659317498
- https://git.kernel.org/stable/c/7a5f1cd22d47f8ca4b760b6334378ae42c1bd24b
- https://git.kernel.org/stable/c/a8d907acc3e5a078c2e5637ff60c30c6d2ddc23a
- https://git.kernel.org/stable/c/c874db8a1d2f9f08161470d00cfe8db2f5cca2cc
- https://git.kernel.org/stable/c/da3b8fd6a202d94fef11a443abc9171c52426a1c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Add fallback to default RSR for S/PDIF spdif_passthru_playback_get_resources() uses atc->pll_rate as the RSR for the MSR calculation loop. However, pll_rate is only updated in atc_pll_init() and not in hw_pll_init(), so it remains 0 after the card init. When spdif_passthru_playback_setup() skips atc_pll_init() for 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin indefinitely. Add fallback to use atc->rsr when atc->pll_rate is 0. This reflects the hardware state, since hw_card_init() already configures the PLL to the default RSR.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/09496158f6ebba8830593f8972035c02f97124c1
- https://git.kernel.org/stable/c/25ded535ee261161bcf19dafd525c542e606559d
- https://git.kernel.org/stable/c/30f9494c6f2b53a78822cfb653ffbb1d092d44c8
- https://git.kernel.org/stable/c/615b7a5e5d8be68d52f262579906f7e015ba4606
- https://git.kernel.org/stable/c/7d61662197ecdc458e33e475b6ada7f6da61d364
- https://git.kernel.org/stable/c/95b1ee8442cabbde83b2848e7c6100df90f3a00d
- https://git.kernel.org/stable/c/d0b53842211f73a10ea174100a213f7fa14b9f33
- https://git.kernel.org/stable/c/dfc00979ff00d9dfdfa1df32144a272ee2728102
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix deadlock with check operation and nowait requests When an array check is running it will raise the barrier at which point normal requests will become blocked and increment the nr_pending value to signal there is work pending inside of wait_barrier(). NOWAIT requests do not block and so will return immediately with an error, and additionally do not increment nr_pending in wait_barrier(). Upstream change commit 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit this condition. raid_end_bio_io() eventually calls allow_barrier() and it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even though the corresponding increment on nr_pending didn't happen in the NOWAIT case. This can be easily seen by starting a check operation while an application is doing nowait IO on the same array. This results in a deadlocked state due to nr_pending value underflowing and so the md resync thread gets stuck waiting for nr_pending to == 0. Output of r10conf state of the array when we hit this condition: crash> struct r10conf barrier = 1, nr_pending = { counter = -41 }, nr_waiting = 15, nr_queued = 0, Example of md_sync thread stuck waiting on raise_barrier() and other requests stuck in wait_barrier(): md1_resync [<0>] raise_barrier+0xce/0x1c0 [<0>] raid10_sync_request+0x1ca/0x1ed0 [<0>] md_do_sync+0x779/0x1110 [<0>] md_thread+0x90/0x160 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30 kworker/u1040:2+flush-253:4 [<0>] wait_barrier+0x1de/0x220 [<0>] regular_request_wait+0x30/0x180 [<0>] raid10_make_request+0x261/0x1000 [<0>] md_handle_request+0x13b/0x230 [<0>] __submit_bio+0x107/0x1f0 [<0>] submit_bio_noacct_nocheck+0x16f/0x390 [<0>] ext4_io_submit+0x24/0x40 [<0>] ext4_do_writepages+0x254/0xc80 [<0>] ext4_writepages+0x84/0x120 [<0>] do_writepages+0x7a/0x260 [<0>] __writeback_single_inode+0x3d/0x300 [<0>] writeback_sb_inodes+0x1dd/0x470 [<0>] __writeback_inodes_wb+0x4c/0xe0 [<0>] wb_writeback+0x18b/0x2d0 [<0>] wb_workfn+0x2a1/0x400 [<0>] process_one_work+0x149/0x330 [<0>] worker_thread+0x2d2/0x410 [<0>] kthread+0xbe/0xf0 [<0>] ret_from_fork+0x34/0x50 [<0>] ret_from_fork_asm+0x1a/0x30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1cdff2937c618f81058422bbdc4974a3e7ec9379
- https://git.kernel.org/stable/c/2249983d971e6839b36284e6610390b2c217dfa1
- https://git.kernel.org/stable/c/42fe37c90184cd1568838b84b488934c3671c963
- https://git.kernel.org/stable/c/7d96f3120a7fb7210d21b520c5b6f495da6ba436
- https://git.kernel.org/stable/c/965d6162dd88cc7cc193cf7f5bfc132d8bbf0523
- https://git.kernel.org/stable/c/ae356d5eb1331d678985799f893e436314834a87
- https://git.kernel.org/stable/c/cac2106bb9a2180b288079b49ed626414fb5bc45
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix soft lockup in retry_aligned_read() When retry_aligned_read() encounters an overlapped stripe, it releases the stripe via raid5_release_stripe() which puts it on the lockless released_stripes llist. In the next raid5d loop iteration, release_stripe_list() drains the stripe onto handle_list (since STRIPE_HANDLE is set by the original IO), but retry_aligned_read() runs before handle_active_stripes() and removes the stripe from handle_list via find_get_stripe() -> list_del_init(). This prevents handle_stripe() from ever processing the stripe to resolve the overlap, causing an infinite loop and soft lockup. Fix this by using __release_stripe() with temp_inactive_list instead of raid5_release_stripe() in the failure path, so the stripe does not go through the released_stripes llist. This allows raid5d to break out of its loop, and the overlap will be resolved when the stripe is eventually processed by handle_stripe().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/09880592f5a9dc73377d6eb5ac123537b5f8df49
- https://git.kernel.org/stable/c/1985cb3247e87ff6b8ca4bc5f9626f4f51024507
- https://git.kernel.org/stable/c/4166d5234fe8b6c3c7f796a6c198605356c5b355
- https://git.kernel.org/stable/c/66df9f30673db66ac35145820a8e24906069ae57
- https://git.kernel.org/stable/c/7f9f7c697474268d9ef9479df3ddfe7cdcfbbffc
- https://git.kernel.org/stable/c/80fc6ca2cbde018d52e13f305edcd643911bd94b
- https://git.kernel.org/stable/c/883cc33b7af1c448663287f069ef9dfea001e90f
- https://git.kernel.org/stable/c/a9055300e07d9d6800264d3c2560e1d0144689ca
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved:
ceph: only d_add() negative dentries when they are unhashed
Ceph can call d_add(dentry, NULL) on a negative dentry that is already
present in the primary dcache hash.
In the current VFS that is not safe. d_add() goes through __d_add()
to __d_rehash(), which unconditionally reinserts dentry->d_hash into
the hlist_bl bucket. If the dentry is already hashed, reinserting the
same node can corrupt the bucket, including creating a self-loop.
Once that happens, __d_lookup() can spin forever in the hlist_bl walk,
typically looping only on the d_name.hash mismatch check and
eventually triggering RCU stall reports like this one:
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829
rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192)
CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE
Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023
RIP: 0010:__d_lookup+0x46/0xb0
Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f
RSP: 0018:ff745a70c8253898 EFLAGS: 00000282
RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966
RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0
RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89
R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0
R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f
FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0
PKRU: 55555554
Call Trace:
lookup_fast+0x9f/0x100
walk_component+0x1f/0x150
link_path_walk+0x20e/0x3d0
path_lookupat+0x68/0x180
filename_lookup+0xdc/0x1e0
vfs_statx+0x6c/0x140
vfs_fstatat+0x67/0xa0
__do_sys_newfstatat+0x24/0x60
do_syscall_64+0x6a/0x230
entry_SYSCALL_64_after_hwframe+0x76/0x7e
This is reachable with reused cached negative dentries. A Ceph lookup
or atomic_open can be handed a negative dentry that is already hashed,
and fs/ceph/dir.c then hits one of two paths that incorrectly assume
"negative" also means "unhashed":
- ceph_finish_lookup():
MDS reply is -ENOENT with no trace
-> d_add(dentry, NULL)
- ceph_lookup():
local ENOENT fast path for a complete directory with shared caps
-> d_add(dentry, NULL)
Both paths can therefore re-add an already-hashed negative dentry.
Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only
calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)
is true.
Fix both fs/ceph/dir.c sites the same way: only call d_add() for a
negative dentry when it is actually unhashed. If the negative dentry
is already hashed, leave it in place and reuse it as-is.
This preserves the existing behavior for unhashed dentries while
avoiding d_hash list corruption for reused hashed negatives.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2010cb06b9df7d3c816c78358c566bdacbdf38ff
- https://git.kernel.org/stable/c/4147ae08824cc8b65d2b2018f79d416af2937108
- https://git.kernel.org/stable/c/4179cc390dacebc87079419ec92f86f3dc46294d
- https://git.kernel.org/stable/c/73b47a1f06dee5e61b00dee5227d75d3f1f6d977
- https://git.kernel.org/stable/c/79ffcbeac6bc1dc1bcdb0434acf250f6215ec111
- https://git.kernel.org/stable/c/803447f93d75ab6e40c85e6d12b5630d281d70d6
- https://git.kernel.org/stable/c/83ce43a21bb7df8dd52228afdd918d2d058eefde
- https://git.kernel.org/stable/c/b91e535f208c48a5e7464f1aa38338a30e7912df
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: rds: fix MR cleanup on copy error __rds_rdma_map() hands sg/pages ownership to the transport after get_mr() succeeds. If copying the generated cookie back to user space fails after that point, the error path must not free those resources again before dropping the MR reference. Remove the duplicate unpin/free from the put_user() failure branch so that MR teardown is handled only through the existing final cleanup path.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/033370ffb3c9c0264d19f8ba9ef769523266589a
- https://git.kernel.org/stable/c/106dc689206610cfa2098f593fdd1e020c997835
- https://git.kernel.org/stable/c/8141a2dc70080eda1aedc0389ed2db2b292af5bd
- https://git.kernel.org/stable/c/8fdbb6262a4a3ed44a0830a7793903b54bb27bdc
- https://git.kernel.org/stable/c/91a44b406bc1f9e1c5da0cb7d0d5991b43b79147
- https://git.kernel.org/stable/c/b3cb8cae530b2727d8245684148bb49425f6765c
- https://git.kernel.org/stable/c/d95cea9298be1ba8876e3f156be96d3a492085ca
- https://git.kernel.org/stable/c/ec55a86f7fba7d9111df94b9c11a4755ed492995
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/01a6431766c35dfedb86e0cb5d3fc80c6d604a47
- https://git.kernel.org/stable/c/204028af77a265e31ceb4ba7f643349a3cca72b2
- https://git.kernel.org/stable/c/85fa3512048793076eef658f66489112dcc91993
- https://git.kernel.org/stable/c/8c6443bb9257b780986fb67ec08565bf48ecb8d7
- https://git.kernel.org/stable/c/b6ae482f88654db407c8c17619d4b62959b903ef
- https://git.kernel.org/stable/c/d28311539ac9f65e29308ea219ecaa48aa5e76e5
- https://git.kernel.org/stable/c/e08d75753db17aa943d7622f09d9c217b5bfd3b8
- https://git.kernel.org/stable/c/ea18732d2614557e59f4c0d8cdbe6611aeab33b7
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: amphion: Fix race between m2m job_abort and device_run Fix kernel panic caused by race condition where v4l2_m2m_ctx_release() frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run with the same context. Race sequence: v4l2_m2m_try_run(): v4l2_m2m_ctx_release(): lock/unlock v4l2_m2m_cancel_job() job_abort() v4l2_m2m_job_finish() kfree(m2m_ctx) <- frees ctx device_run() <- use-after-free crash at 0x538 Crash trace: Unable to handle kernel read from unreadable memory at virtual address 0000000000000538 v4l2_m2m_try_run+0x78/0x138 v4l2_m2m_device_run_work+0x14/0x20 The amphion vpu driver does not rely on the m2m framework's device_run callback to perform encode/decode operations. Fix the race by preventing m2m framework job scheduling entirely: - Add job_ready callback returning 0 (no jobs ready for m2m framework) - Remove job_abort callback to avoid the race condition
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/42dc622776f3ce1a6c31b13bdc686f7295e3b323
- https://git.kernel.org/stable/c/516467052fdfc6a13eadc70d43420ae57436bf3c
- https://git.kernel.org/stable/c/6be2cb75bc1300080cfc8051579f22efae9401f7
- https://git.kernel.org/stable/c/8cd35ceadcfc8c5da2eb7f7ce24525ce9d4ee62e
- https://git.kernel.org/stable/c/da4f46c5cf1d26e6b09418ad453e152f2e75a02c
- https://git.kernel.org/stable/c/fdc150dac1adb9a98be9d6956cff0348838b024a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: jbd2: fix deadlock in jbd2_journal_cancel_revoke() Commit f76d4c28a46a ("fs/jbd2: use sleeping version of __find_get_block()") changed jbd2_journal_cancel_revoke() to use __find_get_block_nonatomic() which holds the folio lock instead of i_private_lock. This breaks the lock ordering (folio -> buffer) and causes an ABBA deadlock when the filesystem blocksize < pagesize: T1 T2 ext4_mkdir() ext4_init_new_dir() ext4_append() ext4_getblk() lock_buffer() <- A sync_blockdev() blkdev_writepages() writeback_iter() writeback_get_folio() folio_lock() <- B ext4_journal_get_create_access() jbd2_journal_cancel_revoke() __find_get_block_nonatomic() folio_lock() <- B block_write_full_folio() lock_buffer() <- A This can occasionally cause generic/013 to hang. Fix by only calling __find_get_block_nonatomic() when the passed buffer_head doesn't belong to the bdev, which is the only case that we need to look up its bdev alias. Otherwise, the lookup is redundant since the found buffer_head is equal to the one we passed in.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix integer overflow in run_unpack() volume boundary check The volume boundary check `lcn + len > sbi->used.bitmap.nbits` uses raw addition which can wrap around for large lcn and len values, bypassing the validation. Use check_add_overflow() as is already done for the adjacent prev_lcn + dlcn and vcn64 + len checks added by commit 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()"). Found by fuzzing with a source-patched harness (LibAFL + QEMU).
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/424858f9a048057bb8f834bfe03d18f5e477e747
- https://git.kernel.org/stable/c/60dab3e2931f3d792438a77a6cb0cb731c43300b
- https://git.kernel.org/stable/c/6175d09c23bec4b60860ee9a0170308ff4b56e10
- https://git.kernel.org/stable/c/984a415f019536ea2d24de9010744e5302a9a948
- https://git.kernel.org/stable/c/a954061b334ec67c79ae9d0cadd83fa521396487
- https://git.kernel.org/stable/c/e73cd5aed6b15e55c1c47577bdb473b5e88d6a69
- https://git.kernel.org/stable/c/f1af27cec07a9fd0847166bdb23c99e86b05bfdc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: x86/shstk: Prevent deadlock during shstk sigreturn During sigreturn the shadow stack signal frame is popped. The kernel does this by reading the shadow stack using normal read accesses. When it can't assume the memory is shadow stack, it takes extra steps to makes sure it is reading actual shadow stack memory and not other normal readable memory. It does this by holding the mmap read lock while doing the access and checking the flags of the VMA. Unfortunately that is not safe. If the read of the shadow stack sigframe hits a page fault, the fault handler will try to recursively grab another mmap read lock. This normally works ok, but if a writer on another CPU is also waiting, the second read lock could fail and cause a deadlock. Fix this by not holding mmap lock during the read access to userspace. Instead use mmap_lock_speculate_...() to watch for changes between dropping mmap lock and the userspace access. Retry if anything grabbed an mmap write lock in between and could have changed the VMA. These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP kernels. So drop support for the other configs under the assumption that the !SMP shadow stack user base does not exist. Currently there is a check that skips the lookup work when the SSP can be assumed to be on a shadow stack. While reorganizing the function, remove the optimization to make the tricky code flows more common, such that issues like this cannot escape detection for so long.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3d29db827502067626062f5c74dd502d14ab15bc
- https://git.kernel.org/stable/c/4f3374c990fb2adec06d20fd6d780927811c9aa0
- https://git.kernel.org/stable/c/9874b2917b9fbc30956fee209d3c4aa47201c64e
- https://git.kernel.org/stable/c/d042d69b417515959e49021fef008c9b04a99bd5
- https://git.kernel.org/stable/c/e2c2b044458cbf22da05264fa707308e8d4f86f9
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ibmasm: fix heap over-read in ibmasm_send_i2o_message() The ibmasm_send_i2o_message() function uses get_dot_command_size() to compute the byte count for memcpy_toio(), but this value is derived from user-controlled fields in the dot_command_header (command_size: u8, data_size: u16) and is never validated against the actual allocation size. A root user can write a small buffer with inflated header fields, causing memcpy_toio() to read up to ~65 KB past the end of the allocation into adjacent kernel heap, which is then forwarded to the service processor over MMIO. Silently clamping the copy size is not sufficient: if the header fields claim a larger size than the buffer, the SP receives a dot command whose own header is inconsistent with the I2O message length, which can cause the SP to desynchronize. Reject such commands outright by returning failure. Validate command_size before calling get_mfa_inbound() to avoid leaking an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware frame from the controller's free pool, and returning without a corresponding set_mfa_inbound() call would permanently exhaust it. Additionally, clamp command_size to I2O_COMMAND_SIZE before the memcpy_toio() so the MMIO write stays within the I2O message frame, consistent with the clamping already performed by outgoing_message_size() for the header field.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/9aad71144fa3682cca3837a06c8623016790e7ec
- https://git.kernel.org/stable/c/9e8f6c9d4ecddda2f28baa1678340286cff3969c
- https://git.kernel.org/stable/c/b870f652877bfbe321bd0f4096fc37a93296f7b6
- https://git.kernel.org/stable/c/c1c2417c60dbdca5ebb00462f21ee71c2d7f7083
- https://git.kernel.org/stable/c/ca1c857e2bb74a9fc0606128334f85316d57067b
- https://git.kernel.org/stable/c/ce57fa439bd1b5d664f334a0c3e3f0e42abb0153
- https://git.kernel.org/stable/c/fd19eb1c75047a4ed4e855f56cafd704dc3914e0
- https://git.kernel.org/stable/c/fe31722b0194ff76bf8b461e8bf97a2081147787
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/25c2b77bc463f29ee71a54b883548baf9386a0db
- https://git.kernel.org/stable/c/2a40f8bc9bb713329f1c35ffc199ee961a7135b0
- https://git.kernel.org/stable/c/2b53d3a52e8e5403a4f4fb57ac6cad3fd2cb1066
- https://git.kernel.org/stable/c/4aab89603b637a2e441b38808c4f6fe7d1184df6
- https://git.kernel.org/stable/c/4fda0d6b45faad44926dd3e4f55f118d899b2e27
- https://git.kernel.org/stable/c/9ded47ad003f09a94b6a710b5c47f4aa5ceb7429
- https://git.kernel.org/stable/c/a0aafb421dd15e935d81543152617f2742cefa70
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx The bounce buffers are allocated with __get_free_pages() using BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error path and nx842_crypto_free_ctx() release the buffers with free_page(). Use free_pages() with the matching order instead.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/5c07962fed66e1238fad7635fa150570bd38b4c5
- https://git.kernel.org/stable/c/80fd99d7c30ea889662d21f1b44d8fea4c83138d
- https://git.kernel.org/stable/c/910bb34b801d39794e656f7d48414844b2bd354e
- https://git.kernel.org/stable/c/adb3faf2db1a66d0f015b44ac909a32dfc7f2f9c
- https://git.kernel.org/stable/c/f17a4850d1ce7c11cba8b1830b9bfedfede878bb
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/030abbae49cf9fd1fba7aa08e15ec81efbeb78cf
- https://git.kernel.org/stable/c/11869ce402d95519d49b25a2a97741f68d69d103
- https://git.kernel.org/stable/c/1958a92599b2653d730ccb6f5685fc3fbed21812
- https://git.kernel.org/stable/c/4e179a60a60c0a5aea245e8e67768343c0f070b8
- https://git.kernel.org/stable/c/63fe3389b3e092d6c0eeea9fc0318e7918b16618
- https://git.kernel.org/stable/c/a88f5391dc68f78cae5eb6a8cd341cafee795d3d
- https://git.kernel.org/stable/c/ae5e95d4157481693be2317e3ffcd84e36010cbb
- https://git.kernel.org/stable/c/c3508895450cca4aeaf5dbadbb5e582363005264
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: md/raid5: validate payload size before accessing journal metadata r5c_recovery_analyze_meta_block() and r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block. A corrupted journal contains payload sizes extending beyond the PAGE_SIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets. Add bounds validation for each payload type to ensure the full payload fits within meta_size before processing.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/28d3ff7109c66e99dc1b7cddacb5c760849620ef
- https://git.kernel.org/stable/c/33698bd1b2db9764a29df7751533d33967ff5c98
- https://git.kernel.org/stable/c/406aa86394ead347c47428fb51b6359bdaa2257d
- https://git.kernel.org/stable/c/73ce72edd113374801045924d4417199963f73a3
- https://git.kernel.org/stable/c/b0cc3ae97e893bf54bbce447f4e9fd2e0b88bff9
- https://git.kernel.org/stable/c/c3a1cf78bd1bbb51b2cc5189b4743056553c1e0e
- https://git.kernel.org/stable/c/c96c6f01d84b5c67db1bf1cc8591c0b7146826fc
- https://git.kernel.org/stable/c/ef4851d8324fd978ca1ff9ec76a275438f887743
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ntfs3: add buffer boundary checks to run_unpack() run_unpack() checks `run_buf < run_last` at the top of the while loop but then reads size_size and offset_size bytes via run_unpack_s64() without verifying they fit within the remaining buffer. A crafted NTFS image with truncated run data in an MFT attribute triggers an OOB heap read of up to 15 bytes when the filesystem is mounted. Add boundary checks before each run_unpack_s64() call to ensure the declared field size does not exceed the remaining buffer. Found by fuzzing with a source-patched harness (LibAFL + QEMU).
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/41aadf5cb482793a24e05aa136224e179a778586
- https://git.kernel.org/stable/c/425de2aba0d061b3e715d51a3b1992c112ed5b99
- https://git.kernel.org/stable/c/b62567bca47408e6739dee75f02a2113548af875
- https://git.kernel.org/stable/c/bbad75336870b51b81979b97613746237fcb02fe
- https://git.kernel.org/stable/c/bf7ac4a1d3bfc6e56e54635c3d331a68170d37c9
- https://git.kernel.org/stable/c/d3012690a7065d9ca86521a525ad11e8af491d45
- https://git.kernel.org/stable/c/e64f7dfcaff79e7dfff9121a382dd77f9b462f62
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hwmon: (powerz) Fix missing usb_kill_urb() on signal interrupt wait_for_completion_interruptible_timeout() returns -ERESTARTSYS when interrupted. This needs to abort the URB and return an error. No data has been received from the device so any reads from the transfer buffer are invalid. The original code tests !ret, which only catches the timeout case (0). On signal delivery (-ERESTARTSYS), !ret is false so the function skips usb_kill_urb() and falls through to read from the unfilled transfer buffer. Fix by capturing the return value into a long (matching the function return type) and handling signal (negative) and timeout (zero) cases with separate checks that both call usb_kill_urb() before returning.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix memory leaks on probe failures Make sure to deregister the controller, disable pins, and kill and free the RX URB on probe failures to mirror disconnect and avoid memory leaks and use-after-free. Also add an explicit URB kill on disconnect for symmetry (even if that is not strictly required as USB core would have stopped it in the current setup).
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path Unregister the hwrng to prevent new ->read() calls and flush the Atmel I2C workqueue before teardown to prevent a potential UAF if a queued callback runs while the device is being removed. Drop the early return to ensure sysfs entries are removed and ->hwrng.priv is freed, preventing a memory leak.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1193c12126d39bf986a5a9214827b73707b193ab
- https://git.kernel.org/stable/c/31901371ccd16b42d2f167b1018ba9ae8bd5a6c7
- https://git.kernel.org/stable/c/6dbeb0f788582e1ab5dfc3f41994eac0ec88c2b5
- https://git.kernel.org/stable/c/775c00d87c385b758da9504cf053acea00e2ed40
- https://git.kernel.org/stable/c/bab1adf3b87e4bfac92c4f5963c63db434d561c1
- https://git.kernel.org/stable/c/c5a45d14234bf26e28a89e3a5dcc08336595cf11
HIGH7.9
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1 Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the hypercall is something other than one of the supported Hyper-V hypercalls. When all of the above conditions are met, KVM will intercept VMMCALL but never forward it to L1, i.e. will let L2 make hypercalls as if it were L1. The TLFS says a whole lot of nothing about this scenario, so go with the architectural behavior, which says that VMMCALL #UDs if it's not intercepted. Opportunistically do a 2-for-1 stub trade by stub-ifying the new API instead of the helpers it uses. The last remaining "single" stub will soon be dropped as well. [sean: rewrite changelog and comment, tag for stable, remove defunct stubs]
CVSS 3.xHIGH 7.9
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-tdes - fix DMA sync direction Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/12a0adfe498cd5d87e6365d7ca5f6b3eed79e523
- https://git.kernel.org/stable/c/5281e6e2302362f6b75b70cbfe4098d2a25dafd9
- https://git.kernel.org/stable/c/863d11b3927703ad95077c81a8a6489c5c7872f7
- https://git.kernel.org/stable/c/b5f5df801d161ba244f391519cbff2f4e5c6edc2
- https://git.kernel.org/stable/c/b9b28f3881dd514e74f98ae04e79a635022a4804
- https://git.kernel.org/stable/c/c0f3002c02a3a83250e25582ffbe8df7eb78a8bd
- https://git.kernel.org/stable/c/c8a9a647532f5c2a04180352693215e24e9dba03
- https://git.kernel.org/stable/c/ce3224678acb8c0b3473daa7d7dbffc998c6951a
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/1d55445226c75ddd4e78b09b3e7d99109b28c366
- https://git.kernel.org/stable/c/222055e6b4063abd2d9e13c3d49bbd1724c50789
- https://git.kernel.org/stable/c/48b27a955d22391c7f30169fa7b6b2e1977f1ce4
- https://git.kernel.org/stable/c/80a23c6d1aba35be8746d74ac14e6ba5ae46da21
- https://git.kernel.org/stable/c/8ebb951a284b7446e025afc7dc5e9516ef9a7214
- https://git.kernel.org/stable/c/a8ee527807f7d97e55ce2ef2906f7f34975eb1c7
- https://git.kernel.org/stable/c/aa16dca1b062355181ef215229eeac249d7c0d61
- https://git.kernel.org/stable/c/d18a3b5d337fa412a38e776e6b4b857a58836575
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
rbd: fix null-ptr-deref when device_add_disk() fails
do_rbd_add() publishes the device with device_add() before calling
device_add_disk(). If device_add_disk() fails after device_add()
succeeds, the error path calls rbd_free_disk() directly and then later
falls through to rbd_dev_device_release(), which calls rbd_free_disk()
again. This double teardown can leave blk-mq cleanup operating on
invalid state and trigger a null-ptr-deref in
__blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set().
Fix this by following the normal remove ordering: call device_del()
before rbd_dev_device_release() when device_add_disk() fails after
device_add(). That keeps the teardown sequence consistent and avoids
re-entering disk cleanup through the wrong path.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available.
We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64
guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer
confines failslab injections to the __add_disk() range and injects
fail-nth while mapping an RBD image through
/sys/bus/rbd/add_single_major.
On the unpatched kernel, fail-nth=4 reliably triggered the fault:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240
Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00
RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246
RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4
RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b
R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000
R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004
FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0
PKRU: 55555554
Call Trace:
blk_mq_free_tag_set+0x77/0x460
do_rbd_add+0x1446/0x2b80
? __pfx_do_rbd_add+0x10/0x10
? lock_acquire+0x18c/0x300
? find_held_lock+0x2b/0x80
? sysfs_file_kobj+0xb6/0x1b0
? __pfx_sysfs_kf_write+0x10/0x10
kernfs_fop_write_iter+0x2f4/0x4a0
vfs_write+0x98e/0x1000
? expand_files+0x51f/0x850
? __pfx_vfs_write+0x10/0x10
ksys_write+0xf2/0x1d0
? __pfx_ksys_write+0x10/0x10
do_syscall_64+0x115/0x690
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0fbea15907
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907
RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001
RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141
R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058
R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004
With this fix applied, rerunning the reproducer over fail-nth=1..256
yields no KASAN reports.
[ idryomov: rename err_out_device_del -> err_out_device ]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/059fb7656723c1b77c2fc0e64b7aa99d6bb65e8e
- https://git.kernel.org/stable/c/2f4809a879f0750c7790bbeeae86c9505797a06f
- https://git.kernel.org/stable/c/564cd8f4aeb9a938e470c5c91922fd02e4d41acc
- https://git.kernel.org/stable/c/78bd0c143dea4b7a4c23c13356987ca0eafb442e
- https://git.kernel.org/stable/c/ad0126ffcba8777109852979eaaa6dca6703abdb
- https://git.kernel.org/stable/c/d1fef92e414433ca7b89abf85cb0df42b8d475eb
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ocfs2: split transactions in dio completion to avoid credit exhaustion During ocfs2 dio operations, JBD2 may report warnings via following call trace: ocfs2_dio_end_io_write ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_split_extent ocfs2_try_to_merge_extent ocfs2_extend_rotate_transaction ocfs2_extend_trans jbd2__journal_restart start_this_handle output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449 To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to handle extents in a batch of transaction. Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode should only be removed from the orphan list after the extent tree update is complete. This ensures that if a crash occurs in the middle of extent tree updates, we won't leave stale blocks beyond EOF. This patch also changes the logic for updating the inode size and removing orphan, making it similar to ext4_dio_write_end_io(). Both operations are performed only when everything looks good. Finally, thanks to Jans and Joseph for providing the bug fix prototype and suggestions.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/069c3fb310e9336cf48cfdf8748a32c29fd0193d
- https://git.kernel.org/stable/c/1e99bb19994246514d63e656492904176f9d5edd
- https://git.kernel.org/stable/c/3c636a3edca9c3f180b3079f94fe7e115730d9c6
- https://git.kernel.org/stable/c/886f97fa59d0bbfa9859fb1a66dd9e014b522d89
- https://git.kernel.org/stable/c/91e05ac2336d00d5b99fc774be4bd50039084796
- https://git.kernel.org/stable/c/97c03c0e9f73a5049794b3c69ee60fb5e8b0ebd8
- https://git.kernel.org/stable/c/d647c5b2fbf81560818dacade360abc8c00a9665
- https://git.kernel.org/stable/c/ea5bb1d20da756e4f41a48dad42b2e7d6e73f71e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0 INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to properly inject #UD when EFER.SVME=0. [sean: tag for stable@]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3ac9d4241d205f5d0df06358349ca718ebb0fa12
- https://git.kernel.org/stable/c/491139c17f8ad5773303068411f6ac5eed438b51
- https://git.kernel.org/stable/c/643125b66ffc1147c66616b749475ba9efb15971
- https://git.kernel.org/stable/c/c15392ed9e49c1a16b4d3a3ccf1b3bf2318a6c28
- https://git.kernel.org/stable/c/d99df02ff427f461102230f9c5b90a6c64ee8e23
- https://git.kernel.org/stable/c/ebb63390142c6458fc37758e0892759989cc159f
- https://git.kernel.org/stable/c/ee24928ecd85db4b68ed111e91fef36af0ca37b0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: fix resource leaks on device setup failure Make sure to call controller cleanup() if spi_setup() fails while registering a device to avoid leaking any resources allocated by setup().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/11baa8b24bcb07ae2048f2566a220021d766abe0
- https://git.kernel.org/stable/c/1e774294b2f944f59e03a04eb438768a4b93c3ce
- https://git.kernel.org/stable/c/a2c817c629430fbbd54273525b472dac96e2c8fd
- https://git.kernel.org/stable/c/db357034f7e0cf23f233f414a8508312dfe8fbbe
- https://git.kernel.org/stable/c/dbcead54b12468d9aa54c0e1f0042d838ec3b0ae
- https://git.kernel.org/stable/c/e0401de43dac00f3e4841ca2aeb98bc10a4c5f13
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana_ib: Disable RX steering on RSS QP destroy When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss() destroys the RX WQ objects but does not disable vPort RX steering in firmware. This leaves stale steering configuration that still points to the destroyed RX objects. If traffic continues to arrive (e.g. peer VM is still transmitting) and the VF interface is subsequently brought up (mana_open), the firmware may deliver completions using stale CQ IDs from the old RX objects. These CQ IDs can be reused by the ethernet driver for new TX CQs, causing RX completions to land on TX CQs: WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false) WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails) Fix this by disabling vPort RX steering before destroying RX WQ objects. Note that mana_fence_rqs() cannot be used here because the fence completion is delivered on the CQ, which is polled by user-mode (e.g. DPDK) and not visible to the kernel driver. Refactor the disable logic into a shared mana_disable_vport_rx() in mana_en, exported for use by mana_ib, replacing the duplicate code. The ethernet driver's mana_dealloc_queues() is also updated to call this common function.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3be5ed233de03b00ae868cfc06e95331d8d9007c
- https://git.kernel.org/stable/c/6a2d6273b6c3581ce7b90ce17b5cbb4efd19438f
- https://git.kernel.org/stable/c/8ba804869382ce307f2a15f5f6f2adfd791f41dc
- https://git.kernel.org/stable/c/dbeb256e8dd87233d891b170c0b32a6466467036
- https://git.kernel.org/stable/c/f1ccc4d500a0b87a5599343fc2f798048836e184
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix rxkad crypto unalignment handling Fix handling of a packet with a misaligned crypto length. Also handle non-ENOMEM errors from decryption by aborting. Further, remove the WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can still be emitted).
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/440d20d95e844b657a93a0b2dcc2aae155efdce6
- https://git.kernel.org/stable/c/af9271eb666d07b6f65612dc160a47f7cb5220ed
- https://git.kernel.org/stable/c/def304aae2edf321d2671fd6ca766a93c21f877e
- https://git.kernel.org/stable/c/f0d3efd03b2a9e0f1ffa6df8fcb264af3d494286
- https://git.kernel.org/stable/c/f1c6bd0cc786a8fa74829ce3c4b3673944a308f4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b9e4bbfb7c949151e3acd44ed4aa33614d2e110
- https://git.kernel.org/stable/c/1406c4e0ed1eaf8a29801ab1163d00fb7ee4359a
- https://git.kernel.org/stable/c/5424e678f9b304e148cf5dcc047cffc7a56a3bb5
- https://git.kernel.org/stable/c/81af4137a30c4c2dc694dea8cacb180bd66000ef
- https://git.kernel.org/stable/c/9a2d9d4e657b23dc21f24cf139e3aeff0b61341f
- https://git.kernel.org/stable/c/a6ae4511c07b91f597e461406c6330f0d4ff810e
- https://git.kernel.org/stable/c/c502fa9f094cb03d1d1685c71e2105ab359bc2b8
- https://git.kernel.org/stable/c/df4601653201de21b487c3e7fffd464790cab808
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names() snd_ctl_elem_init_enum_names() advances pointer p through the names buffer while decrementing buf_len. If buf_len reaches zero but items remain, the next iteration calls strnlen(p, 0). While strnlen(p, 0) returns 0 and would hit the existing name_len == 0 error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks maxlen against __builtin_dynamic_object_size(). When Clang loses track of p's object size inside the loop, this triggers a BRK exception panic before the return value is examined. Add a buf_len == 0 guard at the loop entry to prevent calling fortified strnlen() on an exhausted buffer. Found by kernel fuzz testing through Xiaomi Smartphone.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1fbe46d2b72754d8bd580e13e59ccb5d3d0e8cb0
- https://git.kernel.org/stable/c/654c818a69c21d2bea4e8fd9eae7da865df9a5c8
- https://git.kernel.org/stable/c/708f6ec9bcdf58bfd561409110baaf4fd3be4ea3
- https://git.kernel.org/stable/c/82012fd3e78a14360fbc2f1a7491589896704f97
- https://git.kernel.org/stable/c/8ba0214c3dd32b8ec652947e3f2bc5b8f6e6be9e
- https://git.kernel.org/stable/c/a470f7cabc4df72d9bd132f5719a8717292bb440
- https://git.kernel.org/stable/c/bfcbb4994da9e979c4bcfcf24aaaac69e457e48e
- https://git.kernel.org/stable/c/e0da8a8cac74f4b9f577979d131f0d2b88a84487
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: zram: do not forget to endio for partial discard requests As reported by Qu Wenruo and Avinesh Kumar, the following getconf PAGESIZE 65536 blkdiscard -p 4k /dev/zram0 takes literally forever to complete. zram doesn't support partial discards and just returns immediately w/o doing any discard work in such cases. The problem is that we forget to endio on our way out, so blkdiscard sleeps forever in submit_bio_wait(). Fix this by jumping to end_bio label, which does bio_endio().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2d1f18efccdb8b29552399d024c36b705447e975
- https://git.kernel.org/stable/c/35d3300f6357cfaa72db2721dc2b345b19bac5df
- https://git.kernel.org/stable/c/68ce397e8236088fc53b9532d383a722288c8194
- https://git.kernel.org/stable/c/a02363f71a79b755daa78a70d6b217f9c13c8c85
- https://git.kernel.org/stable/c/e3668b371329ea036ff022ce8ecc82f8befcf003
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/03f52a9c170431e8f10e156b9dc0dae80b3e9198
- https://git.kernel.org/stable/c/345c24b2bcf0923dfae1ab41497351c68214ff76
- https://git.kernel.org/stable/c/5d45e34bf001344e2966dabca1897561bbc9e913
- https://git.kernel.org/stable/c/83bd62fa9620ac98d5d694bde14c50f98c8e7189
- https://git.kernel.org/stable/c/bdd9503c3d222d2735b56c7a8b4422ccf3de6e5c
- https://git.kernel.org/stable/c/e5c33cdc6f402eab8abd36ecf436b22c9d3a8aff
- https://access.redhat.com/errata/RHSA-2026:27353
- https://access.redhat.com/errata/RHSA-2026:27354
- https://access.redhat.com/errata/RHSA-2026:30848
- https://access.redhat.com/errata/RHSA-2026:33215
- https://access.redhat.com/errata/RHSA-2026:33685
- https://access.redhat.com/errata/RHSA-2026:33899
- https://access.redhat.com/errata/RHSA-2026:33900
- https://access.redhat.com/errata/RHSA-2026:34094
- https://access.redhat.com/errata/RHSA-2026:34095
- https://access.redhat.com/errata/RHSA-2026:34443
- https://access.redhat.com/errata/RHSA-2026:35844
- https://access.redhat.com/errata/RHSA-2026:35863
- https://access.redhat.com/errata/RHSA-2026:35896
- https://access.redhat.com/errata/RHSA-2026:41236
- https://access.redhat.com/security/cve/CVE-2026-46090
- https://bugzilla.redhat.com/show_bug.cgi?id=2481980
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46090.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0adac0ee2c42027d80bac02ea9b576a88f8955d3
- https://git.kernel.org/stable/c/0be8fcd9005e3d3b5a61fe34b070a9663adbb4dc
- https://git.kernel.org/stable/c/0e84aa8fc23c7578f105e3a2160f9d0aa2bed79a
- https://git.kernel.org/stable/c/18d6a7c9e4e63c57157e9a57dd9bf3cd38e4c45a
- https://git.kernel.org/stable/c/81f0fb813e4bf28b3ca28dc218938a32eb48f740
- https://git.kernel.org/stable/c/a62ca67e3c72fb297dc7c86495ba8f7329d7f150
- https://git.kernel.org/stable/c/bc04b8633b375af6ac8a8bb615258b80fe06cdaa
- https://git.kernel.org/stable/c/eac69475b01fe1e861dfe3960b57fa95671c132e
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access The bounds check for the next xattr entry in check_xattrs() uses (void *)next >= end, which allows next to point within sizeof(u32) bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4 bytes via *(__u32 *)(entry), which can overrun the valid xattr region. For example, if next lands at end - 1, the check passes since next < end, but IS_LAST_ENTRY() reads 4 bytes starting at end - 1, accessing 3 bytes beyond the valid region. Fix this by changing the check to (void *)next + sizeof(u32) > end, ensuring there is always enough space for the IS_LAST_ENTRY() read on the subsequent iteration.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/520986722dbf869c122252123fc161c7302eab7d
- https://git.kernel.org/stable/c/537e065977022aa22f2c2503e8accaf16622e0fd
- https://git.kernel.org/stable/c/5a5314d2387633a272a04d1bd8727f99058e4e68
- https://git.kernel.org/stable/c/ab6da97bc310db35d4e4ef5354bc3ff626b0698c
- https://git.kernel.org/stable/c/eceafc31ea7b42c984ece10d79d505c0bb6615d5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: caif: clear client service pointer on teardown `caif_connect()` can tear down an existing client after remote shutdown by calling `caif_disconnect_client()` followed by `caif_free_client()`. `caif_free_client()` releases the service layer referenced by `adap_layer->dn`, but leaves that pointer stale. When the socket is later destroyed, `caif_sock_destructor()` calls `caif_free_client()` again and dereferences the freed service pointer. Clear the client/service links before releasing the service object so repeated teardown becomes harmless.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3ac6db584d9d420267bb8413115707eeec76d9cf
- https://git.kernel.org/stable/c/63d21a3aa0108b9dde4e99b0d3d5d679ac68c0f9
- https://git.kernel.org/stable/c/7ef97d4675b05a103648bd9244d91dff7d8c08b0
- https://git.kernel.org/stable/c/914c6456fcfc21a3d553945dff62fd1621d6155d
- https://git.kernel.org/stable/c/a4b191ddc12c55ddb62feb096536f819f384d6f1
- https://git.kernel.org/stable/c/cffca7a18b8f9de7c3d3013a1f5740c412b2a501
- https://git.kernel.org/stable/c/e16859f3f4426fa349bc5519d582a93d28f5a15d
- https://git.kernel.org/stable/c/f7cf8ece8cee3c1ee361991470cdb1eb65ab02e8
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels seg6_input_core() and rpl_input() call ip6_route_input() which sets a NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking dst_hold() unconditionally. On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpu_rt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence: ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6_input_core(,skb)/rpl_input(skb) dst_cache_get() -> miss ip6_route_input(skb) -> ip6_pol_route(,skb,flags) [RT6_LOOKUP_F_DST_NOREF in flags] -> FIB lookup resolves fib6_nh [nhid=N route] -> rt6_make_pcpu_route() [creates pcpu_rt, refcount=1] pcpu_rt->sernum = fib6_sernum [fib6_sernum=W] -> cmpxchg(fib6_nh.rt6i_pcpu, NULL, pcpu_rt) [slot was empty, store succeeds] -> skb_dst_set_noref(skb, dst) [dst is pcpu_rt, refcount still 1] rt_genid_bump_ipv6() -> bumps fib6_sernum [fib6_sernum from W to Z] ip6_route_output() -> ip6_pol_route() -> FIB lookup resolves fib6_nh [nhid=N] -> rt6_get_pcpu_route() pcpu_rt->sernum != fib6_sernum [W <> Z, stale] -> prev = xchg(rt6i_pcpu, NULL) -> dst_release(prev) [prev is pcpu_rt, refcount 1->0, dead] dst = skb_dst(skb) [dst is the dead pcpu_rt] dst_cache_set_ip6(dst) -> dst_hold() on dead dst -> WARN / use-after-free For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release the pcpu_rt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6_nh and its rt6i_pcpu entry. Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after ip6_route_input() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6_route_output() already returns a refcounted dst.
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/51fef5a7c4d160839199e941929456ba21ddf73c
- https://git.kernel.org/stable/c/52f9db67f8f35f436366cf4980b4f0a2583d0ef0
- https://git.kernel.org/stable/c/6bd17925bd6866027a6555db17905b9fc073d38d
- https://git.kernel.org/stable/c/9dd5481f960e337b81d7dfe429529495c1c481c0
- https://git.kernel.org/stable/c/b258b849a580285a1692e782ebc902b44c884a71
- https://git.kernel.org/stable/c/b778b6d095421619c331fd2d7751143cd5387103
- https://git.kernel.org/stable/c/f9c52a6ba9780bd27e0bf4c044fd91c13c778b6e
- https://access.redhat.com/errata/RHSA-2026:45114
- https://access.redhat.com/security/cve/CVE-2026-46099
- https://bugzilla.redhat.com/show_bug.cgi?id=2481972
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46099.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: reject zero shift in nft_bitwise Reject zero shift operands for nft_bitwise left and right shift expressions during initialization. The carry propagation logic computes the carry from the adjacent 32-bit word using BITS_PER_TYPE(u32) - shift. A zero shift operand turns this into a 32-bit shift, which is undefined behaviour. Reject zero shift operands in the control plane, alongside the existing check for values greater than or equal to 32, so malformed rules never reach the packet path.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4fccea585631621c975883911a08d15b6671f7dc
- https://git.kernel.org/stable/c/6f820139d16a4c9865a145d4a9cf9c92cc632c14
- https://git.kernel.org/stable/c/9ad26c272405f53834871cc2e46b9b5393a666c3
- https://git.kernel.org/stable/c/9baa08d6b6b096fad70049533f0d705d85fdc979
- https://git.kernel.org/stable/c/bffef0acec9c3b837a785248a893137fb7f26c95
- https://git.kernel.org/stable/c/ca24f1243ad1a4d12d6a23876bbbe3ed02099853
- https://git.kernel.org/stable/c/f370205974f171a5868c13ff30d7642fed46e47b
- https://git.kernel.org/stable/c/fe11e5c40817b84abaa5d83bfb6586d8412bfd07
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net: strparser: fix skb_head leak in strp_abort_strp() When the stream parser is aborted, for example after a message assembly timeout, it can still hold a reference to a partially assembled message in strp->skb_head. That skb is not released in strp_abort_strp(), which leaks the partially assembled message and can be triggered repeatedly to exhaust memory. Fix this by freeing strp->skb_head and resetting the parser state in the abort path. Leave strp_stop() unchanged so final cleanup still happens in strp_done() after the work and timer have been synchronized.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/19ca9475f18f991735f98a22e735c43e95e6298d
- https://git.kernel.org/stable/c/5327dad2ffe9c1b49881dd6d51ff3c6893847568
- https://git.kernel.org/stable/c/56082f442023db9be1a5a29d4ee361de4017c0b7
- https://git.kernel.org/stable/c/a470ed71c906cc8cbad0d74c9942216698911f8b
- https://git.kernel.org/stable/c/c2e57695ec9ff9d42f23de70f3805199153d007b
- https://git.kernel.org/stable/c/d6668ce0e78d23eabecef9a6bc4f0f739cb28ad3
- https://git.kernel.org/stable/c/e9ae00490d474757c0f9c65073de83e6bb1e5a00
- https://git.kernel.org/stable/c/fe72340daaf1af588be88056faf98965f39e6032
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/10b7b676b78a7bd888d19729b459aad7fc1f428b
- https://git.kernel.org/stable/c/3df5b9110ac08f67ccfe382fc172bfee95688eec
- https://git.kernel.org/stable/c/4b7d07747400cfd7eff1ba7b8b5a7c8d5a58f705
- https://git.kernel.org/stable/c/a90f0815aaa9c629ac4750e7c71c357dd7f231d7
- https://git.kernel.org/stable/c/c0d3ccc6929e4509076df8f30a4fb1dc5018b0ae
- https://git.kernel.org/stable/c/c524c124e3094d2de12235a513854c03d06a2b58
- https://git.kernel.org/stable/c/cb2e41e87a2893345859440017e7178bf7a4c70d
- https://git.kernel.org/stable/c/fed4626501c871890da287bec62a96e52da1af89
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: eventfs: Hold eventfs_mutex and SRCU when remount walks events Commit 340f0c7067a9 ("eventfs: Update all the eventfs_inodes from the events descriptor") had eventfs_set_attrs() recurse through ei->children on remount. The walk only holds the rcu_read_lock() taken by tracefs_apply_options() over tracefs_inodes, which is wrong: - list_for_each_entry over ei->children races with the list_del_rcu() in eventfs_remove_rec() -- LIST_POISON1 deref, same shape as d2603279c7d6. - eventfs_inodes are freed via call_srcu(&eventfs_srcu, ...). rcu_read_lock() does not extend an SRCU grace period, so ti->private can be reclaimed under the walk. - The writes to ei->attr race with eventfs_set_attr(), which holds eventfs_mutex. Reproducer: while :; do mount -o remount,uid=$((RANDOM%1000)) /sys/kernel/tracing; done & while :; do echo "p:kp submit_bio" > /sys/kernel/tracing/kprobe_events echo > /sys/kernel/tracing/kprobe_events done Wrap the events portion of tracefs_apply_options() in eventfs_remount_lock()/_unlock() that take eventfs_mutex and srcu_read_lock(&eventfs_srcu). eventfs_set_attrs() doesn't sleep so the nested rcu_read_lock() is fine; lockdep_assert_held() pins the contract. Comment in tracefs_drop_inode() said "RCU cycle" -- it is SRCU.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/07004a8c4b572171934390148ee48c4175c77eed
- https://git.kernel.org/stable/c/44e64d8a432837308f4dda3ffe819f1ec092a0ba
- https://git.kernel.org/stable/c/52b109f1b875b912d4ab2c5fdd8c322d47119d9b
- https://git.kernel.org/stable/c/ae9cd0b46b1890040006a2fc5e905c5d6053fd02
- https://git.kernel.org/stable/c/ed2ad73bcb0a7a6cc934097d4853b6d5124c317e
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm-thin: fix metadata refcount underflow There's a bug in dm-thin in the function rebalance_children. If the internal btree node has one entry, the code tries to copy all btree entries from the node's child to the node itself and then decrement the child's reference count. If the child node is shared (it has reference count > 1), we won't free it, so there would be two pointers to each of the grandchildren nodes. But the reference counts of the grandchildren is not increased, thus the reference count doesn't match the number of pointers that point to the grandchildren. This results in "device mapper: space map common: unable to decrement block" errors. Fix this bug by incrementing reference counts on the grandchildren if the btree node is shared.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/09a65adc7d8bbfce06392cb6d375468e2728ead5
- https://git.kernel.org/stable/c/12161e03d33afce781f68fa11cc6060538862fad
- https://git.kernel.org/stable/c/323d252a4a378834e4fe68298ca61cfc5dd3a460
- https://git.kernel.org/stable/c/5ec0debbcfd43596e32c1239e993de06a704e04c
- https://git.kernel.org/stable/c/85311a585a26640760cd0f3349ab9f2905691044
- https://git.kernel.org/stable/c/b719d12cb94df345e9ad2715fd0abe9afcaeb111
- https://git.kernel.org/stable/c/f06f6aededd792a754cd677c02b3d3016d868c2c
- https://git.kernel.org/stable/c/f49b41c9eb7c6ff00df27cd49cea210abbadd8ad
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipmi:si: Return state to normal if message allocation fails There were places where nothing would get started if a message allocation failed, so the driver needs to return to normal state.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/09dd798270ff582d7309f285d4aaf5dbebae01cb
- https://git.kernel.org/stable/c/88881dc1da86064f479378bc9d0a4956c3d0bb12
- https://git.kernel.org/stable/c/9c6ded95ac6281e390d167637ccbde6cea2ba1ae
- https://git.kernel.org/stable/c/ab48817aebe4d831f87d4da6f94f50498c130d9e
- https://git.kernel.org/stable/c/ba60140d4133231b49185ac8bf6e54f318d3134e
- https://git.kernel.org/stable/c/bc13fce9eeec88c4950924754c3347c6dc66ff4c
- https://git.kernel.org/stable/c/c204fab7f76a055eac346e3b1a75c6b4bb99600e
- https://git.kernel.org/stable/c/ce905b65e649eee378a0f37e8219f1d70efb3007
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix memory leak on ulpi_register() error paths Commit 01af542392b5 ("usb: ulpi: fix double free in ulpi_register_interface() error path") removed kfree(ulpi) from ulpi_register_interface() to fix a double-free when device_register() fails. But when ulpi_of_register() or ulpi_read_id() fail before device_register() is called, the ulpi allocation is leaked. Add kfree(ulpi) on both error paths to properly clean up the allocation.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b9fcab1b8608d429e5f239afb197de928d4de7d
- https://git.kernel.org/stable/c/0c2c0c6820fe96fa4be0a0499f8d3f3321b9af6c
- https://git.kernel.org/stable/c/2a71e01b2cf9b4329ff67102c1bea7448c2a2d2d
- https://git.kernel.org/stable/c/7bd61ed0bf9f4f1f2673d489b3bda1555b48d054
- https://git.kernel.org/stable/c/b0c0d44adb55c66663886cb6e30ee92cbb0f5385
- https://git.kernel.org/stable/c/be2c1d825f54277472c87019e82013ac534ddc4c
- https://git.kernel.org/stable/c/f1b855c00988a9cb41134cab7cf9faedba775dd9
- https://git.kernel.org/stable/c/f30ccfc2985590b33a23a3d8bed7ca16c0af551b
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Prevent NULL deref when RX memory exhausted The CPU receives frames from the MAC through conventional DMA: the CPU allocates buffers for the MAC, then the MAC fills them and returns ownership to the CPU. For each hardware RX queue, the CPU and MAC coordinate through a shared ring array of DMA descriptors: one descriptor per DMA buffer. Each descriptor includes the buffer's physical address and a status flag ("OWN") indicating which side owns the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set the flag and the MAC is only allowed to clear it, and both must move through the ring in sequence: thus the ring is used for both "submissions" and "completions." In the stmmac driver, stmmac_rx() bookmarks its position in the ring with the `cur_rx` index. The main receive loop in that function checks for rx_descs[cur_rx].own=0, gives the corresponding buffer to the network stack (NULLing the pointer), and increments `cur_rx` modulo the ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its position with `dirty_rx`, allocates fresh buffers and rearms the descriptors (setting OWN=1). If it fails any allocation, it simply stops early (leaving OWN=0) and will retry where it left off when next called. This means descriptors have a three-stage lifecycle (terms my own): - `empty` (OWN=1, buffer valid) - `full` (OWN=0, buffer valid and populated) - `dirty` (OWN=0, buffer NULL) But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In the past (see 'Fixes:'), there was a bug where the loop could cycle `cur_rx` all the way back to the first descriptor it dirtied, resulting in a NULL dereference when mistaken for `full`. The aforementioned commit resolved that *specific* failure by capping the loop's iteration limit at `dma_rx_size - 1`, but this is only a partial fix: if the previous stmmac_rx_refill() didn't complete, then there are leftover `dirty` descriptors that the loop might encounter without needing to cycle fully around. The current code therefore panics (see 'Closes:') when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to catch up to `dirty_rx`. Fix this by explicitly checking, before advancing `cur_rx`, if the next entry is dirty; exit the loop if so. This prevents processing of the final, used descriptor until stmmac_rx_refill() succeeds, but fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix intended: so remove the clamp as well. Since stmmac_rx_zc() is a copy-paste-and-tweak of stmmac_rx() and the code structure is identical, any fix to stmmac_rx() will also need a corresponding fix for stmmac_rx_zc(). Therefore, apply the same check there. In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the MAC sets OWN=0 on the final descriptor, it will be unable to send any further DMA-complete IRQs until it's given more `empty` descriptors. Currently, the driver simply *hopes* that the next stmmac_rx_refill() succeeds, risking an indefinite stall of the receive process if not. But this is not a regression, so it can be addressed in a future change.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0bb05e6adfa99a2ea1fee1125cc0953409f83ed8
- https://git.kernel.org/stable/c/4af2e62cbcda575a174acd230c3f3a208135e16d
- https://git.kernel.org/stable/c/5c910f7708e3c507b037ca91ca5b09f8cfe71e65
- https://git.kernel.org/stable/c/950cb436165aad0f8f2cd49da3cd07677465bcde
- https://git.kernel.org/stable/c/e1c50b273298c7cd9b08b113e7a7598b531a02f5
- https://git.kernel.org/stable/c/fdeb95b1fc7de25c9362990efb9996a8d761055c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in create_big_sync Add hci_conn_valid() check in create_big_sync() to detect stale connections before proceeding with BIG creation. Handle the resulting -ECANCELED in create_big_complete() and re-validate the connection under hci_dev_lock() before dereferencing, matching the pattern used by create_le_conn_complete() and create_pa_complete(). Keep the hci_conn object alive across the async boundary by taking a reference via hci_conn_get() when queueing create_big_sync(), and dropping it in the completion callback. The refcount and the lock are complementary: the refcount keeps the object allocated, while hci_dev_lock() serializes hci_conn_hash_del()'s list_del_rcu() on hdev->conn_hash, as required by hci_conn_del(). hci_conn_put() is called outside hci_dev_unlock() so the final put (which resolves to kfree() via bt_link_release) does not run under hdev->lock, though the release path would be safe either way. Without this, create_big_complete() would unconditionally dereference the conn pointer on error, causing a use-after-free via hci_connect_cfm() and hci_conn_del().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0beddb0c380bed5f5b8e61ddbe14635bb73d0b41
- https://git.kernel.org/stable/c/1750a2df0eab61dc421a7afae74abdd239a44b85
- https://git.kernel.org/stable/c/6823f730bf195fc296d9edd09e2ca94bc1ff5584
- https://git.kernel.org/stable/c/dc34f8d8240f25dd137dc2758ebbcc75e3779142
- https://git.kernel.org/stable/c/f8eaf92c57ad99358dd372580d5ff87623343a72
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() Sashiko points out that hns_roce_qp_remove() requires the caller to hold locks. The error flow in hns_roce_create_qp_common() doesn't hold those locks for the error unwind so it risks corrupting memory. Grab the same locks the other two callers use.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0c99acbc8b6c6dd526ae475a48ee1897b61072fb
- https://git.kernel.org/stable/c/1912f78798505dc9c637081bbddfbf1c22494c49
- https://git.kernel.org/stable/c/1f0a3aa8b569d010316b427238222c5d899f9618
- https://git.kernel.org/stable/c/615d9d260c32bb678504ca96f29ae46f9d745155
- https://git.kernel.org/stable/c/b6296ff2475fc95ee6ea1b528c4b385302808186
- https://git.kernel.org/stable/c/fb4ae739811d467409bd07d0e36cfd4140f3d26a
- https://git.kernel.org/stable/c/fcf6a832c0d5b2bc5398d6996c5570d3ee7993fb
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/06c19c967b845b63172601fe459667d973b7e6b7
- https://git.kernel.org/stable/c/0cb2af2ea66ad8ff195c156ea690f11216285bdf
- https://git.kernel.org/stable/c/14d1e55dfd2cf4711bff164a6aaaddb783552134
- https://git.kernel.org/stable/c/488e386484ec8c0e558be6e156edf34ed9f4d5c8
- https://git.kernel.org/stable/c/738ec97b1855df6c08fe2369f798fa0b972e556b
- https://git.kernel.org/stable/c/e9d4ea13aa2b6400bb10ec64b370ba3dadcd22f0
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject non-8-byte ATOMIC_WRITE payloads atomic_write_reply() at drivers/infiniband/sw/rxe/rxe_resp.c unconditionally dereferences 8 bytes at payload_addr(pkt): value = *(u64 *)payload_addr(pkt); check_rkey() previously accepted an ATOMIC_WRITE request with pktlen == resid == 0 because the length validation only compared pktlen against resid. A remote initiator that sets the RETH length to 0 therefore reaches atomic_write_reply() with a zero-byte logical payload, and the responder reads sizeof(u64) bytes from past the logical end of the packet into skb->head tailroom, then writes those 8 bytes into the attacker's MR via rxe_mr_do_atomic_write(). That is a remote disclosure of 4 bytes of kernel tailroom per probe (the other 4 bytes are the packet's own trailing ICRC). IBA oA19-28 defines ATOMIC_WRITE as exactly 8 bytes. Anything else is protocol-invalid. Hoist a strict length check into check_rkey() so the responder never reaches the unchecked dereference, and keep the existing WRITE-family length logic for the normal RDMA WRITE path. Reproduced on mainline with an unmodified rxe driver: a sustained zero-length ATOMIC_WRITE probe repeatedly leaks adjacent skb head-buffer bytes into the attacker's MR, including recognisable kernel strings and partial kernel-direct-map pointer words. With this patch applied the responder rejects the PDU and the MR stays all-zero.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
- https://git.kernel.org/stable/c/105bf79a23b85cf3a761d18a4f3e10ce88526bc1
- https://git.kernel.org/stable/c/1114c87aa6f195cf07da55a27b2122ae26557b26
- https://git.kernel.org/stable/c/539cabb7b2d8ba70f55bba91db55faef11c2a6d7
- https://git.kernel.org/stable/c/7ec1ed4747f5f99f8b797bb438c5efd36079fad5
- https://git.kernel.org/stable/c/d415fce3fcde6d7aeea6c25362a395b905811452
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: block: add pgmap check to biovec_phys_mergeable biovec_phys_mergeable() is used by the request merge, DMA mapping, and integrity merge paths to decide if two physically contiguous bvec segments can be coalesced into one. It currently has no check for whether the segments belong to different dev_pagemaps. When zone device memory is registered in multiple chunks, each chunk gets its own dev_pagemap. A single bio can legitimately contain bvecs from different pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the outer loop in bio_iov_iter_get_pages() continues filling the same bio. If such bvecs are physically contiguous, biovec_phys_mergeable() will coalesce them, making it impossible to recover the correct pgmap for the merged segment via page_pgmap(). Add a zone_device_pages_have_same_pgmap() check to prevent merging bvec segments that span different pgmaps.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/13920e4b7b784b40cf4519ff1f0f3e513476a499
- https://git.kernel.org/stable/c/3d2ecbd444b01d6500671d1a582b7393943cf539
- https://git.kernel.org/stable/c/a7f3aa8c9df3905fe820ae36b67ba56b81587574
- https://git.kernel.org/stable/c/f17d521075325b8afc42d1baa1c28a5e9aca111f
- https://git.kernel.org/stable/c/f632dab4b841554cd6416058c61886d7db176581
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: if (x->km.seq) hlist_del_rcu(&x->byseq); if (x->id.spi) hlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/14acf9652e5690de3c7486c6db5fb8dafd0a32a3
- https://git.kernel.org/stable/c/26edb0a3c99f9d958c212be68b21f1221614dcf0
- https://git.kernel.org/stable/c/2c617848ae6e4f07a3e397f604208c293bbecacc
- https://git.kernel.org/stable/c/3943fcad7694a7d0b15aeabe7d3cc2a2eb8e92e8
- https://git.kernel.org/stable/c/4980162de555cb838f1a189ce7d2cbf5d2e7b050
- https://git.kernel.org/stable/c/6b4dc3181b4bfc5f5fc33ab33b1dc6e15759f4b6
- https://git.kernel.org/stable/c/a2e2d08fb070fab4947447171f1c4e3ca5a188e5
- https://git.kernel.org/stable/c/b4a53add2fa8f1b5aa17d4c5686c320785fab182
- https://access.redhat.com/errata/RHSA-2026:36018
- https://access.redhat.com/errata/RHSA-2026:39179
- https://access.redhat.com/errata/RHSA-2026:39180
- https://access.redhat.com/errata/RHSA-2026:39371
- https://access.redhat.com/errata/RHSA-2026:41234
- https://access.redhat.com/errata/RHSA-2026:41235
- https://access.redhat.com/errata/RHSA-2026:42919
- https://access.redhat.com/errata/RHSA-2026:43231
- https://access.redhat.com/errata/RHSA-2026:44385
- https://access.redhat.com/errata/RHSA-2026:47632
- https://access.redhat.com/errata/RHSA-2026:47633
- https://access.redhat.com/errata/RHSA-2026:47739
- https://access.redhat.com/errata/RHSA-2026:47869
- https://access.redhat.com/errata/RHSA-2026:49033
- https://access.redhat.com/security/cve/CVE-2026-46116
- https://bugzilla.redhat.com/show_bug.cgi?id=2482523
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46116.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/159f2efabc89d3f931d38f2d35876535d4abf0a3
- https://git.kernel.org/stable/c/9cc0c6b1ba8cd5c55aef043e1384de0a8b4efa71
- https://git.kernel.org/stable/c/9ef65af26b2a6738bf15812042e84b3112402d3a
- https://git.kernel.org/stable/c/db991ba50087ad99fa12a2c483aa3be19671ea73
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/errata/RHSA-2026:30129
- https://access.redhat.com/errata/RHSA-2026:42550
- https://access.redhat.com/errata/RHSA-2026:42552
- https://access.redhat.com/security/cve/CVE-2026-46117
- https://bugzilla.redhat.com/show_bug.cgi?id=2482576
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46117.json
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). Thereafter, an attempt is made to send the preallocated message of type CEPH_MSG_AUTH, where the returned value is interpreted as the size of the front segment to send. If the result value in the message is greater than the size of the memory buffer allocated for the front segment, an out-of-bounds access occurs, and the content of the memory region beyond this buffer is sent out. This patch fixes the issue by treating only negative values in the result field as errors. Positive values are therefore treated as success in the same way as a zero value. Additionally, a BUG_ON is added to __send_prepared_auth_request() comparing the len parameter to front_alloc_len to prevent sending the message if it exceeds the bounds of the allocation and to make it easier to catch any logic flaws leading to this.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/1c439de70b1c3eb3c6bffa8245c16b9fc318f114
- https://git.kernel.org/stable/c/2ae0afd98432536562fa8261538ae795446f0589
- https://git.kernel.org/stable/c/38fdf04c602d52c42c67fc1617211492753b7e8b
- https://git.kernel.org/stable/c/408e85ee708b6aa03eeb0220ffa0915f4d407181
- https://git.kernel.org/stable/c/8517b6c8d2c759918ba0058cb6c7e14d59643202
- https://git.kernel.org/stable/c/b7df9fbd4869fdfe09a3f501ffd228486521e062
- https://git.kernel.org/stable/c/c2374b92c729d0388a538b3cde7b3e3b5e55ef39
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ip6_gre: Use cached t->net in ip6erspan_changelink(). After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns ip6gre hash via link_net. ip6erspan_changelink() was not converted in that series and still uses dev_net(dev), which diverges from the device's creation netns after IFLA_NET_NS_FD migration. This re-inserts the tunnel into the wrong per-netns hash. The original netns keeps a stale entry. When that netns is later destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a slab-use-after-free reported by KASAN, followed by a kernel BUG at net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify(). Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). ip6gre_changelink() earlier in the same file already uses the cached t->net; only ip6erspan_changelink() has the wrong shape.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/01b71ff2857d3598337de11e7840a8e3ff21553c
- https://git.kernel.org/stable/c/0fcf6731706f73494245a9c0d64f93bebf95bb51
- https://git.kernel.org/stable/c/1d324c2f43f70c965f25c58cc3611c779adbe47e
- https://git.kernel.org/stable/c/311fdd26eb4443d43b909cc67a10f3a5fd1b21b2
- https://git.kernel.org/stable/c/7bd0f2b162b426b343a114e1b329f0d8d14fdc6e
- https://git.kernel.org/stable/c/cf7fc624329e76c6394653d12353e1d033adea91
- https://git.kernel.org/stable/c/e70cfb40c3a99b232cd42c6a6a10f0d8e039dc82
- https://git.kernel.org/stable/c/eca62bb0569de4d43a4dac06a2092a9d4ca1d702
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock Patch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path". Reads of 'memcg_path' and 'path' files in DAMON sysfs interface could race with their writes, results in use-after-free. Fix those. This patch (of 2): damon_sysfs_scheme_filter->mmecg_path can be read and written by users, via DAMON sysfs memcg_path file. It can also be indirectly read, for the parameters {on,off}line committing to DAMON. The reads for parameters committing are protected by damon_sysfs_lock to avoid the sysfs files being destroyed while any of the parameters are being read. But the user-driven direct reads and writes are not protected by any lock, while the write is deallocating the memcg_path-pointing buffer. As a result, the readers could read the already freed buffer (user-after-free). Note that the user-reads don't race when the same open file is used by the writer, due to kernfs's open file locking. Nonetheless, doing the reads and writes with separate open files would be common. Fix it by protecting both the user-direct reads and writes with damon_sysfs_lock.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1e68eb96e8beb1abefd12dd22c5637795d8a877e
- https://git.kernel.org/stable/c/b1e9f2d5870776347edef927f9bb3ea19b8e3abb
- https://git.kernel.org/stable/c/baecc45ad60e621ef14d6c1e7f41ef36bbfdf910
- https://git.kernel.org/stable/c/c88802d0e8edd14b6cd2daf3000f99adbc4c85c5
- https://git.kernel.org/stable/c/eafd6f5372d29b0dd213799b92c2c9c7ad31d7da
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: b43: enforce bounds check on firmware key index in b43_rx() The firmware-controlled key index in b43_rx() can exceed the dev->key[] array size (58 entries). The existing B43_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read. Make the B43_WARN_ON check enforcing by dropping the frame when the firmware returns an invalid key index.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/135cb49c9a42a02cceeac7b49ec03e267f7ed6d6
- https://git.kernel.org/stable/c/1e9e55cf66f0fa4799f4d86ef3aaba8e606b5c14
- https://git.kernel.org/stable/c/1f4f78bf8549e6ac4f04fba4176854f3a6e0c332
- https://git.kernel.org/stable/c/219ba67e69e49681e48c822d6eaafb5def032f34
- https://git.kernel.org/stable/c/3157ad40b084a8f3932da2641749ab45e99b933e
- https://git.kernel.org/stable/c/765709720e6af9a178abc40244a8d1aa39ac4e71
- https://git.kernel.org/stable/c/c3d7b90dc95020cd9282c4630e402fe224f7644e
- https://git.kernel.org/stable/c/d7029879bafdac2006c67553807d122283dc6cbf
HIGH7.7
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: clamp rx length before skb_put virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length.
CVSS 3.xHIGH 7.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/21bd244b6de5d2fe1063c23acc93fbdd2b20d112
- https://git.kernel.org/stable/c/4236e55b2d9d1ffd3b4bdf8ebbb86e5a0a526b4a
- https://git.kernel.org/stable/c/6c1730099a6fc18b183bd6c1adad3b54adcaeda9
- https://git.kernel.org/stable/c/b40cdd1b1370d76e9e760af4490cb4a351cceead
- https://git.kernel.org/stable/c/e6b4296f170d949ebba937cf6a3f247ec9550d2c
- https://git.kernel.org/stable/c/ed41c81d30b211a671667259c3b5feeba0e062d5
- https://git.kernel.org/stable/c/fd91fa2678ab603dfb285416c1cf3843d7be1e41
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: isofs: validate block number from NFS file handle in isofs_export_iget isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker- controlled block number (ifid->block or ifid->parent_block) from the NFS file handle to isofs_export_iget(), which only rejects block == 0 before calling isofs_iget() and ultimately sb_bread(). A crafted file handle with fh_len sufficient to pass the check added by commit 0405d4b63d08 ("isofs: Prevent the use of too small fid") can still drive the server to read any in-range block on the backing device as if it were an iso_directory_record. That earlier fix was assigned CVE-2025-37780. sb_bread() on an out-of-range block returns NULL cleanly via the EIO path, so there is no memory-safety violation. For in-range reads of adjacent-partition data on the same block device, the unrelated bytes end up in iso_inode_info fields that reach the NFS client as dentry metadata. The deployment surface (isofs exported over NFS from loop-mounted images) is narrow and requires an authenticated NFS peer, but the malformed-file-handle class is reportable as hardening next to the existing CVE-2025-37780 fix. Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent() call sites with a single line.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
- https://git.kernel.org/stable/c/0a1af74ae2177bda3aee0837a0546309aa539d0d
- https://git.kernel.org/stable/c/24376458138387fb251e782e624c7776e9826796
- https://git.kernel.org/stable/c/31dbb4ba0f719ae7774e4c0c95172c9bf81692f5
- https://git.kernel.org/stable/c/4c721a1d9b3c4fcaf59cc9b2281e3ec5a043e1a6
- https://git.kernel.org/stable/c/908a76f0b1038035e6ebb4f2293ce079f92e0a02
- https://git.kernel.org/stable/c/afbafeddf23db13fe2edb2d5c0bf4bbb13d7881b
- https://git.kernel.org/stable/c/bb0988ed4f2e26d59bbb58f644cb3a55b7521e21
- https://git.kernel.org/stable/c/ee0024f5a7e3c73aa253869fae9650ae054093ca
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: remove station if connection prep fails If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "new_sta" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/18fed0a209500bfea5c4c08609ec93855e4e500b
- https://git.kernel.org/stable/c/1c2b72ea89882aeb948340498391e69c58d466f1
- https://git.kernel.org/stable/c/283fc9e44ff5b5ac967439b4951b80bd4299f4e4
- https://git.kernel.org/stable/c/9e28654f79f443bca9b29ff3ae7cf18abfba58a0
- https://git.kernel.org/stable/c/afcbaed89cdc1a001b43270cbf5394bb4804270a
- https://git.kernel.org/stable/c/fe75fa1ac9a92990f7fc3d34b17808fd933071b2
- https://access.redhat.com/errata/RHSA-2026:26427
- https://access.redhat.com/errata/RHSA-2026:26428
- https://access.redhat.com/errata/RHSA-2026:26462
- https://access.redhat.com/errata/RHSA-2026:26515
- https://access.redhat.com/errata/RHSA-2026:26563
- https://access.redhat.com/errata/RHSA-2026:27288
- https://access.redhat.com/errata/RHSA-2026:27708
- https://access.redhat.com/errata/RHSA-2026:27731
- https://access.redhat.com/errata/RHSA-2026:27735
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/security/cve/CVE-2026-46125
- https://bugzilla.redhat.com/show_bug.cgi?id=2482608
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46125.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss() Sashiko points out there are two bugs here in the error unwind flow, both related to how the WQ table is unwound. First there is a double i-- on the first failure path due to the while loop having a i--, remove it. Second if mana_ib_install_cq_cb() fails then mana_create_wq_obj() is not undone due to the above i--.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp() Sashiko points out that pd->uctx isn't initialized until late in the function so all these error flow references are NULL and will crash. Use the uctx that isn't NULL.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/27b6eb1f27fda9bdd5cae028e396758cdf525845
- https://git.kernel.org/stable/c/34fbf48cf3b410d2a6e8c586fa952a36331ca5ba
- https://git.kernel.org/stable/c/443c991fbc954cc9363e963c09f404b9f281f3a2
- https://git.kernel.org/stable/c/75fc130664ae324e7b2f9ad3630e0f175e9ca6c8
- https://git.kernel.org/stable/c/8832626a483439e207734e027afff322ccdf726e
- https://git.kernel.org/stable/c/b610f33c5523fe26f6dd897667fff9c7a1de5905
- https://git.kernel.org/stable/c/e01a957561f663d3b68d2fd233a4502e3367efcd
- https://git.kernel.org/stable/c/ec44c00a4fe1327efa35083f98b39c01cb535a51
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipmi: Check event message buffer response for bad data The event message buffer response data size got checked later when processing, but check it right after the response comes back. It appears some BMCs may return an empty message instead of an error when fetching events. There are apparently some new BMCs that make this error, so we need to compensate.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/01f8387fa5b796f13cf50014c171f6da7abc46ea
- https://git.kernel.org/stable/c/2418e4b21fb1355504d095da5d5f0a210564a43d
- https://git.kernel.org/stable/c/24269264c3d59a49eb09b10af2c75b14f2931482
- https://git.kernel.org/stable/c/36920f30e78e69df01f9691c470b6f3ba8aebf98
- https://git.kernel.org/stable/c/42432b579a594b66ac32e5e7b7c26e6bc578ec89
- https://git.kernel.org/stable/c/474e53d4397087913a5b9c9eb90fa068da4808bf
- https://git.kernel.org/stable/c/7f7ada72c07a83b46045ddfeee526bd9e2e3c8f0
- https://git.kernel.org/stable/c/cf1ef30c42a7079e5bad863cd01c52aa3a17c3ac
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info() error path When kobject_init_and_add() fails, the call chain is: create_space_info() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&space_info->kobj) -> space_info_release() -> kfree(space_info) Then control returns to create_space_info(): btrfs_sysfs_add_space_info_type() returns error -> goto out_free -> kfree(space_info) This causes a double free. Keep the direct kfree(space_info) for the earlier failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3f487be81292702a59ea9dbc4088b3360a50e837
- https://git.kernel.org/stable/c/9a060970fd7b5e1c561e4ce73cb9949e4269a738
- https://git.kernel.org/stable/c/ae6d6e31ceb72b7697c28a528e4923c08e3c2ef5
- https://git.kernel.org/stable/c/c2670ec4aa49ca226bce9776601e0da37502be07
- https://git.kernel.org/stable/c/dd6ade0fdd59218d71a981ae7c937a304e49209c
- https://git.kernel.org/stable/c/f414b3abbba59ef379a2b3c31f2bdd9358ed5e53
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: check for nEPT/nNPT in slow flush hypercalls Checking is_guest_mode(vcpu) is incorrect, because translate_nested_gpa() is only valid if an L2 guest is running *with nested EPT/NPT enabled*. Instead use the same condition as translate_nested_gpa() itself.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/45fc766bc756ff1d66f8ca026a9c4f7f764adfae
- https://git.kernel.org/stable/c/464af6fc2b1dcc74005b7f58ee3812b17777efee
- https://git.kernel.org/stable/c/4c7f8436b19a2a3acc0cb6b6e3becd6796ae5c57
- https://git.kernel.org/stable/c/971f17f5d91045404e3914029ea57c3da90179a4
- https://git.kernel.org/stable/c/d6f4e217d663ede5becc2fd6cb612c749677387b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack without initialisation: struct ifla_vf_broadcast vf_broadcast; The struct contains a single fixed 32-byte field: /* include/uapi/linux/if_link.h */ struct ifla_vf_broadcast { __u8 broadcast[32]; }; The function then copies dev->broadcast into it using dev->addr_len as the length: memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len); On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via: nla_put(skb, IFLA_VF_BROADCAST, sizeof(vf_broadcast), &vf_broadcast) leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK request, repeatable. The other vf_* structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nla_put() when reproduced. Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf_* structs in the same function.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0653c0516234c8258975d268a749115fc0f0ff00
- https://git.kernel.org/stable/c/14271b401ec6a4bf0d88054106fc2956084717e1
- https://git.kernel.org/stable/c/38bcc21f52246badb3154b6158dcb381d98de011
- https://git.kernel.org/stable/c/4b9e327991815e128ad3af75c3a04630a63ce3e0
- https://git.kernel.org/stable/c/a44fbb631cba646532f3948636626f81717365a7
- https://git.kernel.org/stable/c/c5b1b92ab7eff1a6e8c507ddde6fd02fabd0cfa8
- https://git.kernel.org/stable/c/cccce3190ba4356432b9f22369b56123d3d89f0d
- https://git.kernel.org/stable/c/fbe0e6197225e6a83cf113a67a4b425f8de0bcd5
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject unknown opcodes before ICRC processing Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv"), a single unauthenticated UDP packet can still trigger panic. That patch handled payload_size() underflow only for valid opcodes with short packets, not for packets carrying an unknown opcode. The unknown-opcode OOB read described below predates that commit and reaches back to the initial Soft RoCE driver. The check added there reads pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE where header_size(pkt) expands to rxe_opcode[pkt->opcode].length. The rxe_opcode[] array has 256 entries but is only populated for defined IB opcodes; any other entry (for example opcode 0xff) is zero-initialized, so length == 0 and the check degenerates to pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE which does not constrain pkt->paylen enough. rxe_icrc_hdr() then computes rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES which underflows when length == 0 and passes a huge value to rxe_crc32(), causing an out-of-bounds read of the skb payload. Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after rdma link add rxe0 type rxe netdev eth0 A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and QPN=IB_MULTICAST_QPN triggers: BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170 Read of size 1 at addr ... The buggy address is located 0 bytes to the right of allocated 704-byte region Call Trace: crc32_le+0x115/0x170 rxe_icrc_hdr.isra.0+0x226/0x300 rxe_icrc_check+0x13f/0x3a0 rxe_rcv+0x6e1/0x16e0 rxe_udp_encap_recv+0x20a/0x320 udp_queue_rcv_one_skb+0x7ed/0x12c0 Subsequent packets with the same shape fault on unmapped memory and panic the kernel. The trigger requires only module load and "rdma link add"; no QP, no connection, and no authentication. Fix this by rejecting packets whose opcode has no rxe_opcode[] entry, detected via the zero mask or zero length, before any length arithmetic runs.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/006a3a5f75345c6a0dbf13fd3ee01406e93b6733
- https://git.kernel.org/stable/c/318787fa7193bd79691f2ebce4e80cb6abd0faef
- https://git.kernel.org/stable/c/4c6f86d85d03cdb33addce86aa69aa795ca6c47a
- https://git.kernel.org/stable/c/599cfdf44c1701c581cd4a21f1e1e03f8dc3840b
- https://git.kernel.org/stable/c/6a79b1ea0fcb2c998fda6a793050f66146e9cc42
- https://git.kernel.org/stable/c/6fa18025e5782afff91415fd5217b39c1e4837d7
- https://git.kernel.org/stable/c/e3dc3a2fb05f4ed49c7f20594c4c52350d032189
- https://git.kernel.org/stable/c/f8ee926431a7bbec2b10c1290664af2cb290b983
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/49891c8fe0cb43fbbe480da1cdccfbbaeb820cb3
- https://git.kernel.org/stable/c/5293a8882c549fab4a878bc76b0b6c951f980a61
- https://git.kernel.org/stable/c/5f0b95ef68ab9afba75b20eebf436130f80c161a
- https://git.kernel.org/stable/c/67e1aaf93b495c2f10bc8a5fbba575fbb7f449b6
- https://git.kernel.org/stable/c/6f96dea4819d122737b217ea16660d255abbf8c6
- https://git.kernel.org/stable/c/9c63cf80895a70eb4fcfcaa725bb1ac9ae76f02b
- https://git.kernel.org/stable/c/b7dd4d27aa70bd98bb10572310e913668baf6a65
- https://git.kernel.org/stable/c/dcfe4d1f7960e7d1c01642318f3aae1a604f8508
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix a potential clc buffer length underflow The buf_len is used to limit the iterations for retrieving the country power setting and may underflow under certain conditions due to changes in the power table in CLC. This underflow leads to an almost infinite loop or an invalid power setting resulting in driver initialization failure.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0aa63d33742b805d1a218d18d12b983cce4b2f7b
- https://git.kernel.org/stable/c/2a79b1a492bcfa725383b6580cd93a6862308c85
- https://git.kernel.org/stable/c/5373f8b19e568b5c217832b9bbef165bd2b2df14
- https://git.kernel.org/stable/c/90cc573fd2f46ddbc2c329e7814b5ba3deb7b939
- https://git.kernel.org/stable/c/a0111847f0b4f6023f6dd320114697514e024ba3
- https://git.kernel.org/stable/c/e451c325b000b9a0081fd93bc6d103d6943d4b55
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: fix potential data-race This mptcp_pm_add_timer() helper is executed as a timer callback in softirq context. To avoid any data races, the socket lock needs to be held with bh_lock_sock(). If the socket is in use, retry again soon after, similar to what is done with the keepalive timer.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/013dcdc1961543b9a3433466bc8c79a2f4ca75b5
- https://git.kernel.org/stable/c/23079e0b7742ec114d3507c3e3aad01b7b69e4af
- https://git.kernel.org/stable/c/2ad56e434199ca24a812bb353667aa1c3860f513
- https://git.kernel.org/stable/c/5cd6e0ad79d2615264f63929f8b457ad97ae550d
- https://git.kernel.org/stable/c/6e4710d7d8782cb61af29a7e7111ddfc38b9e1a3
- https://git.kernel.org/stable/c/b35605e1f1e877038c8c9d499babbc891cdd234f
- https://git.kernel.org/stable/c/cc3c0399361efaaf7ae64262eb3f70829b1189c6
- https://git.kernel.org/stable/c/d9b272a85fe6b8f993e37915311e4038c814a533
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt hci_le_create_big_complete_evt() iterates over BT_BOUND connections for a BIG handle using a while loop, accessing ev->bis_handle[i++] on each iteration. However, there is no check that i stays within ev->num_bis before the array access. When a controller sends a LE_Create_BIG_Complete event with fewer bis_handle entries than there are BT_BOUND connections for that BIG, or with num_bis=0, the loop reads beyond the valid bis_handle[] flex array into adjacent heap memory. Since the out-of-bounds values typically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle() rejects them and the connection remains in BT_BOUND state. The same connection is then found again by hci_conn_hash_lookup_big_state(), creating an infinite loop with hci_dev_lock held. Fix this by terminating the BIG if in case not all BIS could be setup properly.
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/22559ad7654f61727fc270ee4893da9f4b70cf17
- https://git.kernel.org/stable/c/5ddb8014261137cadaf83ab5617a588d80a22586
- https://git.kernel.org/stable/c/665da0baaf0396f9ed3c86ccb3955dcd0b73e774
- https://git.kernel.org/stable/c/6cb7f67bc28da787499291a562d49a084d9c90cd
- https://git.kernel.org/stable/c/77981a507aa0fc001dc37f0dd6631dd2042fed17
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: smb: client: use kzalloc to zero-initialize security descriptor buffer Commit 62e7dd0a39c2d ("smb: common: change the data type of num_aces to le16") split struct smb_acl's __le32 num_aces field into __le16 num_aces and __le16 reserved. The reserved field corresponds to Sbz2 in the MS-DTYP ACL wire format, which must be zero [1]. When building an ACL descriptor in build_sec_desc(), we are using a kmalloc()'ed descriptor buffer and writing the fields explicitly using le16() writes now. This never writes to the 2 byte reserved field, leaving it as uninitialized heap data. When the reserved field happens to contain non-zero slab garbage, Samba rejects the security descriptor with "ndr_pull_security_descriptor failed: Range Error", causing chmod to fail with EINVAL. Change kmalloc() to kzalloc() to ensure the entire buffer is zero-initialized. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/20233ed8-a6c6-4097-aafa-dd545ed24428
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4c3ed344a970aad51388ac3b0145b98318f0e21f
- https://git.kernel.org/stable/c/5e489c6c47a2ac15edbaca153b9348e42c1eacab
- https://git.kernel.org/stable/c/941a1e6eb35440336913afc88a82103291956d5d
- https://git.kernel.org/stable/c/9bdb2ca31368b7671949dfb94a5d57ffccd01edd
- https://git.kernel.org/stable/c/be1ef9512a3f5a755895c24f31b334342f4aa15b
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtk: validate WMT event SKB length before struct access btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom. Use skb_pull_data() to validate and advance past the base WMT event header. For the FUNC_CTRL case, pull the additional status field bytes before accessing them.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/36c85f7029484d5ede769f8873d16e9c8e35533c
- https://git.kernel.org/stable/c/624fb79dadc1b65757986a9d0fdde5c0cf3fe179
- https://git.kernel.org/stable/c/634a4408c0615c523cf7531790f4f14a422b9206
- https://git.kernel.org/stable/c/70d37a8b9229e394cc17ddad47e90b81d80fcd09
- https://git.kernel.org/stable/c/c411cf1bfde951cfa821809cf4020ba177f76e0c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix VF illegal register access Register WX_CFG_PORT_ST is a PF restricted register. When a VF is initialized, attempting to read this register triggers an illegal register access, which lead to a system hang. When the device is VF, the bus function ID can be obtained directly from the PCI_FUNC(pdev->devfn).
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/33c5bb50b9c40e8451e6aec4487a31d794b98d92
- https://git.kernel.org/stable/c/68a007a701bc06fa426507c551ef12514f2e721d
- https://git.kernel.org/stable/c/694de316f607fe2473d52ca0707e3918e72c1562
- https://git.kernel.org/stable/c/d3bd8040497968f6f5470018724ef7b0df92f707
- https://git.kernel.org/stable/c/f6e656f7cea16b638675a2ab7d7e4cf2516c5eb0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens As prepare can be called mulitple times, this can result in multiple graph opens for playback path. This will result in a memory leaks, fix this by adding a check before opening.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3141d8b00cad6d3331953c79060ccc3a0262311b
- https://git.kernel.org/stable/c/69acc488aaf39d0ddf6c3cf0e47c1873d39919a2
- https://git.kernel.org/stable/c/7cab9f2ad51c858263da836baebad050a1bc7914
- https://git.kernel.org/stable/c/af9cc7c622e596455c5190e6ef53c5b40ea7a90d
- https://git.kernel.org/stable/c/b97493f0f42ab9d882a62466782e1900e481a9d6
- https://git.kernel.org/stable/c/c91b7bcc70346d07f57ef03d1b9a338324e213de
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Fix error unwind in mana_ib_create_qp_rss() Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal destroy path cleans it up.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/190e570cc0fc7f57eacf80d2b854ba54b4dfad6b
- https://git.kernel.org/stable/c/30e8a2f33815d8f51b8f8b829c07af16c671cc27
- https://git.kernel.org/stable/c/6aaa978c6b6218cfac15fe1dab17c76fe229ce3f
- https://git.kernel.org/stable/c/726af85ea4af750b2f75095e24e3cd99797344cb
- https://git.kernel.org/stable/c/ab64c63b460bbd0521480bf90d5695783f5e66bc
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/012796f9541fcd0c1fa8ae4da7eb4d83931ef838
- https://git.kernel.org/stable/c/11c1431d641e0e4e0529e96957995820600c7287
- https://git.kernel.org/stable/c/6dd2d4ad9c8429523b1c220c5132bd551c006425
- https://git.kernel.org/stable/c/7d7c9f0fcd19c4d2f0164347c58d49cafa961b72
- https://git.kernel.org/stable/c/7d94f155f354b961c598f71bafa804dceded513f
- https://access.redhat.com/errata/RHSA-2026:27353
- https://access.redhat.com/errata/RHSA-2026:27354
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/errata/RHSA-2026:30129
- https://access.redhat.com/security/cve/CVE-2026-46145
- https://bugzilla.redhat.com/show_bug.cgi?id=2482581
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46145.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3() The convert_chmap_v3() has a loop with its increment size of cs_desc->wLength, but we forgot to validate cs_desc->wLength itself, which may lead to potential endless loop by a malformed descriptor. Add a proper size check to abort the loop for plugging the hole.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/076d5d13eb9c1ad259a7f246149f6676c62285f9
- https://git.kernel.org/stable/c/24a40df79307ca7ca0eec0889361cf6ac146d72a
- https://git.kernel.org/stable/c/316aa0b1e3c5600eae5ab876394c1ac70e6db581
- https://git.kernel.org/stable/c/4e0ee232ebe3df04874125d7c7f3e6c25ea5483d
- https://git.kernel.org/stable/c/6e7247d8f5fefeceb0bb9cc80a5388a636b219cd
- https://git.kernel.org/stable/c/be09b47ed8677d76962e3240c145502e2ad9f3c8
- https://git.kernel.org/stable/c/e0e3dcf48189603f3865f1a0b799b3b42baae96d
- https://git.kernel.org/stable/c/fa5b19ce69067874b1413f3c2027563bae8c2cb3
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show() target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered. Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/00d91bfdce5033f5d9b4915638ae9b0553848b5d
- https://git.kernel.org/stable/c/12f2201a56957ba020392223a7393a5eba080c1b
- https://git.kernel.org/stable/c/1f678d13e939f91840cb1ebe9b88544923539d3c
- https://git.kernel.org/stable/c/72cc5ea7ef32bb5fa38bf0dd2e56fcd73aa8c89e
- https://git.kernel.org/stable/c/772a896a56e0e3ef9424a025cec9176f9d8f4552
- https://git.kernel.org/stable/c/d3cc9d490c207d57a289054397349f6f8c90354e
- https://git.kernel.org/stable/c/db0a4759d62cad4ff891e2d81ae4be73bb57f4a4
- https://git.kernel.org/stable/c/e501154f9d82c95d2719bcbbaf679d8fd3226ef7
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NReferences
- https://git.kernel.org/stable/c/04bb66be92f48ed13c3faf1139d892df228789bc
- https://git.kernel.org/stable/c/4a7611ad653785fcdea5ff5f4441e2b7d05b7f11
- https://git.kernel.org/stable/c/7746e3bd4cc19b5092e00d32d676e329bfcb6900
- https://git.kernel.org/stable/c/7baa02b0ae9d17ec5f08836d8ea88ce1927d0678
- https://git.kernel.org/stable/c/895ebbedf88318607c24acc0f591c74b165e1d0a
- https://git.kernel.org/stable/c/a24765332e129c1916d5a6615418b75599b8fcdc
- https://git.kernel.org/stable/c/b7b24b28c8cd55844cab908f4f39dded638d5538
- https://git.kernel.org/stable/c/f130790f1acc8399f32652846c875a251efd040f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix heap leak in IEEE 1284 device ID via short response usblp_ctrl_msg() collapses the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GET_DEVICE_ID control transfer short and the driver has no way to know. usblp_cache_device_id_string() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves device_id_string[2..1022] holding stale kmalloc heap. That stale data is then exposed: - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device. Fix this up by just zapping the buffer with zeros before each request sent to the device.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4220d4dd062ea3d3eb056a6cbe0b568e740d20b1
- https://git.kernel.org/stable/c/4650cce898fcd0bb8c33e529984687a8caed10c3
- https://git.kernel.org/stable/c/522d17e93a85575256894212d10e5a1fa6f36529
- https://git.kernel.org/stable/c/612640abbd9e0947fe8f37aaf0cf324265d7caa4
- https://git.kernel.org/stable/c/6d8142141c942c0d8e79343cffda9c44bb1f3f4f
- https://git.kernel.org/stable/c/6e29c32a27218f2dcd4a4e9b0b3c5e7728640698
- https://git.kernel.org/stable/c/7a400c6fe3617e31e690e3f7ca37bb335e0498f3
- https://git.kernel.org/stable/c/8247f52d822180e94ccbfdab91613af386a4e34d
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop stray 'static' from fast-RX rx_result ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/03584528bfffb195e384698af9148b94e42e3f14
- https://git.kernel.org/stable/c/1739fc31b4de06c5c78ce0741182770fb079091e
- https://git.kernel.org/stable/c/3ef44f96ccc3e06e059dec57842e366f0c4b1893
- https://git.kernel.org/stable/c/7a5b81e0c87a075afd572f659d8eb68c9c4cd2ba
- https://git.kernel.org/stable/c/e131562d6f2b958148c35c98831b007f47f0e3d3
- https://access.redhat.com/errata/RHSA-2026:26427
- https://access.redhat.com/errata/RHSA-2026:26428
- https://access.redhat.com/errata/RHSA-2026:27288
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/errata/RHSA-2026:36767
- https://access.redhat.com/errata/RHSA-2026:38902
- https://access.redhat.com/errata/RHSA-2026:44694
- https://access.redhat.com/security/cve/CVE-2026-46152
- https://bugzilla.redhat.com/show_bug.cgi?id=2482563
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46152.json
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in smb2_compound_op() If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, check_wsl_eas() returns success without validating that the entire OutputBufferLength fits within iov_len. Then smb2_compound_op() does: memcpy(idata->wsl.eas, data[0], size[0]); Where size[0] is OutputBufferLength. If iov_len is smaller than size[0], memcpy can read beyond the end of the rsp_iov allocation and leak adjacent kernel heap memory.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/512d33bc8ea4ea5c19728ee118715f4b1f4d1926
- https://git.kernel.org/stable/c/8d09328dfda089675e4c049f3f256064a1d1996b
- https://git.kernel.org/stable/c/9b3af35645ff9cd334edc130249f9a2fb2bea25f
- https://git.kernel.org/stable/c/a16f70a71be4b5a4eccf39a9bf09b47285f4cb7c
- https://git.kernel.org/stable/c/dffb44b2e06a2908e249f0f93156fc987eee1d1c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU: lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ... Add a default switch case to fix the panic as below: Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210 ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210 [<9000000000eebc08>] pci_fixup_device+0x108/0x280 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280 [<900000000189c028>] acpi_scan_init+0x194/0x310 [<900000000189bc6c>] acpi_init+0xcc/0x140 [<9000000000220cdc>] do_one_initcall+0x4c/0x310 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4 [<900000000184326c>] kernel_init+0x28/0x13c [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/07d190e4ec689d6478f7f5e36099fb9bf457e7c5
- https://git.kernel.org/stable/c/2cb19b06c09983727573bbe7d7430cbad480a714
- https://git.kernel.org/stable/c/81fef1c278436e6bd68ee4ca05a0acb96e256561
- https://git.kernel.org/stable/c/8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e
- https://git.kernel.org/stable/c/9e1aed63a5552958ef2a9bfd699a3f990e52a77f
- https://git.kernel.org/stable/c/bfde8accc3e3260c0ecbb8cc34361739e1e16f31
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4fdc6ee0802121d9cd96b8d085e589f51e5a4ec3
- https://git.kernel.org/stable/c/5d12e0ab009ade48c1bff9324fd9bea2c773d088
- https://git.kernel.org/stable/c/973e57c726c1f8e77259d1c8e519519f1e9aea77
- https://git.kernel.org/stable/c/d09d67d5de577cedae3de9497dff217e0ac8b641
- https://git.kernel.org/stable/c/d69a4a6813fdba7c4cc3695a7e843842b240790d
- https://git.kernel.org/stable/c/d8224b1be6627c6c3b204bfb264508d27c65ac44
- https://git.kernel.org/stable/c/f407aad350bdea4db300c47433573b7a41630d33
- https://git.kernel.org/stable/c/f5ee467b56764964027c361641f64953fc0f8f9a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix missing last_unlink_trans update when removing a directory
When removing a directory we are not updating its last_unlink_trans field,
which can result in incorrect fsync behaviour in case some one fsyncs the
directory after it was removed because it's holding a file descriptor on
it.
Example scenario:
mkdir /mnt/dir1
mkdir /mnt/dir1/dir2
mkdir /mnt/dir3
sync -f /mnt
# Do some change to the directory and fsync it.
chmod 700 /mnt/dir1
xfs_io -c fsync /mnt/dir1
# Move dir2 out of dir1 so that dir1 becomes empty.
mv /mnt/dir1/dir2 /mnt/dir3/
open fd on /mnt/dir1
call rmdir(2) on path "/mnt/dir1"
fsync fd
When attempting to mount the filesystem, the log replay will fail with
an -EIO error and dmesg/syslog has the following:
[445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650
[445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm
[445771.627912] BTRFS info (device dm-0): start tree-log replay
[445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5
[445771.629453] memcg:ffff89f400351b00
[445771.629892] aops:btree_aops [btrfs] ino:1
[445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)
[445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8
[445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00
[445771.635029] page dumped because: eb page dump
[445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir
[445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5
[445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087
[445771.638094] item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
[445771.638097] inode generation 3 transid 9 size 16 nbytes 16384
[445771.638098] block group 0 mode 40755 links 1 uid 0 gid 0
[445771.638100] rdev 0 sequence 2 flags 0x0
[445771.638102] atime 1775744884.0
[445771.660056] ctime 1775744885.645502983
[445771.660058] mtime 1775744885.645502983
[445771.660060] otime 1775744884.0
[445771.660062] item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
[445771.660064] index 0 name_len 2
[445771.660066] item 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34
[445771.660068] location key (259 1 0) type 2
[445771.660070] transid 9 data_len 0 name_len 4
[445771.660075] item 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34
[445771.660076] location key (257 1 0) type 2
[445771.660077] transid 9 data_len 0 name_len 4
[445771.660078] item 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34
[445771.660079] location key (257 1 0) type 2
[445771.660080] transid 9 data_len 0 name_len 4
[445771.660081] item 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34
[445771.660082] location key (259 1 0) type 2
[445771.660083] transid 9 data_len 0 name_len 4
[445771.660084] item 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160
[445771.660086] inode generation 9 transid 9 size 8 nbytes 0
[445771.660087] block group 0 mode 40777 links 1 uid 0 gid 0
[445771.660088] rdev 0 sequence 2 flags 0x0
[445771.660089] atime 1775744885.641174097
[445771.660090] ctime 1775744885.645502983
[445771.660091] mtime 1775744885.645502983
[445771.660105] otime 1775744885.641174097
[445771.660106] item 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14
[445771.660107] index 2 name_len 4
[445771.660108] item 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34
[445771.660109] location key (2
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2525998ac956476bded26b9f34c4164dc890b87a
- https://git.kernel.org/stable/c/36fcc2c7517f8a86379154c9793f867592aa8b7e
- https://git.kernel.org/stable/c/6acbb2f6dff23c9bb9761fb98b516525b9cf1ce9
- https://git.kernel.org/stable/c/999757231c49376cd1a37308d2c8c4c9932571e1
- https://git.kernel.org/stable/c/aa9c3ecaf7337df3a689318584f879b5339ede0f
- https://git.kernel.org/stable/c/af467162290f5fe79d6a361b7c84302e45b1fd9f
- https://git.kernel.org/stable/c/cc3c0a0f965754ce230d93ba44ee5b34fbe6138a
- https://git.kernel.org/stable/c/fb388eb58c1ba047ccabc33901839acfecadcf49
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies setup_geo() extracts near_copies (nc) and far_copies (fc) from the user-provided layout parameter without checking for zero. When fc=0 with the "improved" far set layout selected, 'geo->far_set_size = disks / fc' triggers a divide-by-zero. Validate nc and fc immediately after extraction, returning -1 if either is zero.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b43a70394ce492274e67463326be03e0a9897c5
- https://git.kernel.org/stable/c/4af2e558e6fdfb972c61350653fd55d1f62b60a5
- https://git.kernel.org/stable/c/553e32adfa1a96b217651139a3f8c3b92b9984ac
- https://git.kernel.org/stable/c/913d556e4bd1b56ed822815655b82c7bb54edc51
- https://git.kernel.org/stable/c/9aa6d860b0930e2f72795665c42c44252a558a0c
- https://git.kernel.org/stable/c/9d8e03b9a2b1e8ce5c198bf3a409a629f4d02cda
- https://git.kernel.org/stable/c/c716ab3034f84f8a6c226814247b8c5ac9f95da1
- https://git.kernel.org/stable/c/f9ddb621b2325eb69c95692958daf2bab4dea2c4
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ice: fix double free in ice_sf_eth_activate() error path When auxiliary_device_add() fails, ice_sf_eth_activate() jumps to aux_dev_uninit and calls auxiliary_device_uninit(&sf_dev->adev). The device release callback ice_sf_dev_release() frees sf_dev, but the current error path falls through to sf_dev_free and calls kfree(sf_dev) again, causing a double free. Keep kfree(sf_dev) for the auxiliary_device_init() failure path, but avoid falling through to sf_dev_free after auxiliary_device_uninit().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: b43legacy: enforce bounds check on firmware key index in RX path Same fix as b43: the firmware-controlled key index in b43legacy_rx() can exceed dev->max_nr_keys. The existing B43legacy_WARN_ON is non-enforcing in production builds, allowing an out-of-bounds read of dev->key[]. Make the check enforcing by dropping the frame for invalid indices.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1baaeb6adecb9691748c0253dab6ddd19a2b4e9e
- https://git.kernel.org/stable/c/4242db36de99de734cc1f60e5edd86cda7e598c6
- https://git.kernel.org/stable/c/6ee946077607d7783ae6709a899213fc4fe08f35
- https://git.kernel.org/stable/c/9d1bc155802943e92c57a5fb923d23edfbf0b525
- https://git.kernel.org/stable/c/a035766f970bde2d4298346a31a80685be5c0205
- https://git.kernel.org/stable/c/a92bd0503df2488f2cc040f329ebccff1c1934cb
- https://git.kernel.org/stable/c/df805c1d085b7a96077f0964185764c87060950d
- https://git.kernel.org/stable/c/fdd4e51979f42ca8b1ab7e6176b607e1caabf2a5
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free in create_space_info_sub_group() error path When kobject_init_and_add() fails, the call chain is: create_space_info_sub_group() -> btrfs_sysfs_add_space_info_type() -> kobject_init_and_add() -> failure -> kobject_put(&sub_group->kobj) -> space_info_release() -> kfree(sub_group) Then control returns to create_space_info_sub_group(), where: btrfs_sysfs_add_space_info_type() returns error -> kfree(sub_group) Thus, sub_group is freed twice. Keep parent->sub_group[index] = NULL for the failure path, but after btrfs_sysfs_add_space_info_type() has called kobject_put(), let the kobject release callback handle the cleanup.
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/14b22be1dd844383eb03af9b1ee3b6b25d32aeaf
- https://git.kernel.org/stable/c/259af6857a1b4f1e9ef8b780353f9d11c26a22bd
- https://git.kernel.org/stable/c/a7449edf96143f192606ec8647e3167e1ecbd728
- https://git.kernel.org/stable/c/c2d59527cba6d59f0d77a75c1101ab4e69758bea
- https://git.kernel.org/stable/c/d2a675f2e238ec96c8e91e2718c1f910c9c8fb21
- https://git.kernel.org/stable/c/dfd05a16b5c9d1d98b47905f37f2fccda52173d1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: openvswitch: vport: fix self-deadlock on release of tunnel ports vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here. However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal. Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/366c482965c673565ecb8bcfb15d5548f13a6a10
- https://git.kernel.org/stable/c/3df75fff46b1517eb479d8e6b8e3500763715dd0
- https://git.kernel.org/stable/c/6522d59fb7de55ce0f0f285d962243ddffebb01f
- https://git.kernel.org/stable/c/8ae6c15fc473c9ad03b0173330cce9a092c76154
- https://git.kernel.org/stable/c/aa69918bd418e700309fdd08509dba324fb24296
- https://git.kernel.org/stable/c/c741433f6c8dcdecd1d9549d89053761fd1ea413
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use safe list iteration in radar detect work The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/120149fb3ebcf674832ca3cafd32bedcdb686dde
- https://git.kernel.org/stable/c/7577a4b8a10fab45a6ee2045ea038a5adadbb585
- https://git.kernel.org/stable/c/887ece6c23b49d02a6678e7a8d5ad213d75883ce
- https://git.kernel.org/stable/c/ac8eb3e18f41e2cc8492cc1d358bcb786c850270
- https://access.redhat.com/errata/RHSA-2026:27288
- https://access.redhat.com/errata/RHSA-2026:27708
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/errata/RHSA-2026:33215
- https://access.redhat.com/security/cve/CVE-2026-46166
- https://bugzilla.redhat.com/show_bug.cgi?id=2482645
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46166.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl Just like in a previous problem in this driver, usblp_ctrl_msg() will collapse the usb_control_msg() return value to 0/-errno, discarding the actual number of bytes transferred. Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that. statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl. usblp_read_status() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copy_to_user()s directly to the ioctl caller. Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/087d97342c100138ea7d75a50977c9c2319f957b
- https://git.kernel.org/stable/c/0f7c41314ebf17049917a452684db371babf711a
- https://git.kernel.org/stable/c/6b0e7438e31c74b01514d31ff35c1e688c4baaba
- https://git.kernel.org/stable/c/762a6ccf391db0d629e590a803a3a2231e17dd3f
- https://git.kernel.org/stable/c/a502b997668401a6821501fc98b7f9220f9b6ff2
- https://git.kernel.org/stable/c/b38e53cbfb9d84732e5984fbd73e128d592415c5
- https://git.kernel.org/stable/c/cf24991619be317e2769310b4a367bf4a04b82bc
- https://git.kernel.org/stable/c/d06d937b0a4cdb8867f04275c8100a8b943da31a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix scheduling with atomic in timestamp sockopt Using lock_sock_fast() (atomic context) around sock_set_timestamp() and sock_set_timestamping() is unsafe, as both helpers can sleep. Replace lock_sock_fast() with sleepable lock_sock()/release_sock() to avoid scheduling while atomic panic.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0949d8bbbedbafe0136a1723c41eb823c2f1e09d
- https://git.kernel.org/stable/c/7eb513b42721bee4b96da69f6188d5a7783f210d
- https://git.kernel.org/stable/c/8a005fe451c73fd2b3d1faa5643c11e6bd07acfc
- https://git.kernel.org/stable/c/b157dab93a7af44a84e78cf0cb311dde475cff5b
- https://git.kernel.org/stable/c/b5c52908d52c6c8eb8933264aa6087a0600fd892
- https://git.kernel.org/stable/c/e792cfb6aeaf65612cdf8e3ac431d65e66283654
- https://git.kernel.org/stable/c/ebeb70e29e37cfce899309cc2665a3bfe960ed94
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3003dbf62d151d47a6b90f71655292a51a05f244
- https://git.kernel.org/stable/c/3bc337697c66db2e2a4a94f0509c282c1a014b86
- https://git.kernel.org/stable/c/61a790974ff7e533acbceca06c7d02f22bf96d4d
- https://git.kernel.org/stable/c/8be69532e399eec9d9d990f6958b4ff2383b19b3
- https://git.kernel.org/stable/c/93e8d613f1a01b6637f387cc93f184cf7fb881d6
- https://git.kernel.org/stable/c/a420904450962a562ad053a41a53a27755021b48
- https://git.kernel.org/stable/c/b6b592275aeff184aa82fcf6abccd833fb71b393
- https://git.kernel.org/stable/c/c91bbd6193c70a02c50c22e0fb1f60c3c5bd053a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipv6: xfrm6: release dst on error in xfrm6_rcv_encap() xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not already have a dst attached. ip6_route_input_lookup() returns a referenced dst entry even when the lookup resolves to an error route. If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching the dst to the skb and without releasing the reference returned by the lookup. Repeated packets hitting this path therefore leak dst entries. Release the dst before jumping to the drop path.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/554c9b090c8ac5b1c5c507f4badf8d5d0c9c6e13
- https://git.kernel.org/stable/c/6a5eec0a2a0e99ec9743cf8f1c4082178811d90a
- https://git.kernel.org/stable/c/870560015ce6e0d8f841c6a8aba33c44be52c727
- https://git.kernel.org/stable/c/9d5047782f9bd2829e529df69209bf3232eb561f
- https://git.kernel.org/stable/c/a0721bcd72641c32b281f227a94505b31cf54117
- https://git.kernel.org/stable/c/a20b34f6e854fe6f2aa82528fae7a88759919eb4
- https://git.kernel.org/stable/c/bc0fcb9823cd0894934cf968b525c575833d7078
- https://git.kernel.org/stable/c/c2efc4956981066df2fef1cc77391b523db6d8e4
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3d6fb8a7690c23e3213c4b008f64d89a44b98737
- https://git.kernel.org/stable/c/640b4c00fb0e2920327435f6176cbefc3c546165
- https://git.kernel.org/stable/c/6f49f94f3b11fe8bff1bf2a054143789e76aaf17
- https://git.kernel.org/stable/c/7b2800ba5f5f77a8ee7f4cbadb19cf1264597a34
- https://git.kernel.org/stable/c/9756b3db5db6c2f5eccb32dddbd88eb4c54f575e
- https://git.kernel.org/stable/c/c1fa0bb633e4a6b11e83ffc57fa5abe8ebb87891
- https://project-zero.issues.chromium.org/issues/510793286
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache Make sure resources are not improperly shared in the op cache and cause instruction corruption this way.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1cd85a19748b2407830376a5cbae5c0f126016e5
- https://git.kernel.org/stable/c/1e23b30a80b14e5764657401ee2cca030525ae8e
- https://git.kernel.org/stable/c/251497955f2314cd39d43191e81c6151dead4c7b
- https://git.kernel.org/stable/c/28f5ed477eef166d678d6966762cbc1de9b4f436
- https://git.kernel.org/stable/c/9109489cc8c34e50d15575a3d1ff82af586bc1aa
- https://git.kernel.org/stable/c/c21b90f77687075115d989e53a8ec5e2bb427ab1
- https://git.kernel.org/stable/c/f5bc3aef7df46eaaf423d7413ab8833f704ae576
- https://git.kernel.org/stable/c/ff6fc65b3bf73acc5ee71919154d830ad5431362
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
- https://cert-portal.siemens.com/productcert/html/ssa-082556.html
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error path fall-through in mlx5_ib_dev_res_srq_init() mlx5_ib_dev_res_srq_init() allocates two SRQs, s0 and s1. When ib_create_srq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERR_PTR s1 to devr->s0 and devr->s1. This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERR_PTR as already initialised; users in mlx5_ib_create_qp() dereference the freed SRQ or ERR_PTR via to_msrq(devr->s0)->msrq.srqn; and mlx5_ib_dev_res_cleanup() dereferences the ERR_PTR and double-frees s0 on teardown. Fix by adding the same `goto unlock` in the s1 failure path.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/6fd93142dd1d09000c3750af08270f5792523fe9
- https://git.kernel.org/stable/c/a13c2ac4d480b734342c6fbf8249fc48afd675f3
- https://git.kernel.org/stable/c/b087913ae88256df66620f7ba0a9776716aeef7e
- https://git.kernel.org/stable/c/bc2cf5935b4665172235341163315905197ae91d
- https://git.kernel.org/stable/c/c488df06bd552bb8b6e14fa0cfd5ad986c6e9525
- https://access.redhat.com/errata/RHSA-2026:30848
- https://access.redhat.com/errata/RHSA-2026:33215
- https://access.redhat.com/errata/RHSA-2026:33685
- https://access.redhat.com/errata/RHSA-2026:34094
- https://access.redhat.com/security/cve/CVE-2026-46176
- https://bugzilla.redhat.com/show_bug.cgi?id=2482594
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46176.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: ipmi: Add limits to event and receive message requests The driver would just fetch events and receive messages until the BMC said it was done. To avoid issues with BMCs that never say they are done, add a limit of 10 fetches at a time. In addition, an si interface has an attn state it can return from the hardware which is supposed to cause a flag fetch to see if the driver needs to fetch events or message or a few other things. If the attn bit gets stuck, it's a similar problem. So allow messages in between flag fetches so the driver itself doesn't get stuck. This is a more general fix than the previous fix for the specific bad BMC, but should fix the more general issue of a BMC that won't stop saying it has data. This has been there from the beginning of the driver. It's not a bug per-se, but it is accounting for bugs in BMCs.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/112df8e631636cafda64dcee4561daf09ce74a4a
- https://git.kernel.org/stable/c/304b56883b7eff73eb606c35d062c8101aaf5471
- https://git.kernel.org/stable/c/3d37d2165df9504ea99d9e6181552dc4d2d1ab37
- https://git.kernel.org/stable/c/67c44e0deba936d5edaebea356b4589eb43acb5c
- https://git.kernel.org/stable/c/9059dc94421e1d4f8e5844204608b37ebfddb3da
- https://git.kernel.org/stable/c/c024167fb00489baee08c72182ca2e7dc5fb9f20
- https://git.kernel.org/stable/c/c4cca236968683eb0d59abfb12d5c7e4d8514227
- https://git.kernel.org/stable/c/e20212b431bef217d3886b86bbc90cc3ed00de68
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq() Sashiko points out that mlx4_srq_alloc() was not undone during error unwind, add the missing call to mlx4_srq_free().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0be6ae614ca7fa53e7389e3c7462ed20abbd4192
- https://git.kernel.org/stable/c/0dbd619716fb07b7de1acd64fec673ee6e1adde7
- https://git.kernel.org/stable/c/388617f44d81604a760742a0b5de292d411e63e3
- https://git.kernel.org/stable/c/53fd4c03558672ccb167754fbacbf045c7ab335c
- https://git.kernel.org/stable/c/5b3b220d54e6a3d77380cb7caa1ef79cb8f4fc94
- https://git.kernel.org/stable/c/c54c7e4cb679c0aaa1cb489b9c3f2cd98e63a44c
- https://git.kernel.org/stable/c/c5dc30da990045105c9762248d23076223e7878a
- https://git.kernel.org/stable/c/e01b8c9286c470b71a38acd320106f2c4f2826a1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Don't allow pointer operations on unconfigured streams When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0f0c0c1397a42aacaacae828206ee1b921623952
- https://git.kernel.org/stable/c/327a64241f30c74b6f35537eb9e1fc6c3cbe060b
- https://git.kernel.org/stable/c/4f42dd01f5217465f23a763e27b3984e114d0972
- https://git.kernel.org/stable/c/76ff6bfc9a809571793f425ba99f6a759108dcf8
- https://git.kernel.org/stable/c/98ed1383f597f8a45b6cb816bb20b96d46eeceda
- https://git.kernel.org/stable/c/c5b6285aae050ff1c3ea824ca3d88ac4be1e69c8
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/658d2e46c2e9a8eb9b80c5e803ce3c89885b3366
- https://git.kernel.org/stable/c/908b92231e1ded53e43fcfad5e0704d83e1b803c
- https://git.kernel.org/stable/c/a21f735fb1017ef89c6f9dbf4d799513b4e7bd5a
- https://git.kernel.org/stable/c/c623b63580880cc742255eaed3d79804c1b91143
- https://git.kernel.org/stable/c/d16827cb1d3936f7627d0da6044483f743ebde03
- https://git.kernel.org/stable/c/d616bb10de79e5c2bd8a24230a1128aeaf715615
- https://git.kernel.org/stable/c/df2e90d6a9955510f24f1dada78cfc439fd9fa88
- https://git.kernel.org/stable/c/ed4168d1a50fef5be8eca947fbbf05a28507d265
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: sound: ua101: fix division by zero at probe Add a missing sanity check for bNrChannels in detect_usb_format() to prevent a division by zero in playback_urb_complete() and capture_urb_complete(). USB core does not validate class-specific descriptor fields such as bNrChannels, so drivers must verify them before use. If a device provides bNrChannels = 0, frame_bytes becomes zero and is later used as a divisor in the URB completion handlers, leading to a kernel crash.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0ff2b713f406e9ecadb406014d74e7a020ac12b1
- https://git.kernel.org/stable/c/593dd7e6c890d8e4ca21b3e2f796b7cb8e8da983
- https://git.kernel.org/stable/c/6162e8212e88c39492d981b248b5e37002486c66
- https://git.kernel.org/stable/c/66d9c2ed081f299cfb201d9e9c4faf920e56e0bf
- https://git.kernel.org/stable/c/aae1498c59f48d03ee358df84f07a5af9885f827
- https://git.kernel.org/stable/c/d1f73f169c1014463b5060e3f60813e13ddc7b87
- https://git.kernel.org/stable/c/e02897c5b041c9b980055fa9a6167023d6dc5caf
- https://git.kernel.org/stable/c/f1862dbf09080254c52175a448290c784dd7d3de
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer only contains the base SMB2 header (64 bytes), accessing err->ErrorContextCount (at offset 66) or err->ByteCount later in symlink_data() will cause an out-of-bounds read.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/15dc0a4de743a1aaa7b859b3aea79f08c695396c
- https://git.kernel.org/stable/c/2be11faf79e49fb8250a181ff0b4d2b2f084af83
- https://git.kernel.org/stable/c/b8c8a704f0bc133deb171f6aeb6f3a684203e212
- https://git.kernel.org/stable/c/b9561402489d41149f63e001a74384863b7b30a6
- https://git.kernel.org/stable/c/d62b8d236fab503c6fec1d3e9a38bea71feaca20
- https://git.kernel.org/stable/c/ef6495d4df6e7af8f3de67e65150881c880f696c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: virtio_bt: validate rx pkt_type header length virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/149cfb42ad69c7964fd9f2c43831da9152007129
- https://git.kernel.org/stable/c/1e1e509b6fd2a42421745bbcd98bd16daad20904
- https://git.kernel.org/stable/c/2c1143564c71e7497b42d8360a8379ccbb011d3c
- https://git.kernel.org/stable/c/3485c7236c59c8c34a41af1c4b52982437554e79
- https://git.kernel.org/stable/c/7b2d4c04816cdc887f472caaf7fc966cfc107e40
- https://git.kernel.org/stable/c/daf23014e5d975e72ea9c02b5160d3fcf070ea47
- https://git.kernel.org/stable/c/f743eab6486965f276c7e3f1700895f014fdc6db
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: fix kthread lifetime race between self-exit and external-stop RSI driver use both self-exit(kthread_complete_and_exit) and external-stop (kthread_stop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur. However, in rare instances where kthread_complete_and_exit() is called first and then kthread_stop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again. Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/16d9f674c619838bdeae42abc0929c9c5477ea1f
- https://git.kernel.org/stable/c/4ac3095da22fc50e51ec10c3b8323c21ab3e441a
- https://git.kernel.org/stable/c/4f4c9b13c485abd0a2d2c97f9db339d1dd8e147f
- https://git.kernel.org/stable/c/4f697813162d5f9151726a6d2bee82bffe4b0256
- https://git.kernel.org/stable/c/4f9a4ae8d2c198f01611ea376034c326ef43ab56
- https://git.kernel.org/stable/c/95fcb436586dc3c2983537d557ac05bbc6a027f3
- https://git.kernel.org/stable/c/9dfe8a4458a063c6433526bc59112a169eee1aa3
- https://git.kernel.org/stable/c/db57a1aa54ff68669781976e4edb045e09e2b65b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: octeon_ep_vf: add NULL check for napi_build_skb() napi_build_skb() can return NULL on allocation failure. In __octep_vf_oq_process_rx(), the result is used directly without a NULL check in both the single-buffer and multi-fragment paths, leading to a NULL pointer dereference. Add NULL checks after both napi_build_skb() calls, properly advancing descriptors and consuming remaining fragments on failure.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path Sashiko points out that pvrdma_uar_free() is already called within pvrdma_dealloc_ucontext(), so calling it before triggers a double free.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0c63333ff97bd1275294fd12840a0efe9d7a4c59
- https://git.kernel.org/stable/c/1df5711121cdc11e76b889408fdbe459feba1d39
- https://git.kernel.org/stable/c/269967d7693304e1f06ed2dff4ebbbeeb397cda4
- https://git.kernel.org/stable/c/3a231c34c5bc3d3cfc850b877758ec9fdaa8a483
- https://git.kernel.org/stable/c/45d25e3ec17900bf5a9d6876ff16ceee31c4c0e0
- https://git.kernel.org/stable/c/935ee27d0904aa944cbcc979094c20e5ef62eead
- https://git.kernel.org/stable/c/e38e86995df27f1f854063dab1f0c6a513db3faf
- https://git.kernel.org/stable/c/ecc36a82ecfcfdf3c6606d209f22ec5543c410e0
- https://access.redhat.com/errata/RHSA-2026:30848
- https://access.redhat.com/errata/RHSA-2026:33685
- https://access.redhat.com/errata/RHSA-2026:33743
- https://access.redhat.com/errata/RHSA-2026:35904
- https://access.redhat.com/errata/RHSA-2026:36049
- https://access.redhat.com/errata/RHSA-2026:36073
- https://access.redhat.com/errata/RHSA-2026:36767
- https://access.redhat.com/errata/RHSA-2026:38902
- https://access.redhat.com/errata/RHSA-2026:40068
- https://access.redhat.com/errata/RHSA-2026:40760
- https://access.redhat.com/errata/RHSA-2026:47633
- https://access.redhat.com/security/cve/CVE-2026-46189
- https://bugzilla.redhat.com/show_bug.cgi?id=2482588
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46189.json
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show() Sashiko noticed an out-of-bounds read [1]. In spi_nor_params_show(), the snor_f_names array is passed to spi_nor_print_flags() using sizeof(snor_f_names). Since snor_f_names is an array of pointers, sizeof() returns the total number of bytes occupied by the pointers (element_count * sizeof(void *)) rather than the element count itself. On 64-bit systems, this makes the passed length 8x larger than intended. Inside spi_nor_print_flags(), the 'names_len' argument is used to bounds-check the 'names' array access. An out-of-bounds read occurs if a flag bit is set that exceeds the array's actual element count but is within the inflated byte-size count. Correct this by using ARRAY_SIZE() to pass the actual number of string pointers in the array.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/231b8e1f604f6e0a7e100536f506cdf482e2c5f5
- https://git.kernel.org/stable/c/34bdcfb496b29f9a52431194f94473b37fb8c162
- https://git.kernel.org/stable/c/9a80c458320e0514e11945402dd6e48fcee05524
- https://git.kernel.org/stable/c/c0b654bc0b76a1da102d9138be1ed1223bd99310
- https://git.kernel.org/stable/c/ca18c180b053f6ce80394322b314ac721c316af7
- https://git.kernel.org/stable/c/e47029b977e747cb3a9174308fd55762cce70147
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/46cf3646dea54baeaa2eafe3fb1ba769947f31b0
- https://git.kernel.org/stable/c/524a6079395916fb3d790ef2bb46a1d2939b27dd
- https://git.kernel.org/stable/c/594973a2e54924d8ba31c9faac669fc1ba6fcb80
- https://git.kernel.org/stable/c/7105d9f1387d63b15c9a860674fc92c959181f2f
- https://git.kernel.org/stable/c/ab6c34b9829d5de03f1d08a47a2253729a6e7e27
- https://git.kernel.org/stable/c/b44cc78ff46b96e72d333a3be6aaaa0a14797263
- https://git.kernel.org/stable/c/b51c343a81e6e806525a4435e22532c107dd7e9d
- https://git.kernel.org/stable/c/e4ef723d8975a2694cc90733a6b888a5e2841842
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0555d4f526232b3c9e3afbcd490c0c0793aefec6
- https://git.kernel.org/stable/c/1dae77078ceb4bab833f7a4935f05c5b8c97b9ba
- https://git.kernel.org/stable/c/2ffaa7a94f9a4d22724364a1821735a0231d9f8d
- https://git.kernel.org/stable/c/729899a2aa8bda7844be0cdcd3b470f11b912eda
- https://git.kernel.org/stable/c/7db99a09b3bc87268287bc7ab5f2e7f382b5ad87
- https://git.kernel.org/stable/c/ec406c26c97594124e79d14516b729a8d5dced62
- https://git.kernel.org/stable/c/ec54093e6a8f87e800bb6aa15eb7fc1e33faa524
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix node_cnt race between extent node destroy and writeback f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing extent nodes. When called from f2fs_drop_inode() with I_SYNC set, concurrent kworker writeback can insert new extent nodes into the same extent tree, racing with the destroy and triggering f2fs_bug_on() in __destroy_extent_node(). The scenario is as follows: drop inode writeback - iput - f2fs_drop_inode // I_SYNC set - f2fs_destroy_extent_node - __destroy_extent_node - while (node_cnt) { write_lock(&et->lock) __free_extent_tree write_unlock(&et->lock) - __writeback_single_inode - f2fs_outplace_write_data - f2fs_update_read_extent_cache - __update_extent_tree_range // FI_NO_EXTENT not set, // insert new extent node } // node_cnt == 0, exit while - f2fs_bug_on(node_cnt) // node_cnt > 0 Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected. This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(), consistent with other callers (__update_extent_tree_range and __drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and EX_BLOCK_AGE tree.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0559a0e962aacbb47519e26ee663be04b72dcb92
- https://git.kernel.org/stable/c/42dd1c91f993431d0b399502479d00e6ad1bca71
- https://git.kernel.org/stable/c/ab1eaf9d5c99042f5b0243bf67a06283a4c0757f
- https://git.kernel.org/stable/c/b0e4395870eb3441ddc959f6710b5f6ca61aff26
- https://git.kernel.org/stable/c/ed78aeebef05212ef7dca93bd931e4eff67c113f
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3b1ddba19e77ee35241cd27f16dc3e8d14e08db7
- https://git.kernel.org/stable/c/5de2665e913a10ad70aaeecf736b97276e83d995
- https://git.kernel.org/stable/c/8bd07e417b6bda67e317920584e48cb6ee442a8a
- https://git.kernel.org/stable/c/ba7f71b6161c0943dafc367565e5843d16b7d505
- https://git.kernel.org/stable/c/c688f3ed73d31943334ad2139cb02ec49664322a
- https://git.kernel.org/stable/c/f98b48151cc502ada59d9778f0112d21f2586ca3
- https://git.kernel.org/stable/c/f9dc3be8f403c1216df73e57221f44b045e7ee0b
- https://access.redhat.com/errata/RHSA-2026:21556
- https://access.redhat.com/errata/RHSA-2026:21706
- https://access.redhat.com/errata/RHSA-2026:21745
- https://access.redhat.com/security/cve/CVE-2026-46195
- https://bugzilla.redhat.com/show_bug.cgi?id=2482606
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46195.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/247ed8a969f981bfba3112fd4bb441eaa6cef59c
- https://git.kernel.org/stable/c/2c5b8eeea006eb694c81631cd5713d494b80be90
- https://git.kernel.org/stable/c/342829e042ac00f3d68d442ea92873fb6683f494
- https://git.kernel.org/stable/c/36ff362235307af95152d510b53c2d9b8773a342
- https://git.kernel.org/stable/c/4f1756d043e56ea2e9a6c858fb290a0cf6fc2251
- https://git.kernel.org/stable/c/5787052e5f69beb649f3d6a80a8aa37d9e683e4e
- https://git.kernel.org/stable/c/7bcadb3c2bc1cf60690e931aadd35fb7bd646a49
- https://git.kernel.org/stable/c/fad217e16fded7f3c09f8637b0f6a224d58b5f2e
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: validate SVM ioctl nattr against buffer size Validate nattr field against the buffer size, preventing out-of-bounds buffer access via user-controlled attribute count. (cherry picked from commit 5eca8bfdfa456c3304ca77523718fe24254c172f)
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/045e0ff208f0838a246c10204105126611b267a1
- https://git.kernel.org/stable/c/6abd3a4417cb73a7d0db7e25bf11fae1074bdba3
- https://git.kernel.org/stable/c/91c6dc5a41695d02dfc6299f106ac38a6c493e52
- https://git.kernel.org/stable/c/ccd060b5c7cc75ae7e211c250b97c5b6272e7efc
- https://git.kernel.org/stable/c/daa8bc5f83814b55b71d2b5b3a090d57a5219c21
- https://git.kernel.org/stable/c/db9530a9873a7c85d2266a922589ebcf427fa631
- https://git.kernel.org/stable/c/fb07a0c9c8419164812e07274947f11b1d92dd61
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix integer overflow on buff_pos Fixing an integer overflow present in batadv_iv_ogm_send_to_if. The size check is done using the int type in batadv_iv_ogm_aggr_packet whereas the buff_pos variable uses the s16 type. This could lead to an out-of-bound read.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0799e5943611006b346b8813c7daf7dd5aa26bfd
- https://git.kernel.org/stable/c/10bb1f366d884d506c38a947b43026a75d1afe9a
- https://git.kernel.org/stable/c/867cd090760e8f5cd206f387b47ff9c56fac04e9
- https://git.kernel.org/stable/c/96c9c0ed9a9579a9085765aceaa4556a6666eb82
- https://git.kernel.org/stable/c/974542d1efc48b7e9fe16184e647615cba39969b
- https://git.kernel.org/stable/c/b252797bfced986d6d92ec2f4cfcca842ce8aa78
- https://git.kernel.org/stable/c/bf872db54f91ffe70104b98c20068b2d5910e018
- https://git.kernel.org/stable/c/f61499359fa529f0d45a53bf7c573a49eb6322e6
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a78f2bac1424deb7c9d5e09c6b8e849d8e8b648
- https://git.kernel.org/stable/c/3c817a60b09eaab926e475088e750936efcc95ae
- https://git.kernel.org/stable/c/63b51e8a9d54317d31cc3856c1e12407070d5fc2
- https://git.kernel.org/stable/c/7688143ca62edeecacb3ba0a2cea129dbd262a18
- https://git.kernel.org/stable/c/88411caee8f576d6b5abf6531232fcc0ce756dc5
- https://git.kernel.org/stable/c/c72a8b4dc6d598e3831ef3abd9c6527dfbf4810e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix controller deregistration Make sure to deregister the controller before disabling and releasing underlying resources like interrupts and gpios during driver unbind.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix dma-buf attachment leak in xe_gem_prime_import() When xe_dma_buf_init_obj() fails, the attachment from dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before returning the error. Note: we cannot use goto out_err here because xe_dma_buf_init_obj() already frees bo on failure, and out_err would double-free it. (cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: Prevent OOB reads when parsing IB Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/1dc005775fb5b3f86464406452b17364f85581d3
- https://git.kernel.org/stable/c/2444eb0ec8283f4a3845eb7febad378476e1ba3c
- https://git.kernel.org/stable/c/5c3e8ebad0c9e2354ddfa8f2148dc4f70a3b4bd1
- https://git.kernel.org/stable/c/a6d5563ba1f03a049561cd347574613167294e8d
- https://git.kernel.org/stable/c/d0802a8877d730260d4af4dd4e0b6cde7e0e593f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: staging: media: atomisp: Disallow all private IOCTLs Disallow all private IOCTLs. These aren't quite as safe as one could assume of IOCTL handlers; disable them for now. Instead of removing the code, return in the beginning of the function if cmd is non-zero in order to keep static checkers happy.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2b7eb2c5dc72f0fc954ac4aa155f9e285e937f7c
- https://git.kernel.org/stable/c/51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654
- https://git.kernel.org/stable/c/64e85679beafe082fc2e70a557ec356c7fd27548
- https://git.kernel.org/stable/c/6850a439f8d23d4979624f1d6880d3118d473a28
- https://git.kernel.org/stable/c/6f1ce75a75c65061e7a720c3d0ee5f8adab7a2d3
- https://git.kernel.org/stable/c/8774f8cb661f57ae43cc3bc0509d16ef1f406e45
- https://git.kernel.org/stable/c/8c7a281a99224a5b9af99c4dcd98d68eea75926c
- https://git.kernel.org/stable/c/c7848b67ef10f581114b6a2f52b160fc20eb52c9
- https://git.kernel.org/stable/c/ceb1b5f910e58986ea544ff8c9c2f23ae9a52414
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject new tp_meter sessions during teardown Prevent tp_meter from starting new sender or receiver sessions after mesh_state has left BATADV_MESH_ACTIVE.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0a7a840074c9ca5ebffc9c52358c8ea55828ec71
- https://git.kernel.org/stable/c/3243543592425beec83d453793e9d27caa0d8e66
- https://git.kernel.org/stable/c/52e6ec3e972cf27792cc1559874dbee19f286869
- https://git.kernel.org/stable/c/ca39545cf07c142b39d474a1439a046bf28def3d
- https://git.kernel.org/stable/c/dcff44644bb518598b1a6be722706d6174b2f6a1
- https://git.kernel.org/stable/c/e1e2194cc725ec1d41f9412496212f0fa0519c36
- https://git.kernel.org/stable/c/e4a3c4a4c8f6efd243c3e448c05b7bebcbf7b3b6
- https://git.kernel.org/stable/c/ff93f86ecbb50a4709c403fc279a396e308edde5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix empty payload in tap skb for non-linear buffers For non-linear skbs, virtio_transport_build_skb() goes through virtio_transport_copy_nonlinear_skb() to copy the original payload in the new skb to be delivered to the vsockmon tap device. This manually initializes an iov_iter but does not set iov_iter.count. Since the iov_iter is zero-initialized, the copy length is zero and no payload is actually copied to the monitor interface, leaving data un-initialized. Fix this by removing the linear vs non-linear split and using skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as vhost-vsock already does. This handles both linear and non-linear skbs, properly initializes the iov_iter, and removes the now unused virtio_transport_copy_nonlinear_skb(). While touching this code, let's also check the return value of skb_copy_datagram_iter(), even though it's unlikely to fail.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/03660dab86f93319178a24667f6998526dc4355d
- https://git.kernel.org/stable/c/268078acae72daa12b17b2b299701cb9924e469a
- https://git.kernel.org/stable/c/26dfeee8db81354bfdade155f27f9e16510ad196
- https://git.kernel.org/stable/c/3d3cf6a7314aca4df0a6dde28ce784a2a30d0166
- https://git.kernel.org/stable/c/58943b7ea356294749dae3e75b96c0ee292c00be
- https://git.kernel.org/stable/c/5e7d0ac936354c36810e74ac3056b334ed1f4058
- https://git.kernel.org/stable/c/79bc0eaeef2c5797317bf2da8e3159a74d62ec47
- https://git.kernel.org/stable/c/8634c1dbd73adb74d40533ebb7e914efb82e71fb
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs() drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions using plain integer division: unsigned int width = mode_cmd->width / (i ? info->hsub : 1); unsigned int height = mode_cmd->height / (i ? info->vsub : 1); However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses drm_format_info_plane_width/height() which round up dimensions via DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object size check for certain pixel format and dimension combinations. For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the GEM size validation path sees height=0 instead of height=1. The expression (height - 1) then wraps to UINT_MAX as an unsigned int, causing min_size to overflow and wrap back to a small value. A tiny GEM object therefore passes the size guard, yet when the GPU accesses the chroma plane it will read or write memory beyond the object's bounds. Fix by replacing the open-coded divisions with drm_format_info_plane_width() and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match the calculation already used in framebuffer_check().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/11427ad6c9f0def5ce567982b785da3191946430
- https://git.kernel.org/stable/c/1a17ea9861e89585361caa8bc231bd22dc6dbe7d
- https://git.kernel.org/stable/c/1da4ab7189f1064b3b712b388772c008b4d82580
- https://git.kernel.org/stable/c/22922f7dae74409fc4bf0f1142710cb6b8ce8cc2
- https://git.kernel.org/stable/c/3d4c2268bd7243c3780fe32bf24ff876da272acf
- https://git.kernel.org/stable/c/6b992591e04f2cce813bcf239b354f375bbf84d3
- https://git.kernel.org/stable/c/adfc5ba4ef4dd2bca5969f40e8fc7b41fb3902ad
- https://git.kernel.org/stable/c/c5fc49d8470c5ebf3b41607600f277158f159950
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata() msm_ioctl_gem_info_get_metadata() always returns 0 regardless of errors. When copy_to_user() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not. Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copy_to_user() call. Add the missing NULL check for kmemdup() and return ret instead of 0. Note that the SET counterpart (msm_ioctl_gem_info_set_metadata) correctly returns ret. Patchwork: https://patchwork.freedesktop.org/patch/714478/
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH8.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/00155f336a5e8b1006d2ca9ae7ad8fc4a44bb401
- https://git.kernel.org/stable/c/0cc9847c64cb6e61118bc78c9187c8209a7197fa
- https://git.kernel.org/stable/c/1d4b241482d9025c537afb3c7c8419c72c0e0c82
- https://git.kernel.org/stable/c/368449e467d5f1e2c2e987bf2bd57000ba75e10b
- https://git.kernel.org/stable/c/4ae1709a314060a196981b344610d023ea841e57
- https://git.kernel.org/stable/c/6c5dc6d68e6ba7f0224a757a39ed52fcdb54d472
- https://git.kernel.org/stable/c/a1a99837bb6169cfb9187abaa2005e8f12079426
- https://git.kernel.org/stable/c/b88c865dcf6e9f20bfe66a360d4b62941ef769b8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix accept queue count leak on transport mismatch virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections. Fix by moving sk_acceptq_added() to after the transport validation, matching the pattern used by vmci_transport and hyperv_transport.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/29371f3cc83e2a92265b4768014a30b80234112f
- https://git.kernel.org/stable/c/2ea5d2c79edcc99c7dbe0bb7518f5e1ee2a2391f
- https://git.kernel.org/stable/c/52bcb57a4e8a0865a76c587c2451906342ae1b2d
- https://git.kernel.org/stable/c/65c484726e74013a2ec7ba67a34d87760ae8f390
- https://git.kernel.org/stable/c/6d3275fc4ed968938e1d556c344798046776668d
- https://git.kernel.org/stable/c/e9edf9893cf26d060705c910a9b62d8cc96ed56a
- https://git.kernel.org/stable/c/f66c7904fb6f0e420a654bc90909e64a25d00896
- https://git.kernel.org/stable/c/fd51e810affa38d735d04261e673b2a5fe9c8665
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add bounds checking to ib_{get,set}_value The uvd/vce/vcn code accesses the IB at predefined offsets without checking that the IB is large enough. Check the bounds here. The caller is responsible for making sure it can handle arbitrary return values. Also make the idx a uint32_t to prevent overflows causing the condition to fail.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0fb5cb556b249b2b64c0f818136c4c3e838ef53f
- https://git.kernel.org/stable/c/5da6c6430be0acb25b4242bce0323fc514d4e3cf
- https://git.kernel.org/stable/c/66085e206431ef88ce36f53c1f53d570790ccc9e
- https://git.kernel.org/stable/c/a853178d23e774adfe3a35073c375b04b3b20f7d
- https://git.kernel.org/stable/c/ee26fcf7c5cf131f0b6a732faa27d79ec61b8ec7
- https://git.kernel.org/stable/c/fec8b11b55e53ff51a741e56894fe331a516f5c6
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on unbind The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0944b20e9dfa2917bd70eb5b301cbb67fe54a718
- https://git.kernel.org/stable/c/6c3e413919a12627d04a31a4a5fccb9fc129bb02
- https://git.kernel.org/stable/c/706b3dc2ac7a998c55e14b3fd2e8f934c367e6e0
- https://git.kernel.org/stable/c/ac8316c896c79f32c1d0a38cb41fd2b14cf8112e
- https://git.kernel.org/stable/c/bb6b50f709c5a01906ff72a07fdc070bb3357188
- https://git.kernel.org/stable/c/bbcd6dd8e9f264440eaf6167382bf404911c1c46
- https://git.kernel.org/stable/c/ed929d40963073f23cfb50219ccbcc6e0c3ea641
- https://git.kernel.org/stable/c/ee52da0dd83ebcd89ecbbe2660c57b15a25489f2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4: replace BUG_ON with WARN_ON in fence emission sdma_v4_0_ring_emit_fence() contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions can be reached from unprivileged userspace via crafted DRM_IOCTL_AMDGPU_CS submissions, causing a fatal kernel panic in a scheduler worker thread. Replace both BUG_ON() calls with WARN_ON() to log the condition without crashing the kernel. A misaligned fence address at this point indicates a driver bug, but crashing the kernel is never the correct response when the assertion is reachable from userspace. The CS IOCTL path is the correct place to filter invalid submissions; the ring emission callback is too late to do anything about it. (cherry picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b91ea46bb68abf98a082bf239092253bbd6aaa2
- https://git.kernel.org/stable/c/25e7d56a39657d56d1ea6d78992f7ed15dedb412
- https://git.kernel.org/stable/c/4f7ca00fa91daf0795ec6b3b130c5ebba1f155fe
- https://git.kernel.org/stable/c/78d2e624fa073c14970aa097adcf3ea31c157a66
- https://git.kernel.org/stable/c/a4fd82fb0757c180bf622907397c528b89a827b2
- https://git.kernel.org/stable/c/d331fb241a4602253976ddd65144a8ba2b05665d
- https://git.kernel.org/stable/c/d4c56932d29773e278be6a65a5384a36c95b89a4
- https://git.kernel.org/stable/c/ecaa80318e900ca0c3f687742ede33b41cfd2f8e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: rspi: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/77defd64b405b680db73d767313fce770d368368
- https://git.kernel.org/stable/c/9944fa6726afb1e6eb7e2212764e7da0c97f2dcc
- https://git.kernel.org/stable/c/aee76c1dd189562c6678313caec12761f78a9ef3
- https://git.kernel.org/stable/c/c5090db1b31de3ef4db0cda7e822ab49cb572292
- https://git.kernel.org/stable/c/fee6abd9845c3edd217b0e429d09f764f9a5690e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: fsl: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/562d954a144950ec2aa6a874ae657cb3fa31fe53
- https://git.kernel.org/stable/c/5750743a39c9d46ac9fcf57ffe000956da4942cf
- https://git.kernel.org/stable/c/9b7abfed4c3754062d1f3ffd452e65a38667f586
- https://git.kernel.org/stable/c/ca3195c7b88362d7c81efe685948663a9f9db0e6
- https://git.kernel.org/stable/c/e888308222375ac28bae69134dae288178718a96
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0c7b55974f97b78d1109025eadf084e74cbf330f
- https://git.kernel.org/stable/c/0dbc8cde64280fc37cdd678cced34eaf96cfb197
- https://git.kernel.org/stable/c/1bfb06ecb00f7fdf35dba8e8f2877346cbe5e078
- https://git.kernel.org/stable/c/6187a172d6ed57d6b2c327836e4407c6456e639d
- https://git.kernel.org/stable/c/abb5f36771cc4c05899b34000829a787572a8817
- https://git.kernel.org/stable/c/bf0f40d8107e2ce827521968dc6926f3e13728ae
- https://git.kernel.org/stable/c/c9dadb31f36045a8cb65df4bd75e7237ef21a4b5
- https://git.kernel.org/stable/c/f3a3f0b406b4b7eb3cea35a23fa2bf170848b104
- https://access.redhat.com/errata/RHSA-2026:26462
- https://access.redhat.com/errata/RHSA-2026:26515
- https://access.redhat.com/errata/RHSA-2026:26535
- https://access.redhat.com/errata/RHSA-2026:26563
- https://access.redhat.com/errata/RHSA-2026:27731
- https://access.redhat.com/errata/RHSA-2026:27735
- https://access.redhat.com/errata/RHSA-2026:33899
- https://access.redhat.com/errata/RHSA-2026:34094
- https://access.redhat.com/errata/RHSA-2026:36018
- https://access.redhat.com/errata/RHSA-2026:36348
- https://access.redhat.com/errata/RHSA-2026:36349
- https://access.redhat.com/errata/RHSA-2026:36956
- https://access.redhat.com/security/cve/CVE-2026-46227
- https://bugzilla.redhat.com/show_bug.cgi?id=2482564
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46227.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated VRAM with stale data from prior use observable by compute kernels. The GEM ioctl path already sets VRAM_CLEARED for all userspace allocations via amdgpu_gem_create_ioctl() and amdgpu_mode_dumb_create(). The KFD path was missing this flag, allowing stale page table remnants to leak into user buffers. This causes crashes in RCCL P2P transport where non-zero data in ptrExchange/head/tail fields corrupts the protocol handshake.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/047d44d8d29a6a1a5757256837aa9dd78e3cd0b5
- https://git.kernel.org/stable/c/1db431380879fd9d28b763a88a0c0431be5be8df
- https://git.kernel.org/stable/c/32b153658f017ad2f5bf8aab479e8d16ac95bc3a
- https://git.kernel.org/stable/c/77d0b5d11387071770246fd0185a69fa28e8e109
- https://git.kernel.org/stable/c/ad52d61d82181dbdb7f05826de38352d5e550cc2
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg Check bounds against the end of the BO whenever we access the msg.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/638d3e0b9eb77aa53fdd60e2b928761d16ba76fa
- https://git.kernel.org/stable/c/638e48ee39d0f2af9336f917a6f5d6692dd64d93
- https://git.kernel.org/stable/c/82c535eff05490c71153af57de9fe85502fcb5d5
- https://git.kernel.org/stable/c/870c8738c3774336baedddd0240951d078a703b8
- https://git.kernel.org/stable/c/b193019860d61e92da395eae2011f2f6716b182f
- https://git.kernel.org/stable/c/e382e0b81a3e7bd21504fee1d01ae8b08f84d3a7
- https://git.kernel.org/stable/c/f55552adb100eb54a6e6dabff4fbdc8679bd3fa0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: put backbone reference on failed claim hash insert When batadv_bla_add_claim() fails to insert a new claim into the hash, it leaked a reference to the backbone_gw for which the claim was intended. Call batadv_backbone_gw_put() on the error path to release the reference and avoid leaking the backbone_gw object.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0baf4b659cdc7305cf685b5a5d60f9e3816ab5d0
- https://git.kernel.org/stable/c/2888c9a154123db0254ae4fb9bea570c7e1f2e06
- https://git.kernel.org/stable/c/65419eb4259a26a3cd3f56fa0e3b3c113bf8c256
- https://git.kernel.org/stable/c/6c8b68a7ed667a63aa603ba4d3a7088be143007e
- https://git.kernel.org/stable/c/769f413d374ff2b6ff6d8d8c37b4c1178e6cdf14
- https://git.kernel.org/stable/c/7cccf4eb4f96d3c3af91a00b7a9caa652439542e
- https://git.kernel.org/stable/c/ba9d20ee9076dac32c371116bacbe72480eb356c
- https://git.kernel.org/stable/c/fd0ca034c1e71ca7613cde9dd892836b2c2831bd
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: HID: playstation: Clamp num_touch_reports A device would never lie about the number of touch reports would it? If it does the loop in dualshock4_parse_report will read off the end of the touch_reports array, up to about 2 KiB for the maximum number of 256 loop iteraions. The data that is read is emitted via evdev if the DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by clamping the num_touch_reports value provided by the device to the maximum size of the touch_reports array.
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0bc4cf1a6ba00fb8c074531b179bc7b97502fbc4
- https://git.kernel.org/stable/c/208f6d5b1dfd6399bc6af9e11f27f1f496243ed0
- https://git.kernel.org/stable/c/7812694752a5f295eaa05a093b90a2c332666051
- https://git.kernel.org/stable/c/9c031b24aed6733b6dcc5d98527875b8654a04e9
- https://git.kernel.org/stable/c/cac61b58a3b6340c52afa06bb15eac033158db2f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: only purge non-released claims When batadv_bla_purge_claims() goes through the list of claims, it is only traversing the hash list with an rcu_read_lock(). Due to a potential parallel batadv_claim_put(), it can happen that it encounters a claim which was actually in the process of being released+freed by batadv_claim_release(). In this case, backbone_gw is set to NULL before the delayed RCU kfree is started. Calling batadv_bla_claim_get_backbone_gw() is then no longer allowed because it would cause a NULL-ptr derefence. To avoid this, only claims with a valid reference counter must be purged. All others are already taken care of.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/6725c523a35eeca611ff37e7d4a8712fae92aefd
- https://git.kernel.org/stable/c/7b7ebb7222a5524ce58e48cc9c6d688320ea6cfe
- https://git.kernel.org/stable/c/7b8fbcee3184d848b5aee085ca16d0cf05c9b641
- https://git.kernel.org/stable/c/a9f58d5e3261f3deeae69ec1e237f38ef3ff5cbe
- https://git.kernel.org/stable/c/ab3dbd07a809a8eb30c7ddfab9ac886ed30dce8d
- https://git.kernel.org/stable/c/afb5436f6028fd68f408f189230fbaa19c910d72
- https://git.kernel.org/stable/c/b65365d2b1e6095c538d49baeb140dd1c166c1b3
- https://git.kernel.org/stable/c/cf6b604011591865ae39ac82de8978c1120d17af
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: vsock: fix buffer size clamping order In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint. This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size. Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/01ef69785dc3162f588a361ab770b1e312800188
- https://git.kernel.org/stable/c/0b68881501460c3761f196469e1e503218c5e536
- https://git.kernel.org/stable/c/2602f7bb5818e92315feeaeb71d8ce4d5c9ab160
- https://git.kernel.org/stable/c/310da27932dd0afe7ce7456dfe1f0814c3301f41
- https://git.kernel.org/stable/c/a998a7e250bf976539e05a00ec64a81292afecaa
- https://git.kernel.org/stable/c/caf11dfea5233a69298a1c448bbf8d1639c80536
- https://git.kernel.org/stable/c/d114bfdc9b76bf93b881e195b7ec957c14227bab
- https://git.kernel.org/stable/c/f6ec135941d2c1c2dbb87b5ce1783f4f6ac6ccca
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: saa7164: add ioremap return checks and cleanups Add checks for ioremap return values in saa7164_dev_setup(). If ioremap for BAR0 or BAR2 fails, release the already allocated PCI memory regions, remove the device from the global list, decrement the device count, and return -ENODEV. This prevents potential null pointer dereferences and ensures proper cleanup on memory mapping failures.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/23dee5990d2c27ed79567fd61ccfe6876768531a
- https://git.kernel.org/stable/c/3ce8f3057c51bb0a66aa3fab0862be74e9f88684
- https://git.kernel.org/stable/c/6047dc542fa404b5c187cc2c7906aaaaec6d11ed
- https://git.kernel.org/stable/c/6c22a6d8e4c1507bba504aeebe80476144a373eb
- https://git.kernel.org/stable/c/a9b83f46e52cf1239d780920d1a7a3e415f7b5d9
- https://git.kernel.org/stable/c/d51c60a498e83c9a79884c8e420f97e3885c9583
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: rc: xbox_remote: heed DMA restrictions The buffer for IO must not be part of the device structure because that violates the DMA coherency rules.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0bd8ac88ec5f74cd0f4b8cfc54f4cc0827007249
- https://git.kernel.org/stable/c/0cc9251833bf02c8c7863404157c94dab5928fcf
- https://git.kernel.org/stable/c/0ea67a135335e51be50e83ee4cc99560b8b89c25
- https://git.kernel.org/stable/c/465d27ab83692167f06a6f917bdfd0a0d4fc8ff3
- https://git.kernel.org/stable/c/48a668c22e8f92637bc496e84d1cf06900f74a5c
- https://git.kernel.org/stable/c/63a960b39de9c51f29ca19aa5067934f865c0bc7
- https://git.kernel.org/stable/c/e0301883ec779c21158a3923b2eb666074fa976e
- https://git.kernel.org/stable/c/e280d1e5e3f2595bbb43fe6e1bce00c59a43c0ff
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop caching unowned originator pointers in BAT IV BAT IV keeps the last-hop neighbor address in each neigh_node, but some paths also cache an originator pointer derived from a temporary lookup. That pointer is not owned by the neigh_node and may no longer refer to a live originator entry after purge handling runs. Stop storing the auxiliary originator pointer in the BAT IV neighbor state. When BAT IV needs the neighbor originator data, resolve it from the stored neighbor address and drop the reference again after use. [sven: avoid bonding logic for outgoing OGM]
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/09dc0d1a12222ffca6481916eab3cfea477b9620
- https://git.kernel.org/stable/c/384e3050a42be9085d50507b4d5f8266a588d742
- https://git.kernel.org/stable/c/67bceeb22207f1f5a402973a3a0809e5f2698f38
- https://git.kernel.org/stable/c/6e20700f8c524ac379ba8274ff5d453023b7c006
- https://git.kernel.org/stable/c/86b2b58d7c228d850c8c78e4144e6123e8ed2718
- https://git.kernel.org/stable/c/8c16c68fdbb69778f8d04f650340c3f4d1518f8e
- https://git.kernel.org/stable/c/aafcbaf1159ea224528ca4075d0ba8c10ef374af
- https://git.kernel.org/stable/c/f03e8583532941b07761c5429de7d50766fa3110
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on registration failure Make sure to disable and free the interrupts in case controller registration fails to avoid a potential use-after-free and resource leak. This issue was flagged by Sashiko when reviewing a controller deregistration fix.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH8.6
In the Linux kernel, the following vulnerability has been resolved:
ibmveth: Disable GSO for packets with small MSS
Some physical adapters on Power systems do not support segmentation
offload when the MSS is less than 224 bytes. Attempting to send such
packets causes the adapter to freeze, stopping all traffic until
manually reset.
Implement ndo_features_check to disable GSO for packets with small MSS
values. The network stack will perform software segmentation instead.
The 224-byte minimum matches ibmvnic
commit ("ibmvnic: Enforce stronger sanity checks
on GSO packets")
which uses the same physical adapters in SEA configurations.
The issue occurs specifically when the hardware attempts to perform
segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets
(gso_segs == 1) do not trigger the problematic LSO code path and are
transmitted normally without segmentation.
Add an ndo_features_check callback to disable GSO when MSS < 224 bytes.
Also call vlan_features_check() to ensure proper handling of VLAN packets,
particularly QinQ (802.1ad) configurations where the hardware parser may
not support certain offload features.
Validated using iptables to force small MSS values. Without the fix,
the adapter freezes. With the fix, packets are segmented in software
and transmission succeeds. Comprehensive regression testing completedd
(MSS tests, performance, stability).
CVSS 3.xHIGH 8.6
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1cdf5dbcec988d06f5f720bdf89e91073f77fa10
- https://git.kernel.org/stable/c/3af24f0c4c31f18a4a2d927990759194832bb6e9
- https://git.kernel.org/stable/c/82bc89fbb82d9396fb4eaee8720ea85e2e787957
- https://git.kernel.org/stable/c/86fc64584811d43c9ccd74447de58620189d8b77
- https://git.kernel.org/stable/c/9a5e984d7af910e46dcbed3ce77873e000a4f77d
- https://git.kernel.org/stable/c/c1f261863e65b508f37416dfbc5c5d911c9b9233
- https://git.kernel.org/stable/c/cc427d24ac6442ffdeafd157a63c7c5b73ed4de4
- https://git.kernel.org/stable/c/db8012c631cb845e9ae2b4b531e17d86c9519755
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0]. Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory. Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/252c5051dba9c709b6a72f2866f93e5e618b3f06
- https://git.kernel.org/stable/c/5a20ebf0c81b61f5ea3b1b529c100cad69b9f603
- https://git.kernel.org/stable/c/d376c131af7c7739a87ff037ed2fdb67c2542c8a
- https://git.kernel.org/stable/c/d6a2d7b04b5a093021a7a0e2e69e9d5237dfa8cc
- https://git.kernel.org/stable/c/d6bda9df0c0a3080804181464d5c0f4d78a4e769
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix zero-size GDS range init on RDNA4 RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this. amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT. Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type. DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now. Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/095a8b0ad3c3b5cdc3850d961adb8a8f735220bb
- https://git.kernel.org/stable/c/0e21db1a77967bc15df662efdca8ea8a61d124ea
- https://git.kernel.org/stable/c/1f5d33e7b0a9a2a140f46e22fb52eede323c5946
- https://git.kernel.org/stable/c/30c000a49094ec568c9b51b7421f7a4a3f0b0298
- https://git.kernel.org/stable/c/36f9602fb22ede69fcc8b422be0cf8105bf655ad
- https://git.kernel.org/stable/c/3e26c76891ab99fa173e9c501119fbb5c9f4600f
- https://git.kernel.org/stable/c/9bc925759c05feae7dfa9570e77131d54729c8ea
- https://git.kernel.org/stable/c/be0376affcafa0bbb371bb501579a825eae32281
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: lib: test_hmm: evict device pages on file close to avoid use-after-free Patch series "Minor hmm_test fixes and cleanups". Two bugfixes a cleanup for the HMM kernel selftests. These were mostly reported by Zenghui Yu with special thanks to Lorenzo for analysing and pointing out the problems. This patch (of 3): When dmirror_fops_release() is called it frees the dmirror struct but doesn't migrate device private pages back to system memory first. This leaves those pages with a dangling zone_device_data pointer to the freed dmirror. If a subsequent fault occurs on those pages (eg. during coredump) the dmirror_devmem_fault() callback dereferences the stale pointer causing a kernel panic. This was reported [1] when running mm/ksft_hmm.sh on arm64, where a test failure triggered SIGABRT and the resulting coredump walked the VMAs faulting in the stale device private pages. Fix this by calling dmirror_device_evict_chunk() for each devmem chunk in dmirror_fops_release() to migrate all device private pages back to system memory before freeing the dmirror struct. The function is moved earlier in the file to avoid a forward declaration.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/234071b4318feaeb27cd2e4e1b16ef6b055adf89
- https://git.kernel.org/stable/c/38f113f81d3f0adc658a4475dd3ecaec985e21d3
- https://git.kernel.org/stable/c/5846715b6382dd4c6a69b35a56ca6115d33bc2a0
- https://git.kernel.org/stable/c/744dd97752ef1076a8d8672bb0d8aa2c7abc1144
- https://git.kernel.org/stable/c/9de1eb0aac2862d6144b8db0ec1388e79f8bc3e1
- https://git.kernel.org/stable/c/bf477abd448c76bb8ea51c9b4f63a3a17c4b6239
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: iio: frequency: admv1013: fix NULL pointer dereference on str When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver. Several cleanup patches have been applied to this driver recently so this will need a manual backport.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tpm: Use kfree_sensitive() to free auth session in tpm_dev_release() tpm_dev_release() uses plain kfree() to free chip->auth, which contains sensitive cryptographic material including HMAC session keys, nonces, and passphrase data (struct tpm2_auth). Every other code path that frees this structure uses kfree_sensitive() to zero the memory before releasing it: both tpm2_end_auth_session() and tpm_buf_check_hmac_response() do so. The tpm_dev_release() path is the only one that does not, leaving key material in freed slab memory until it is eventually overwritten. Use kfree_sensitive() for consistency with the rest of the driver and to ensure session keys are scrubbed during device teardown.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/16f6588a3b7a2a20d10ad9b766be74c60ba347cc
- https://git.kernel.org/stable/c/2bf706fe7831b319f23a85b9728f961cfed40c3e
- https://git.kernel.org/stable/c/8408655ec8344511667b61d8257dc59c80ee3391
- https://git.kernel.org/stable/c/ca19808bc6fac7e29420d8508df569b346b3e339
- https://git.kernel.org/stable/c/d26f8c361f751c188b7ebaf8189aa0258968fd98
- https://git.kernel.org/stable/c/d49628d63d4e6bbc8a1621afb88e5fc901611bee
- https://git.kernel.org/stable/c/d89044889ecd11b0c2f86663597246e9bdd25679
- https://git.kernel.org/stable/c/f5d2ed4ed47d3906e2495a3537a48b127f497a17
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: leds: qcom-lpg: Check for array overflow when selecting the high resolution When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/28a2e047d03721e0517c67ee726eaa6621c30e5f
- https://git.kernel.org/stable/c/36ce3094dc50598f38fd961b46688cd533940efc
- https://git.kernel.org/stable/c/438e357b3cc6cd6900df271e4bc567bfe1142281
- https://git.kernel.org/stable/c/d45963a93c1495e9f1338fde91d0ebba8fd22474
- https://git.kernel.org/stable/c/f67a24e75d3251ba42538738120b6b659c0dca7d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
net: txgbe: fix RTNL assertion warning when remove module
For the copper NIC with external PHY, the driver called
phylink_connect_phy() during probe and phylink_disconnect_phy() during
remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
upon module remove.
To fix this, add rtnl_lock() and rtnl_unlock() around the
phylink_disconnect_phy() in remove function.
------------[ cut here ]------------
RTNL: assertion failed at drivers/net/phy/phylink.c (2351)
WARNING: drivers/net/phy/phylink.c:2351 at
phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464
Modules linked in: ...
CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+
Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING
PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024
RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]
Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7
48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a
e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000
RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020
RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000
R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348
FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0
PKRU: 55555554
Call Trace:
txgbe_remove_phy+0xbb/0xd0 [txgbe]
txgbe_remove+0x4c/0xb0 [txgbe]
pci_device_remove+0x41/0xb0
device_remove+0x43/0x80
device_release_driver_internal+0x206/0x270
driver_detach+0x4a/0xa0
bus_remove_driver+0x83/0x120
driver_unregister+0x2f/0x60
pci_unregister_driver+0x40/0x90
txgbe_driver_exit+0x10/0x850 [txgbe]
__do_sys_delete_module.isra.0+0x1c3/0x2f0
__x64_sys_delete_module+0x12/0x20
x64_sys_call+0x20c3/0x2390
do_syscall_64+0x11c/0x1500
? srso_alias_return_thunk+0x5/0xfbef5
? do_syscall_64+0x15a/0x1500
? srso_alias_return_thunk+0x5/0xfbef5
? do_fault+0x312/0x580
? srso_alias_return_thunk+0x5/0xfbef5
? __handle_mm_fault+0x9d5/0x1040
? srso_alias_return_thunk+0x5/0xfbef5
? count_memcg_events+0x101/0x1d0
? srso_alias_return_thunk+0x5/0xfbef5
? handle_mm_fault+0x1e8/0x2f0
? srso_alias_return_thunk+0x5/0xfbef5
? do_user_addr_fault+0x2f8/0x820
? srso_alias_return_thunk+0x5/0xfbef5
? irqentry_exit+0xb2/0x600
? srso_alias_return_thunk+0x5/0xfbef5
? exc_page_fault+0x92/0x1c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0305e7118451c7c363c18f8113b0d8e0077ffa4c
- https://git.kernel.org/stable/c/3e223a7fd41ce6fffdb10577df9350385262bf33
- https://git.kernel.org/stable/c/6c5ec52c68a6a442c8a159615ae092512562318a
- https://git.kernel.org/stable/c/d29cafc7e4ee9e28a150ba17e9a565ec5d881fbc
- https://git.kernel.org/stable/c/e159f05e12cc1111a3103b99375ddf0dfd0e7d63
HIGH8.4
In the Linux kernel, the following vulnerability has been resolved: of: unittest: fix use-after-free in of_unittest_changeset() The variable 'parent' is assigned the value of 'nchangeset' earlier in the function, meaning both point to the same struct device_node. The call to of_node_put(nchangeset) can decrement the reference count to zero and free the node if there are no other holders. After that, the code still uses 'parent' to check for the presence of a property and to read a string property, leading to a use-after-free. Fix this by moving the of_node_put() call after the last access to 'parent', avoiding the UAF.
CVSS 3.xHIGH 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HCRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: lib/scatterlist: fix length calculations in extract_kvec_to_sg Patch series "Fix bugs in extract_iter_to_sg()", v3. Fix bugs in the kvec and user variants of extract_iter_to_sg. This series is growing due to useful remarks made by sashiko.dev. The main bugs are: - The length for an sglist entry when extracting from a kvec can exceed the number of bytes in the page. This is obviously not intended. - When extracting a user buffer the sglist is temporarily used as a scratch buffer for extracted page pointers. If the sglist already contains some elements this scratch buffer could overlap with existing entries in the sglist. The series adds test cases to the kunit_iov_iter test that demonstrate all of these bugs. Additionally, there is a memory leak fix for the test itself. The bugs were orignally introduced into kernel v6.3 where the function lived in fs/netfs/iterator.c. It was later moved to lib/scatterlist.c in v6.5. Thus the actual fix is only marked for backports to v6.5+. This patch (of 5): When extracting from a kvec to a scatterlist, do not cross page boundaries. The required length was already calculated but not used as intended. Adjust the copied length if the loop runs out of sglist entries without extracting everything. While there, return immediately from extract_iter_to_sg if there are no sglist entries at all. A subsequent commit will add kunit test cases that demonstrate that the patch is necessary.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/07b7d66e65d9cfe6b9c2c34aa22cfcaac37a5c45
- https://git.kernel.org/stable/c/3f17500e86d730c76db638bb3ae52f9b5e496c76
- https://git.kernel.org/stable/c/8fbba6829057979149d1b37d65690c037f3ddf4d
- https://git.kernel.org/stable/c/9d38756d0a93b66163554219fa9c3365f40c4035
- https://git.kernel.org/stable/c/e5e22fc9963469e678c4f4bb38d26adcec107f1e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/177730a273b18e195263ed953853273e901b5064
- https://git.kernel.org/stable/c/2adbfca7452eeac45117b8e803288a2767f7075f
- https://git.kernel.org/stable/c/5cffe3c136891aa4d579bf5c079a68f7cb371b0c
- https://git.kernel.org/stable/c/a9207798fe619cbc85c8744a9b9e2af1db2b6e1a
- https://git.kernel.org/stable/c/b8f12d9b00c1950779e5679b9c13908584682bb6
- https://git.kernel.org/stable/c/c7e52fe3f7901ccb9cd29b3f7c683d809ba87e48
- https://git.kernel.org/stable/c/cd849c07b8d706425e60a4dfcef54b7b67c967ce
- https://git.kernel.org/stable/c/e8e72fdf47bd5ef7abe642b034c6178a61a8580a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/26735dfdd8930d9ef1fa92e590a9bf77726efdf6
- https://git.kernel.org/stable/c/361518a26e4434e879db6ff43bf364795dcbfbff
- https://git.kernel.org/stable/c/51a7dd9cbae9210335ce398642ecaaa52c939eb5
- https://git.kernel.org/stable/c/52e485ed0dcb5496864003ba9ffcef7d5b613f83
- https://git.kernel.org/stable/c/707cb5df3eab32ddc52979418f7ace62941e6381
- https://git.kernel.org/stable/c/8d44391a7f29e4601e8243f13498d0219bab2576
- https://git.kernel.org/stable/c/98b8104978474d381256a2b2fb0e7ca8e05a7bfa
- https://git.kernel.org/stable/c/e8f8dad44f024a5c99e54a48ad5c943fa8e54319
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: clk: microchip: mpfs-ccc: fix out of bounds access during output registration UBSAN reported an out of bounds access during registration of the last two outputs. This out of bounds access occurs because space is only allocated in the hws array for two PLLs and the four output dividers that each has, but the defined IDs contain two DLLS and their two outputs each, which are not supported by the driver. The ID order is PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs by two while adding them to the array to avoid the problem.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/2f7ae8ab6aa73daaf080d5332110357c29df9c36
- https://git.kernel.org/stable/c/47bc7a03449c39805bc2665d3e57c73195d5bcf8
- https://git.kernel.org/stable/c/9ed9b580a814773482c0a4f1be045636e68cc109
- https://git.kernel.org/stable/c/a0780aeea166a7cf4706c45af4cadbb2a43a1fc9
- https://git.kernel.org/stable/c/dbfcb09656cb30439577325c9dea2250203c2e3c
- https://git.kernel.org/stable/c/f24efd415455b98a1f1cfc6071fe6fde71986706
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm: fix a buffer overflow in ioctl processing Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the function retrieve_status: 1. The code in retrieve_status checks that the output string fits into the output buffer and writes the output string there 2. Then, the code aligns the "outptr" variable to the next 8-byte boundary: outptr = align_ptr(outptr); 3. The alignment doesn't check overflow, so outptr could point past the buffer end 4. The "for" loop is iterated again, it executes: remaining = len - (outptr - outbuf); 5. If "outptr" points past "outbuf + len", the arithmetics wraps around and the variable "remaining" contains unusually high number 6. With "remaining" being high, the code writes more data past the end of the buffer Luckily, this bug has no security implications because: 1. Only root can issue device mapper ioctls 2. The commonly used libraries that communicate with device mapper (libdevmapper and devicemapper-rs) use buffer size that is aligned to 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input buffer and the bug can't happen accidentally
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2fa49cc884f6496a915c35621ba4da35649bf159
- https://git.kernel.org/stable/c/448ee8fb79c26a26599ffa4b2adeb4322d3d3d8c
- https://git.kernel.org/stable/c/526ff9126a0ae087b65726e1faf31114c718020d
- https://git.kernel.org/stable/c/5af6a879e915ae7bcd83695c316ebb32e1c61bc2
- https://git.kernel.org/stable/c/8daa6c708ef524089ae43f2aed9190acb26d7df8
- https://git.kernel.org/stable/c/c8c5311237448f6ffeecc9aec2362e3692623668
- https://git.kernel.org/stable/c/d271631023cbe1cbe7c31a0275ab797883be6e0a
- https://git.kernel.org/stable/c/f0b0b09d9840838ae77ccdd6a62de0daef4e6e0a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: s3c64xx: fix NULL-deref on driver unbind A change moving DMA channel allocation from probe() back to s3c64xx_spi_prepare_transfer() failed to remove the corresponding deallocation from remove(). Drop the bogus DMA channel release from remove() to avoid triggering a NULL-pointer dereference on driver unbind. This issue was flagged by Sashiko when reviewing a controller deregistration fix.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1108b8722b9ff0cdd3e8aa18d98244fcd93b6760
- https://git.kernel.org/stable/c/1b66f16a571a10ba8889ac471755c8af9c5b9266
- https://git.kernel.org/stable/c/22788b1a8611380b141e09a8896702e32d164238
- https://git.kernel.org/stable/c/29e219a18e21258bdb4ee12cecd0e9ec87d7e6a7
- https://git.kernel.org/stable/c/323a258f4b1916b5a3098618e036e033b2f2317f
- https://git.kernel.org/stable/c/45daacbead8a009844bd5dba6cfa731332184d17
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix held lock freed on hfsplus_fill_super()
hfsplus_fill_super() calls hfs_find_init() to initialize a search
structure, which acquires tree->tree_lock. If the subsequent call to
hfsplus_cat_build_key() fails, the function jumps to the out_put_root
error label without releasing the lock. The later cleanup path then
frees the tree data structure with the lock still held, triggering a
held lock freed warning.
Fix this by adding the missing hfs_find_exit(&fd) call before jumping
to the out_put_root error label. This ensures that tree->tree_lock is
properly released on the error path.
The bug was originally detected on v6.13-rc1 using an experimental
static analysis tool we are developing, and we have verified that the
issue persists in the latest mainline kernel. The tool is specifically
designed to detect memory management issues. It is currently under active
development and not yet publicly available.
We confirmed the bug by runtime testing under QEMU with x86_64 defconfig,
lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we
used GDB to dynamically shrink the max_unistr_len parameter to 1 before
hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally
return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and
exercises the faulty error path. The following warning was observed
during mount:
=========================
WARNING: held lock freed!
7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted
-------------------------
mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there!
ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0
2 locks held by mount/174:
#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40
#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0
stack backtrace:
CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
dump_stack_lvl+0x82/0xd0
debug_check_no_locks_freed+0x13a/0x180
kfree+0x16b/0x510
? hfsplus_fill_super+0xcb4/0x18a0
hfsplus_fill_super+0xcb4/0x18a0
? __pfx_hfsplus_fill_super+0x10/0x10
? srso_return_thunk+0x5/0x5f
? bdev_open+0x65f/0xc30
? srso_return_thunk+0x5/0x5f
? pointer+0x4ce/0xbf0
? trace_contention_end+0x11c/0x150
? __pfx_pointer+0x10/0x10
? srso_return_thunk+0x5/0x5f
? bdev_open+0x79b/0xc30
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? vsnprintf+0x6da/0x1270
? srso_return_thunk+0x5/0x5f
? __mutex_unlock_slowpath+0x157/0x740
? __pfx_vsnprintf+0x10/0x10
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? mark_held_locks+0x49/0x80
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? irqentry_exit+0x17b/0x5e0
? trace_irq_disable.constprop.0+0x116/0x150
? __pfx_hfsplus_fill_super+0x10/0x10
? __pfx_hfsplus_fill_super+0x10/0x10
get_tree_bdev_flags+0x302/0x580
? __pfx_get_tree_bdev_flags+0x10/0x10
? vfs_parse_fs_qstr+0x129/0x1a0
? __pfx_vfs_parse_fs_qstr+0x3/0x10
vfs_get_tree+0x89/0x320
fc_mount+0x10/0x1d0
path_mount+0x5c5/0x21c0
? __pfx_path_mount+0x10/0x10
? trace_irq_enable.constprop.0+0x116/0x150
? trace_irq_enable.constprop.0+0x116/0x150
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? kmem_cache_free+0x307/0x540
? user_path_at+0x51/0x60
? __x64_sys_mount+0x212/0x280
? srso_return_thunk+0x5/0x5f
__x64_sys_mount+0x212/0x280
? __pfx___x64_sys_mount+0x10/0x10
? srso_return_thunk+0x5/0x5f
? trace_irq_enable.constprop.0+0x116/0x150
? srso_return_thunk+0x5/0x5f
do_syscall_64+0x111/0x680
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ffacad55eae
Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8
RSP: 002b
---truncated---
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/041acda6d9f96006703466449c10c9a69590c8b9
- https://git.kernel.org/stable/c/3ca80e3012c8be85b4f8d0d20eac8d3b17ff257e
- https://git.kernel.org/stable/c/6499c9c8ec437a369e7e221dad91f6122b50759d
- https://git.kernel.org/stable/c/90c500e4fd83fa33c09bc7ee23b6d9cc487ac733
- https://git.kernel.org/stable/c/bfbcce6a7b0552a390620d9b2c4d2bcb1825cbdc
- https://git.kernel.org/stable/c/c554ddc87af4d4e4be42f8aed1baec9e1c7588e0
- https://git.kernel.org/stable/c/d309d3308de658d87c42d97e044c89a226327526
- https://git.kernel.org/stable/c/e890656accee4c26d932ea388eb8936a6e22184d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c
- https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987
- https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111
- https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a
- https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e
- https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0
- https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5
- https://git.kernel.org/stable/c/f84eca5817390257cef78013d0112481c503b4a3
- http://www.openwall.com/lists/oss-security/2026/05/13/5
- http://www.openwall.com/lists/oss-security/2026/05/21/11
- http://www.openwall.com/lists/oss-security/2026/05/21/12
- http://www.openwall.com/lists/oss-security/2026/05/21/13
- https://access.redhat.com/errata/RHBA-2026:20032
- https://access.redhat.com/errata/RHSA-2026:19521
- https://access.redhat.com/errata/RHSA-2026:19540
- https://access.redhat.com/errata/RHSA-2026:19568
- https://access.redhat.com/errata/RHSA-2026:19569
- https://access.redhat.com/errata/RHSA-2026:19664
- https://access.redhat.com/errata/RHSA-2026:19666
- https://access.redhat.com/errata/RHSA-2026:19705
- https://access.redhat.com/errata/RHSA-2026:19711
- https://access.redhat.com/errata/RHSA-2026:19875
- https://access.redhat.com/errata/RHSA-2026:20051
- https://access.redhat.com/errata/RHSA-2026:20054
- https://access.redhat.com/errata/RHSA-2026:20087
- https://access.redhat.com/errata/RHSA-2026:20129
- https://access.redhat.com/errata/RHSA-2026:20130
- https://access.redhat.com/errata/RHSA-2026:20299
- https://access.redhat.com/errata/RHSA-2026:20593
- https://access.redhat.com/errata/RHSA-2026:21656
- https://access.redhat.com/errata/RHSA-2026:21690
- https://access.redhat.com/errata/RHSA-2026:21695
- https://access.redhat.com/errata/RHSA-2026:21702
- https://access.redhat.com/errata/RHSA-2026:23233
- https://access.redhat.com/errata/RHSA-2026:23240
- https://access.redhat.com/errata/RHSA-2026:23245
- https://access.redhat.com/errata/RHSA-2026:23468
- https://access.redhat.com/errata/RHSA-2026:23469
- https://access.redhat.com/errata/RHSA-2026:23470
- https://access.redhat.com/errata/RHSA-2026:23471
- https://access.redhat.com/errata/RHSA-2026:24814
- https://access.redhat.com/errata/RHSA-2026:25044
- https://access.redhat.com/errata/RHSA-2026:28887
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/errata/RHSA-2026:34098
- https://access.redhat.com/security/cve/CVE-2026-46300
- https://bugzilla.redhat.com/show_bug.cgi?id=2477015
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
- https://cert-portal.siemens.com/productcert/html/ssa-082556.html
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46300.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: spi: topcliff-pch: fix use-after-free on unbind Give the driver a chance to flush its queue before releasing the DMA buffers on driver unbind
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0e8e57f9737ea257634db1d152fc430a0788a3e1
- https://git.kernel.org/stable/c/36e58c436d2c2a797800427dc04d74ffd8b6ce1c
- https://git.kernel.org/stable/c/43334836b907adc21eab3079d2e6b26754468786
- https://git.kernel.org/stable/c/4ca90deeca1c7dd72c1c380ba8143565516def2d
- https://git.kernel.org/stable/c/8822980668c96b5aa251c1e2daec1873262b8f3f
- https://git.kernel.org/stable/c/9d72732fe70c11424bc90ed466c7ccfa58b42a9a
- https://git.kernel.org/stable/c/d50ef3553acbacce6f2843304d41d06dca358bb6
- https://git.kernel.org/stable/c/d79e92161b65832e0b8cad5f3d84d17e5cd7a970
HIGH8.2
In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice.
CVSS 3.xHIGH 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:NReferences
- https://git.kernel.org/stable/c/22b36fa081f38ab397c7697f9d539211b51a0cfc
- https://git.kernel.org/stable/c/8356fb821016797f5677cbeee5ddc0d32a95b4be
- https://git.kernel.org/stable/c/a36d990f591320e9dd379ab30063ebfe91d47e1f
- https://git.kernel.org/stable/c/bf1bc673c587f5ef7e9c09b94aea7c5a7847d4d9
- https://git.kernel.org/stable/c/c9b37c8b73f6368e4750e5ccb0632c380b43c6e5
- https://git.kernel.org/stable/c/d582e12378bc1637f337622feef762f53c43fd57
- https://git.kernel.org/stable/c/e69da8eeab74b4f4505024c38a17bce060fe7df8
- https://git.kernel.org/stable/c/ef048470c90bc8c1b8318bb2ce329da9ef64b9fe
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved:
nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free
nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the
final controller reference through nvmet_cq_put(). If that triggers
nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on
the same nvmet-wq.
Call chain:
nvmet_tcp_schedule_release_queue()
kref_put(&queue->kref, nvmet_tcp_release_queue)
nvmet_tcp_release_queue()
queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq
process_one_work()
nvmet_tcp_release_queue_work()
nvmet_cq_put(&queue->nvme_cq)
nvmet_cq_destroy()
nvmet_ctrl_put(cq->ctrl)
nvmet_ctrl_free()
flush_work(&ctrl->async_event_work) <--- nvmet_wq
Previously Scheduled by :-
nvmet_add_async_event
queue_work(nvmet_wq, &ctrl->async_event_work);
This trips lockdep with a possible recursive locking warning.
[ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55
[ 5223.061801] loop0: detected capacity change from 0 to 2097152
[ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
[ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
[ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
[ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349
[ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"
[ 5233.227718] ============================================
[ 5233.231283] WARNING: possible recursive locking detected
[ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N
[ 5233.238434] --------------------------------------------
[ 5233.241852] kworker/u192:6/2413 is trying to acquire lock:
[ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90
[ 5233.251438]
but task is already holding lock:
[ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0
[ 5233.261125]
other info that might help us debug this:
[ 5233.265333] Possible unsafe locking scenario:
[ 5233.269217] CPU0
[ 5233.270795] ----
[ 5233.272436] lock((wq_completion)nvmet-wq);
[ 5233.275241] lock((wq_completion)nvmet-wq);
[ 5233.278020]
*** DEADLOCK ***
[ 5233.281793] May be due to missing lock nesting notation
[ 5233.286195] 3 locks held by kworker/u192:6/2413:
[ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0
[ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0
[ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530
[ 5233.304290]
stack backtrace:
[ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full)
[ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST
[ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
[ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp]
[ 5233.306532] Call Trace:
[ 5233.306534]
[ 5233.306536] dump_stack_lvl+0x73/0xb0
[ 5233.306552] print_deadlock_bug+0x225/0x2f0
[ 5233.306556] __lock_acquire+0x13f0/0x2290
[ 5233.306563] lock_acquire+0xd0/0x300
[ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90
[ 5233.306571] ? __flush_work+0x20b/0x530
[ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90
[ 5233.306577] touch_wq_lockdep_map+0x3b/0x90
[ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90
[ 52
---truncated---
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/551f445a56a11a6457550cddcf39c9ebb8bcacc6
- https://git.kernel.org/stable/c/781f47d641432c26c19625b2cdd7f40825097592
- https://git.kernel.org/stable/c/8d66ba89480ff098a58d79003a505f383aa4e920
- https://git.kernel.org/stable/c/9a4d7222c0955b221e38bb66d10e6bccb672c8a1
- https://git.kernel.org/stable/c/a696fbbd5240b4ac9b166f7bd4c550882ff543f1
- https://git.kernel.org/stable/c/aade8abd8b868b6ffa9697aadaea28ec7f65bee6
- https://git.kernel.org/stable/c/ae5b0cad163833e10b271e9becc05d81dae56e5f
- https://git.kernel.org/stable/c/ee6e20c4bc9eae542a0954a368449532383169d4
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: flow_dissector: do not dissect PPPoE PFC frames RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the flow dissector driver has assumed an uncompressed frame until the blamed commit. During the review process of that commit [1], support for PFC is suggested. However, having a compressed (1-byte) protocol field means the subsequent PPP payload is shifted by one byte, causing 4-byte misalignment for the network header and an unaligned access exception on some architectures. The exception can be reproduced by sending a PPPoE PFC frame to an ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE session is active on that interface: $ 0 : 00000000 80c40000 00000000 85144817 $ 4 : 00000008 00000100 80a75758 81dc9bb8 $ 8 : 00000010 8087ae2c 0000003d 00000000 $12 : 000000e0 00000039 00000000 00000000 $16 : 85043240 80a75758 81dc9bb8 00006488 $20 : 0000002f 00000007 85144810 80a70000 $24 : 81d1bda0 00000000 $28 : 81dc8000 81dc9aa8 00000000 805ead08 Hi : 00009d51 Lo : 2163358a epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50 ra : 805ead08 __skb_get_hash_net+0x74/0x12c Status: 11000403 KERNEL EXL IE Cause : 40800010 (ExcCode 04) BadVA : 85144817 PrId : 0001992f (MIPS 1004Kc) Call Trace: [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50 [<805ead08>] __skb_get_hash_net+0x74/0x12c [<805ef330>] get_rps_cpu+0x1b8/0x3fc [<805fca70>] netif_receive_skb_list_internal+0x324/0x364 [<805fd120>] napi_complete_done+0x68/0x2a4 [<8058de5c>] mtk_napi_rx+0x228/0xfec [<805fd398>] __napi_poll+0x3c/0x1c4 [<805fd754>] napi_threaded_poll_loop+0x234/0x29c [<805fd848>] napi_threaded_poll+0x8c/0xb0 [<80053544>] kthread+0x104/0x12c [<80002bd8>] ret_from_kernel_thread+0x14/0x1c Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000 To reduce the attack surface and maintain performance, do not process PPPoE PFC frames. [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0d00b9015069712944934bab09eaa6c542143049
- https://git.kernel.org/stable/c/18ae9eacfc95cc715c0606b2c86e8aa8a86cf3e3
- https://git.kernel.org/stable/c/6044392d9cace3a3672b02c8bc7d38b502e51734
- https://git.kernel.org/stable/c/7c93f353eab4ea911e394630f07d72e040a729d8
- https://git.kernel.org/stable/c/abc5bc84e0f2edc7ea2d437afa6ef3fe1fc43200
- https://git.kernel.org/stable/c/d6c19b31a3c1d519fabdcf0aa239e6b6109b9473
- https://git.kernel.org/stable/c/db104b0d8a7856397c0469d83a4289adf7c54863
- https://git.kernel.org/stable/c/e7c811ca372d53c2be7d01a1614e71fae1054836
HIGH8.3
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath5k: do not access array OOB
Vincent reports:
> The ath5k driver seems to do an array-index-out-of-bounds access as
> shown by the UBSAN kernel message:
> UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20
> index 4 is out of range for type 'ieee80211_tx_rate [4]'
> ...
> Call Trace:
>
> dump_stack_lvl+0x5d/0x80
> ubsan_epilogue+0x5/0x2b
> __ubsan_handle_out_of_bounds.cold+0x46/0x4b
> ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
> tasklet_action_common+0xb5/0x1c0
It is real. 'ts->ts_final_idx' can be 3 on 5212, so:
info->status.rates[ts->ts_final_idx + 1].idx = -1;
with the array defined as:
struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
while the size is:
#define IEEE80211_TX_MAX_RATES 4
is indeed bogus.
Set this 'idx = -1' sentinel only if the array index is less than the
array size. As mac80211 will not look at rates beyond the size
(IEEE80211_TX_MAX_RATES).
Note: The effect of the OOB write is negligible. It just overwrites the
next member of info->status, i.e. ack_signal.
CVSS 3.xHIGH 8.3
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:LReferences
- https://git.kernel.org/stable/c/568173ad9bd0b46cc6cd937dea8791e9b5eefa57
- https://git.kernel.org/stable/c/744c19e266b0d2628c5951439195dcef27eadacf
- https://git.kernel.org/stable/c/83226c71af53fb9b3cad40cb9a9a79f36d68c020
- https://git.kernel.org/stable/c/9dd6aae4bc7bfa11088d928670a3315eae542769
- https://git.kernel.org/stable/c/d6869537013b1f21b292342752d97868b79b5934
- https://git.kernel.org/stable/c/d748603f12baff112caa3ab7d39f50100f010dbd
- https://git.kernel.org/stable/c/e9f1081bc775146156def0dbc821b92f35d56afb
- https://git.kernel.org/stable/c/ecb1c163166759dec004c1fdb9709b8a5992fc8e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: videobuf2: Set vma_flags in vb2_dma_sg_mmap vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not see a reason why vb2_dma_sg should behave differently. This avoids hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of tree Apple ISP camera capture driver which uses vb2_dma_sg_memops. gst-launch-1.0 v4l2src ! gtk4paintablesink [ 38.201528] ------------[ cut here ]------------ [ 38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210 [ 38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3 snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon apple_sart apple_dockchannel macsmc apple_rtkit_helper spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core spi_apple [ 38.203300] videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram [ 38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G W 6.17.6+ #asahi-dev PREEMPT(full) [ 38.219040] Tainted: [W]=WARN [ 38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210 [ 38.221643] lr : drm_gem_mmap_obj+0x78/0x210 [ 38.222178] sp : ffffc0008dc678e0 [ 38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480 [ 38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968 [ 38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0 [ 38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968 [ 38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8 [ 38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff [ 38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8 [ 38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000 [ 38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038 [ 38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb [ 38.231488] Call trace: [ 38.231806] drm_gem_mmap_obj+0x1f8/0x210 (P) [ 38.232342] drm_gem_mmap+0x140/0x260 [ 38.232813] __mmap_region+0x488/0x9a0 [ 38.233277] mmap_region+0xd0/0x148 [ 38.233703] do_mmap+0x350/0x5c0 [ 38.234148] vm_mmap_pgoff+0x14c/0x200 [ 38.234612] ksys_mmap_pgoff+0x150/0x208 [ 38.235107] __arm64_sys_mmap+0x34/0x50 [ 38.235611] invoke_syscall+0x50/0x120 [ 38.236075] el0_svc_common.constprop.0+0x48/0xf0 [ 38.236680] do_el0_svc+0x24/0x38 [ 38.237113] el0_svc+0x38/0x168 [ 38.237507] el0t_64_sync_handler+0xa0/0xe8 [ 38.238034] el0t_64_sync+0x198/0x1a0 [ 38.238491] ---[ end trace 0000000000000000 ]--- There were discussions in [1] at the end of 2023 that mmap() on imported ---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1a1360264f699521e001e7739009ee3ee3c6a4f5
- https://git.kernel.org/stable/c/21fade52ab9fb13368a5709e60b0d9909197aeae
- https://git.kernel.org/stable/c/7254b31a13aaa0c2c0f9ffbc335b718656117ff4
- https://git.kernel.org/stable/c/b4cf91658a636618f1437beec971dec25dec28eb
- https://git.kernel.org/stable/c/feb17524aa4ec337749344be0db52b88663e25ab
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: fix error pointer dereference In a error path isp->psys is confirmed to be an error pointer not NULL so this condition is true and the error pointer is dereferenced. So isp-psys should be set to NULL before going to out_ipu6_bus_del_devices. Detected by Smatch: drivers/media/pci/intel/ipu6/ipu6.c:690 ipu6_pci_probe() error: 'isp->psys' dereferencing possible ERR_PTR() [Sakari Ailus: Fix commit message.]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. The tcf_ct_flow_table_cleanup_work() can complete before refcount_inc_not_zero() is invoked on the returned ct_ft resulting in a UAF on the already freed ct_ft object. This vulnerability can lead to privilege escalation. Analysis from zdi-disclosures@trendmicro.com: When initializing act_ct, tcf_ct_init() is called, which internally triggers tcf_ct_flow_table_get(). static int tcf_ct_flow_table_get(struct net *net, struct tcf_ct_params *params) { struct zones_ht_key key = { .net = net, .zone = params->zone }; struct tcf_ct_flow_table *ct_ft; int err = -ENOMEM; mutex_lock(&zones_mutex); ct_ft = rhashtable_lookup_fast(&zones_ht, &key, zones_params); // [1] if (ct_ft && refcount_inc_not_zero(&ct_ft->ref)) // [2] goto out_unlock; ... } static __always_inline void *rhashtable_lookup_fast( struct rhashtable *ht, const void *key, const struct rhashtable_params params) { void *obj; rcu_read_lock(); obj = rhashtable_lookup(ht, key, params); rcu_read_unlock(); return obj; } At [1], rhashtable_lookup_fast() looks up and returns the corresponding ct_ft from zones_ht . The lookup is performed within an RCU read critical section through rcu_read_lock() / rcu_read_unlock(), which prevents the object from being freed. However, at the point of function return, rcu_read_unlock() has already been called, and there is nothing preventing ct_ft from being freed before reaching refcount_inc_not_zero(&ct_ft->ref) at [2]. This interval becomes the race window, during which ct_ft can be freed. Free Process: tcf_ct_flow_table_put() is executed through the path tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put(). static void tcf_ct_flow_table_put(struct tcf_ct_flow_table *ct_ft) { if (refcount_dec_and_test(&ct_ft->ref)) { rhashtable_remove_fast(&zones_ht, &ct_ft->node, zones_params); INIT_RCU_WORK(&ct_ft->rwork, tcf_ct_flow_table_cleanup_work); // [3] queue_rcu_work(act_ct_wq, &ct_ft->rwork); } } At [3], tcf_ct_flow_table_cleanup_work() is scheduled as RCU work static void tcf_ct_flow_table_cleanup_work(struct work_struct *work) { struct tcf_ct_flow_table *ct_ft; struct flow_block *block; ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table, rwork); nf_flow_table_free(&ct_ft->nf_ft); block = &ct_ft->nf_ft.flow_block; down_write(&ct_ft->nf_ft.flow_block_lock); WARN_ON(!list_empty(&block->cb_list)); up_write(&ct_ft->nf_ft.flow_block_lock); kfree(ct_ft); // [4] module_put(THIS_MODULE); } tcf_ct_flow_table_cleanup_work() frees ct_ft at [4]. When this function executes between [1] and [2], UAF occurs. This race condition has a very short race window, making it generally difficult to trigger. Therefore, to trigger the vulnerability an msleep(100) was inserted after[1]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/17dfb67cb399b660105d9a8c6100851c0d0cdc70
- https://git.kernel.org/stable/c/3e20e1b3058e0b94638e7b931c138e840e266724
- https://git.kernel.org/stable/c/4c727c6967a41b37efe0f26332ca9ec5b74785a3
- https://git.kernel.org/stable/c/67c9ecc9f2575273ed1323e312881fc98ac83d6d
- https://git.kernel.org/stable/c/a2e0c045c87aa252eb61412e67dd91f2c2b19f81
- https://git.kernel.org/stable/c/ece578ca61e572df96cfc80456357ebfae0b4b9e
- https://git.kernel.org/stable/c/f23424a0ddadb494d4bd57056a7ca703312d3a7b
- https://git.kernel.org/stable/c/f462dca0c8415bf0058d0ffa476354c4476d0f09
HIGH8.0
In the Linux kernel, the following vulnerability has been resolved: greybus: gb-beagleplay: bound bootloader receive buffering cc1352_bootloader_rx() appends each serdev chunk into the fixed rx_buffer before parsing bootloader packets. The helper can keep leftover bytes between callbacks and may receive multiple packets in one callback, so a single count value is not constrained by one packet length. Check that the incoming chunk fits in the remaining receive buffer space before memcpy(). If it does not, drop the staged data and consume the bytes instead of overflowing rx_buffer.
CVSS 3.xHIGH 8.0
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NReferences
- https://git.kernel.org/stable/c/01363cb3fbd0238ffdeb09f53e9039c9edf8a730
- https://git.kernel.org/stable/c/15b828a46f305ae9f05a7c16914b3ce273474205
- https://git.kernel.org/stable/c/2a93a4fac7b6051d3be7cd1b015fe7320cd0404d
- https://git.kernel.org/stable/c/31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a
- https://git.kernel.org/stable/c/4709234fd1b95136ceb789f639b1e7ea5de1b181
- https://git.kernel.org/stable/c/6e5b51e74a40d377bcd3081dd33fbaa0e1aa7e3d
- https://git.kernel.org/stable/c/8f907d345bae8f4b3f004c5abc56bf2dfb851ea7
- https://git.kernel.org/stable/c/93d4ba49d18e3d7fb41a9927c2d0cca5e9dfefd6
- http://www.openwall.com/lists/oss-security/2026/05/15/9
- http://www.openwall.com/lists/oss-security/2026/05/20/14
- http://www.openwall.com/lists/oss-security/2026/05/20/16
- https://lists.debian.org/debian-lts-announce/2026/05/msg00032.html
- https://lists.debian.org/debian-lts-announce/2026/05/msg00035.html
- https://access.redhat.com/errata/RHSA-2026:19521
- https://access.redhat.com/errata/RHSA-2026:19540
- https://access.redhat.com/errata/RHSA-2026:19568
- https://access.redhat.com/errata/RHSA-2026:19569
- https://access.redhat.com/errata/RHSA-2026:19664
- https://access.redhat.com/errata/RHSA-2026:19666
- https://access.redhat.com/errata/RHSA-2026:19705
- https://access.redhat.com/errata/RHSA-2026:19711
- https://access.redhat.com/errata/RHSA-2026:19875
- https://access.redhat.com/errata/RHSA-2026:20051
- https://access.redhat.com/errata/RHSA-2026:20054
- https://access.redhat.com/errata/RHSA-2026:20129
- https://access.redhat.com/errata/RHSA-2026:20130
- https://access.redhat.com/errata/RHSA-2026:20299
- https://access.redhat.com/errata/RHSA-2026:20593
- https://access.redhat.com/errata/RHSA-2026:21701
- https://access.redhat.com/errata/RHSA-2026:21702
- https://access.redhat.com/errata/RHSA-2026:23468
- https://access.redhat.com/errata/RHSA-2026:23469
- https://access.redhat.com/errata/RHSA-2026:23470
- https://access.redhat.com/errata/RHSA-2026:23471
- https://access.redhat.com/errata/RHSA-2026:24814
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/security/cve/CVE-2026-46333
- https://bugzilla.redhat.com/show_bug.cgi?id=2477802
- https://cert-portal.siemens.com/productcert/html/ssa-019113.html
- https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn/
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46333.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix nvkm_device leak on aperture removal failure When aperture_remove_conflicting_pci_devices() fails during probe, the error path returns directly without unwinding the nvkm_device that was just allocated by nvkm_device_pci_new(). This leaks both the device wrapper and the pci_enable_device() reference taken inside it. Jump to the existing fail_nvkm label so nvkm_device_del() runs and balances both. The leak was introduced when the intermediate nvkm_device_del() between detection and aperture removal was dropped in favor of creating the pci device once.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH8.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: scope conn->binding slowpath to bound sessions only When the binding SESSION_SETUP sets conn->binding = true, the flag stays set after the call so that the global session lookup in ksmbd_session_lookup_all() can find the session, which was not added to conn->sessions. Because the flag is connection-wide, the global lookup path will also resolve any other session by id if asked. Tighten the global lookup so that the returned session must have this connection registered in its channel xarray (sess->ksmbd_chann_list). The channel entry is installed by the existing binding_session path in ntlm_authenticate()/krb5_authenticate() when a SESSION_SETUP completes successfully, so this condition is a strict equivalent of "this connection has been accepted as a channel of this session". Connections that have not bound to a given session cannot reach it via the global table. The existing conn->binding gate for entering the slowpath is preserved so that non-binding connections keep the fast-path-only behavior, and the session->state check is unchanged.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1e2bec062c5c9ec282636715166056d0998d746d
- https://git.kernel.org/stable/c/1ff46c9915c1cbf454db58a8cb87f7cac818e6a6
- https://git.kernel.org/stable/c/2cc8a4db633b10715450b291c1343859a4b2c509
- https://git.kernel.org/stable/c/974c1c224e85549dc3459f3bb2255bbbdd2b9372
- https://git.kernel.org/stable/c/b0da97c034b6107d14e537e212d4ce8b22109a58
- https://git.kernel.org/stable/c/e3a93ce6e25757b8f375e38b8f91e1d9da4edc1a
- https://git.kernel.org/stable/c/e74c00c6af428a39e564cdc5bd3a3648c6d8de87
HIGH8.3
In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_policy: fix strict mode inbound policy matching match_policy_in() walks sec_path entries from the last transform to the first one, but strict policy matching needs to consume info->pol[] in the same forward order as the rule layout. Derive the strict-match policy position from the number of transforms already consumed so that multi-element inbound rules are matched consistently.
CVSS 3.xHIGH 8.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:HReferences
- https://git.kernel.org/stable/c/392cc1d8408b5665215c1e9290bbf0f92339b043
- https://git.kernel.org/stable/c/4b2b4d7d4e203c92db8966b163edfacb1f0e1e29
- https://git.kernel.org/stable/c/82664d0f1ba25e4f9a71994954abae24c60f4067
- https://git.kernel.org/stable/c/938867e870fb5471bb16f442aeac81326e05bf65
- https://git.kernel.org/stable/c/b130a6eefa02bd4d475f2f059da8bcfb3e7d18d9
- https://git.kernel.org/stable/c/eb323f7b82d2e2f638de0cc2a177803eb20e0707
- https://git.kernel.org/stable/c/f98b7f85e04b40e28b08c461ded0cc79f14f5509
- https://git.kernel.org/stable/c/fc1c518bb1f054831ecabb32da9b8e1dff9699c6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
vrf: Fix a potential NPD when removing a port from a VRF
RCU readers that identified a net device as a VRF port using
netif_is_l3_slave() assume that a subsequent call to
netdev_master_upper_dev_get_rcu() will return a VRF device. They then
continue to dereference its l3mdev operations.
This assumption is not always correct and can result in a NPD [1]. There
is no RCU synchronization when removing a port from a VRF, so it is
possible for an RCU reader to see a new master device (e.g., a bridge)
that does not have l3mdev operations.
Fix by adding RCU synchronization after clearing the IFF_L3MDEV_SLAVE
flag. Skip this synchronization when a net device is removed from a VRF
as part of its deletion and when the VRF device itself is deleted. In
the latter case an RCU grace period will pass by the time RTNL is
released.
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:l3mdev_fib_table_rcu (net/l3mdev/l3mdev.c:181)
[...]
Call Trace:
l3mdev_fib_table_by_index (net/l3mdev/l3mdev.c:201 net/l3mdev/l3mdev.c:189)
__inet_bind (net/ipv4/af_inet.c:499 (discriminator 3))
inet_bind_sk (net/ipv4/af_inet.c:469)
__sys_bind (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:1951 (discriminator 1))
__x64_sys_bind (net/socket.c:1969 (discriminator 1) net/socket.c:1967 (discriminator 1) net/socket.c:1967 (discriminator 1))
do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2674d603a9e6970463b2b9ebcf8e31e90beae169
- https://git.kernel.org/stable/c/2c022f582fd16a470df6ed9e7fb7e9fc48946d49
- https://git.kernel.org/stable/c/3db8d078f7f652379ee394132b169d304f6eb4c1
- https://git.kernel.org/stable/c/468defa0b70902a22f4478c1207624bc1b31c124
- https://git.kernel.org/stable/c/4ab6fc60ed5a0344b60711b09bff1dc238d8d6a4
- https://git.kernel.org/stable/c/8c2b792f04a3db97c9d8d2a45817e93f8884baf5
- https://git.kernel.org/stable/c/a7a97f2303e63ede105c1d55ef53dc497364e11d
- https://git.kernel.org/stable/c/d47204c127992da0c976ac9747070a575912e0fe
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3147ddf5a41c20c45c2eb69e00b62f10f822056a
- https://git.kernel.org/stable/c/645b1ed3259af38b7814242a420bc2081bdd1eb6
- https://git.kernel.org/stable/c/b741c9c6ef59f17c1f104ddf1217ef77f79ed29b
- https://git.kernel.org/stable/c/c34c41446acf6c0d13b5b06c809be11e0f7f2729
- https://git.kernel.org/stable/c/d119775f2bad827edc28071c061fdd4a91f889a5
- https://git.kernel.org/stable/c/ec123873fdc83e7244c8ed6d17b8f8ea6c416a67
- https://git.kernel.org/stable/c/f085971de6d6b8ef946a5e0bcd73ff24509a0f85
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/326941b22806cbf2df1fbfe902b7908b368cce42
- https://git.kernel.org/stable/c/81bf96b0abbfa4cd47ea32e12596aed3855fb2f3
- https://git.kernel.org/stable/c/c6d191164dc81838d8dbf452a6000f68c558d1ae
- https://git.kernel.org/stable/c/cf522703d4f194991615763697ae25a3f9539763
- https://git.kernel.org/stable/c/ea0697129807d718037f618221037aa0660ee3c5
- https://git.kernel.org/stable/c/fc47043f3d9af3efa407665b47f8378ec691ba18
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: jitterentropy - replace long-held spinlock with mutex jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock. To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/01d798e9feb30212952d4e992801ba6bd6a82351
- https://git.kernel.org/stable/c/18216b8ab6904753eaf31baf453cb02ecd202ba4
- https://git.kernel.org/stable/c/4c03e6eb98443dc4d6d422a9780034a5b75376b4
- https://git.kernel.org/stable/c/ec427dc5286da1ed08f2d510e2147a7581b0cb02
- https://git.kernel.org/stable/c/ff734dbd9e2432601a6dcd167cfb0bf8a36d1880
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: handle empty bo and UAF races There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/20a99ea1e2fd720856d6ba497ff26b82c604751f
- https://git.kernel.org/stable/c/981bedbbe61364fcc3a3b87ebaf648a66cd07108
- https://git.kernel.org/stable/c/9894731e513019df22a29e5c52f1c98890355ff1
- https://git.kernel.org/stable/c/c473ae25421fddc3dde247ba7b85225b10641d09
- https://access.redhat.com/security/cve/CVE-2026-52951
- https://bugzilla.redhat.com/show_bug.cgi?id=2492353
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52951.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: libceph: handle rbtree insertion error in decode_choose_args() A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map. This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails. [ idryomov: changelog ]
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a1265a9ab875f92b6a3ffb497404f46cf9d76a3
- https://git.kernel.org/stable/c/0b6a3bcb91bc5bfeda39f0df3b71bab62c13e9da
- https://git.kernel.org/stable/c/4d2b37abda9536808655830d683dc491d31741a8
- https://git.kernel.org/stable/c/534ebc08df97c47d4c7596f336fa31ecbf91519c
- https://git.kernel.org/stable/c/80c73bd1b2b04355d1d0c29be8ccbd25a380905d
- https://git.kernel.org/stable/c/c7bf7864e2924fa5508ac270b0e9364bc13d5a6c
- https://git.kernel.org/stable/c/d289478cfc0bcf81c7914200d6abdcb78bd04ded
- https://git.kernel.org/stable/c/f47430fc1f815e87406e2d3b4e476eff1bc7fd9b
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in crush_decode() A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket().
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0f3604cbe4df14c5e58288ac9f57511e726a222d
- https://git.kernel.org/stable/c/3f42508191e129ee6b5ea96578d5cab14f2a013a
- https://git.kernel.org/stable/c/4c79fc2d598694bda845b46229c9d48b65042970
- https://git.kernel.org/stable/c/6e70ef53e818c53eab28d7b0026b7fd03dddaba5
- https://git.kernel.org/stable/c/cceb10023e76bc89f3fe9238ebd0ccab0fc7c7c5
- https://git.kernel.org/stable/c/ea0d42137f0c06da71e37ffc647aab4c5309599a
- https://git.kernel.org/stable/c/ebe76d58a48a48031b98543d86c4cd30a825b622
- https://git.kernel.org/stable/c/fb176a99e4c1a5a8448a83d83d3606203ba81faa
- https://access.redhat.com/security/cve/CVE-2026-52955
- https://bugzilla.redhat.com/show_bug.cgi?id=2492328
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52955.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential null-ptr-deref in decode_choose_args() A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an array of max_buckets CRUSH buckets is decoded, where some indices may not refer to actual buckets and are therefore set to NULL. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). When decoding a crush_choose_arg_map, a series of choose_args for different buckets is decoded, with the bucket_index being read from the incoming message. It is only checked that the bucket index does not exceed max_buckets, but not that it doesn't point to an index with a NULL bucket. If a (potentially corrupted) message contains a crush_choose_arg_map including such a bucket_index, a null pointer dereference may occur in the subsequent processing when attempting to access the bucket with the given index. This patch fixes the issue by extending the affected check. Now, it is only attempted to access the bucket if it is not NULL.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/28b0a2ab8c82d0bbdeb8013029c67c978ce6e4bf
- https://git.kernel.org/stable/c/301286c0ccd37d66b0e40786fd35a4f19cdbd88a
- https://git.kernel.org/stable/c/312ec973efac0efb9b9ed64214235910e9ecbaa8
- https://git.kernel.org/stable/c/7169f326a23d0f547fcd90e68b72fd387622e126
- https://git.kernel.org/stable/c/a20e16ebfe2fa65348eb4b2dc7deac330ce03e9c
- https://git.kernel.org/stable/c/d55ffad8d422b5d1cc44dad32bd3d25f4471cd9f
- https://git.kernel.org/stable/c/d7a65a34d2453f8cd3e0cc0e1319740af7e24276
- https://git.kernel.org/stable/c/f2f95e6d4b97e70bb876139b0583fc8079983f85
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in osdmap_decode() When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This patch fixes the issue by changing the corresponding part in the ceph_decode_need() check to account for map->max_osd*sizeof(*map->osd_weight).
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0d2dd7e6bb74fd7712aa73457a4a821906c6863a
- https://git.kernel.org/stable/c/35d0ed82d03e5ee77ea4f31f20e29562a7721649
- https://git.kernel.org/stable/c/36a79759a288961b1ff28a68ec2d1f56f6848098
- https://git.kernel.org/stable/c/3f2575bb7f955d42569d96c3e04fa958a0dcf4b4
- https://git.kernel.org/stable/c/48df98d12b15360cd56af5c1f460307b340c1197
- https://git.kernel.org/stable/c/8713bbc4b2b9ad78f803978e54b7e49dd21bd9be
- https://git.kernel.org/stable/c/e7187f33c02488697ec0d01d82bf7a3f8deaba8f
- https://git.kernel.org/stable/c/ee933694645dac062d65fc2743f92bc06fa0db6b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size
The generic/642 test-case can reproduce the kernel crash:
[40243.605254] ------------[ cut here ]------------
[40243.605956] kernel BUG at fs/ceph/xattr.c:918!
[40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI
[40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full)
[40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[40243.611820] Workqueue: ceph-msgr ceph_con_workfn
[40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0
[40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc
[40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287
[40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000
[40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000
[40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000
[40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000
[40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd
[40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000
[40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0
[40243.627408] Call Trace:
[40243.627839]
[40243.628188] __prep_cap+0x3fd/0x4a0
[40243.628789] ? do_raw_spin_unlock+0x4e/0xe0
[40243.629474] ceph_check_caps+0x46a/0xc80
[40243.630094] ? __lock_acquire+0x4a2/0x2650
[40243.630773] ? find_held_lock+0x31/0x90
[40243.631347] ? handle_cap_grant+0x79f/0x1060
[40243.632068] ? lock_release+0xd9/0x300
[40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340
[40243.633429] ? lock_release+0xd9/0x300
[40243.634052] handle_cap_grant+0xcf6/0x1060
[40243.634745] ceph_handle_caps+0x122b/0x2110
[40243.635415] mds_dispatch+0x5bd/0x2160
[40243.636034] ? ceph_con_process_message+0x65/0x190
[40243.636828] ? lock_release+0xd9/0x300
[40243.637431] ceph_con_process_message+0x7a/0x190
[40243.638184] ? kfree+0x311/0x4f0
[40243.638749] ? kfree+0x311/0x4f0
[40243.639268] process_message+0x16/0x1a0
[40243.639915] ? sg_free_table+0x39/0x90
[40243.640572] ceph_con_v2_try_read+0xf58/0x2120
[40243.641255] ? lock_acquire+0xc8/0x300
[40243.641863] ceph_con_workfn+0x151/0x820
[40243.642493] process_one_work+0x22f/0x630
[40243.643093] ? process_one_work+0x254/0x630
[40243.643770] worker_thread+0x1e2/0x400
[40243.644332] ? __pfx_worker_thread+0x10/0x10
[40243.645020] kthread+0x109/0x140
[40243.645560] ? __pfx_kthread+0x10/0x10
[40243.646125] ret_from_fork+0x3f8/0x480
[40243.646752] ? __pfx_kthread+0x10/0x10
[40243.647316] ? __pfx_kthread+0x10/0x10
[40243.647919] ret_from_fork_asm+0x1a/0x30
[40243.648556]
[40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore
[40243.654766] ---[ end trace 0000000000000000 ]---
Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS
maximum xattr size") moved the required_blob_size computation to before
the __build_xattrs() call, introducing a race.
__build_xattrs() releases and reacquires i_ceph_lock during execution.
In that window, handle_cap_grant() may update i_xattrs.blob with a
newer MDS-provided blob and bump i_xattrs.version. When
__bui
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ceph: fix a buffer leak in __ceph_setxattr() The old_blob in __ceph_setxattr() can store ci->i_xattrs.prealloc_blob value during the retry. However, it is never called the ceph_buffer_put() for the old_blob object. This patch fixes the issue of the buffer leak.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3fa13ceefbc5f36131110342743994cb3de80637
- https://git.kernel.org/stable/c/4bfdcefdaa6092a06cacd59389c7756b36e6de8c
- https://git.kernel.org/stable/c/521e5aba857fd267624892c8dd6295f22ce0267e
- https://git.kernel.org/stable/c/5d3cc36b4e77a27ce7b686b7c59c7072bcb3fa8e
- https://git.kernel.org/stable/c/7d3e8d2d648d5f0df29b4710246680f47695fe94
- https://git.kernel.org/stable/c/bc7abce4460e490dcb579eec770f175b150b685f
- https://git.kernel.org/stable/c/d0cb994605c84a159c1d00d72cdc8583c321ef95
- https://git.kernel.org/stable/c/ecf94823c5c6a20790bb76ed2816822b0beb0c22
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI endpoint descriptor scans snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/09141583bd97f4bbd7358e29fd138fe798467cdb
- https://git.kernel.org/stable/c/3d3b2b01a3e73828e201ece96f863e7a3e0cdc6e
- https://git.kernel.org/stable/c/728ab0c72e49ca27185067984cd565425eb69b2e
- https://git.kernel.org/stable/c/a0226560540c16717efcceaf15c862cf115b01d3
- https://git.kernel.org/stable/c/c59159ce10e75b568cd0d4b29efcb0fb0ddecc94
- https://git.kernel.org/stable/c/c65b137d351e21cbc5630e73ef0eb1e1d75f5b20
- https://git.kernel.org/stable/c/d6854daa67be623860f4e1873fd3d3c275aba4ed
- https://git.kernel.org/stable/c/e2f1260a056eb3215c13c48c5378f3e4112dc3af
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/17e76b19de1aff5ff4de64d269290bd1b07a01d3
- https://git.kernel.org/stable/c/918be519c7876329e1b6e2ea1c59f0b75e792dca
- https://git.kernel.org/stable/c/a310b4bebda5e4a1b26520c0cc5145ccd6d617e2
- https://git.kernel.org/stable/c/f9c184a83574549a36ea69b755f650e57d164c78
- https://git.kernel.org/stable/c/fafc97bd01e4c737eaeafadfdadb1af4bbfa7307
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: smb/client: fix possible infinite loop and oob read in symlink_data() On 32-bit architectures, the infinite loop is as follows: len = p->ErrorDataLength == 0xfffffff8 u8 *next = p->ErrorContextData + len next == p On 32-bit architectures, the out-of-bounds read is as follows: len = p->ErrorDataLength == 0xfffffff0 u8 *next = p->ErrorContextData + len next == (u8 *)p - 8
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/1b9331b16b0ed9414dcf7583d8134bdfeb117aae
- https://git.kernel.org/stable/c/1cfa2d59f669db28d6292d10ff87ca6837c781b0
- https://git.kernel.org/stable/c/7d9a7f1f96cd617ee9e75bb22217c709038e26b8
- https://git.kernel.org/stable/c/97a05b0ae9ea5ec052be2eef0f9cc7ce03501bbb
- https://git.kernel.org/stable/c/b41598bf54b3fe528994e573df6008f8f4d0a4f4
- https://git.kernel.org/stable/c/cd4b9b662f0fb9aa97ee6bf9034eca76fc6cab23
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and aen_host_forward() index the GAIT by manually multiplying the index with sizeof(struct zpci_gaite). Since aift->gait is already a struct zpci_gaite pointer, this double-scales the offset, accessing element aisb*16 instead of aisb. This causes out-of-bounds accesses when aisb >= 32 (with ZPCI_NR_DEVICES=512) Fix by removing the erroneous sizeof multiplication.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/11b8ff5b930b351dd1f6f088dce0beb027ac92d0
- https://git.kernel.org/stable/c/16d990a15491cf76cd6eef0846e1b4100e63261a
- https://git.kernel.org/stable/c/31a9d9f9942885aae356a1a57c79e82c5b5b0828
- https://git.kernel.org/stable/c/a99a25db131ece5e6c0f7632da606de631efe4f2
- https://git.kernel.org/stable/c/b22a2da8792a7bfe743c1a922e77fa499ddedbe8
- https://git.kernel.org/stable/c/e7216651b94e92e5433fb2f54b77864642b4ea48
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: KVM: Reject wrapped offset in kvm_reset_dirty_gfn() kvm_reset_dirty_gfn() guards the gfn range with if (!memslot || (offset + __fls(mask)) >= memslot->npages) return; but offset is u64 and the addition is unchecked. The check can be silently bypassed by a u64 wrap. The dirty ring backing those entries is MAP_SHARED at KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the slot and offset fields of any entry between when the kernel pushes them and when KVM_RESET_DIRTY_RINGS consumes them. On reset, kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds them straight back into this check; only the flags handshake is treated as the handover, the slot/offset payload is taken on trust. Crafting two entries entry[i].offset = 0xffffffffffffffc1 entry[i+1].offset = 0 makes the coalescing loop in kvm_dirty_ring_reset() compute delta = (s64)(0 - 0xffffffffffffffc1) = 63 which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn() call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63; the sum is 0 in u64 and the bounds check passes. That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked() unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() == true, i.e. shadow paging, any VM that has allocated shadow roots, or a write-tracked slot -- it reaches gfn_to_rmap(), which indexes slot->arch.rmap[0][] with a near-U64_MAX gfn. That is an out-of-bounds load of a kvm_rmap_head, followed by a conditional clear of PT_WRITABLE_MASK in whatever the loaded pointer points at. The path is reachable from any process holding /dev/kvm. Range-check offset on its own first, so the addition cannot wrap. memslot->npages is bounded well below U64_MAX, so once offset < npages holds, offset + __fls(mask) (with __fls(mask) < BITS_PER_LONG) stays in range.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/01b71b930f15728aa8599478a7ce90c19dcd9fc2
- https://git.kernel.org/stable/c/0d419c23bb11b5c9664de777c47c1f04a235882d
- https://git.kernel.org/stable/c/0eb281eb95b2d4eea4db1da5fe91023aecc97095
- https://git.kernel.org/stable/c/577a8d3bae0531f0e5ccfac919cd8192f920a804
- https://git.kernel.org/stable/c/74f1a22f7a80f03d28ad8551a2d25d563433addf
- https://git.kernel.org/stable/c/b315b033a877b1ee6d827810b5d7bb4392ffcf8d
- https://git.kernel.org/stable/c/ecf9b3ea7847fe14f34b8c41f00de1eb95c747da
- https://access.redhat.com/security/cve/CVE-2026-52969
- https://bugzilla.redhat.com/show_bug.cgi?id=2492434
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52969.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix missing expect put in obj eval nft_ct_expect_obj_eval() allocates an expectation and may call nf_ct_expect_related(), but never drops its local reference. Add nf_ct_expect_put(exp) before return to balance allocation.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/19f94b6fee75b3ef7fbc06f3745b9a771a8a19a4
- https://git.kernel.org/stable/c/1dced0725e2fae3ac3416274db20a7ff5a46931d
- https://git.kernel.org/stable/c/26ab32ec73941871c97562ee1f39587950dc3b68
- https://git.kernel.org/stable/c/2aef1b13d5c0285f340512c6c07eb858fd018fd8
- https://git.kernel.org/stable/c/7b96242ceedfe249f158419f3254bcee04173ffe
- https://git.kernel.org/stable/c/84c422cea5a45fe56be839f25880f21fd33940cd
- https://git.kernel.org/stable/c/cdb9a25dd3416d427e8b2753210f8baf44207577
- https://git.kernel.org/stable/c/ecca618e1e339494911090474ed87742c0f73976
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Cap AEAD AD length to 0x80000000 In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b3a57d218618cb1cc78ddc9ba02c07de84b46f4
- https://git.kernel.org/stable/c/265ac26d1c5e17b34d497cbda1f754a1ec8552bc
- https://git.kernel.org/stable/c/97948906dc8e0ea84775e03e35b60a2063c70193
- https://git.kernel.org/stable/c/a1c5672faf8e93e38c2deac3979cc767ca5cf918
- https://git.kernel.org/stable/c/a4fe4eb580bbc7439f649a496d4cf38415a4021c
- https://git.kernel.org/stable/c/a9f68d9ed38dd6e5a6c6d75b03d25c1c133e321d
- https://git.kernel.org/stable/c/e4c06479d7059888adf2f22bc1ebcf053bf691a2
- https://git.kernel.org/stable/c/e4c4a5074532eaaa14951994a3aad0d479aa7431
- https://git.kernel.org/stable/c/f8a5203596797f394ff3f9aa4005597a92249802
- https://access.redhat.com/security/cve/CVE-2026-52972
- https://bugzilla.redhat.com/show_bug.cgi?id=2492364
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52972.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net: tls: fix strparser anchor skb leak on offload RX setup failure When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb. The normal close path in tls_sk_proto_close() handles cleanup by calling tls_sw_strparser_done() (which calls tls_strp_done()) after dropping the socket lock, because tls_strp_done() does cancel_work_sync() and the strparser work handler takes the socket lock.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0c9f399b37ce22a5ed94cc51f03ed07ac7f38e32
- https://git.kernel.org/stable/c/3c405dfa9619e506e75b8e41f8b29a5b99731877
- https://git.kernel.org/stable/c/58689498ca3384851145a754dbb1d8ed1cf9fb54
- https://git.kernel.org/stable/c/688f12aa44511dd57e448eb670075c6302ad1dc1
- https://git.kernel.org/stable/c/9c54e76f8d6eb11735918777ef0e0509e089557d
- https://git.kernel.org/stable/c/bd07fe6c38b9e44ff3fc02692a53f095c5cc9afc
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl() Two error handling issues exist in xe_exec_queue_create_ioctl(): 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in preempt fence mode, xe_vm_add_compute_exec_queue() has already added the queue to the VM's compute exec queue list. Skipping the kill leaves the queue on that list, leading to a dangling pointer after the queue is freed. 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has succeeded, the error path does not call xe_hw_engine_group_del_exec_queue() to remove the queue from the hw engine group list. The queue is then freed while still linked into the hw engine group, causing a use-after-free. Fix both by: - Changing the xe_hw_engine_group_add_exec_queue() failure path to jump to kill_exec_queue so that xe_exec_queue_kill() properly removes the queue from the VM's compute list. - Adding a del_hw_engine_group label before kill_exec_queue for the xa_alloc() failure path, which removes the queue from the hw engine group before proceeding with the rest of the cleanup. (cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8)
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1be55646d8a2035343b012dcb12210db7bb8b056
- https://git.kernel.org/stable/c/753b149d5a433eb19e0c1b0eb4526a6e26120d1f
- https://git.kernel.org/stable/c/f3cc22d4df3ed58439ea7e21daa54c3608e03b78
- https://git.kernel.org/stable/c/f93b00161213a0fe9f7ff1d8498ee5ca9e0a5c43
- https://access.redhat.com/errata/RHSA-2026:42919
- https://access.redhat.com/errata/RHSA-2026:45192
- https://access.redhat.com/security/cve/CVE-2026-52976
- https://bugzilla.redhat.com/show_bug.cgi?id=2492284
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52976.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0304d60abb9dcc02bc7fe6d1850f4ca206e8f1a0
- https://git.kernel.org/stable/c/0aacb6d18f76552e3e0ee25d9f40d21b3486f4cf
- https://git.kernel.org/stable/c/4e0ed44e51727d56244a822ab941efe507c47966
- https://git.kernel.org/stable/c/69a7cfc66405aeaa2483147653d031b3592ffc9c
- https://git.kernel.org/stable/c/bc7304f3ae20972d11db6e0b1b541c63feda5f05
- https://git.kernel.org/stable/c/e3f95b1ba242e37093305812df7fdbe7288a43ac
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Clear rel_deadline when initializing forked entities A yield-triggered crash can happen when a newly forked sched_entity enters the fair class with se->rel_deadline unexpectedly set. The failing sequence is: 1. A task is forked while se->rel_deadline is still set. 2. __sched_fork() initializes vruntime, vlag and other sched_entity state, but does not clear rel_deadline. 3. On the first enqueue, enqueue_entity() calls place_entity(). 4. Because se->rel_deadline is set, place_entity() treats se->deadline as a relative deadline and converts it to an absolute deadline by adding the current vruntime. 5. However, the forked entity's deadline is not a valid inherited relative deadline for this new scheduling instance, so the conversion produces an abnormally large deadline. 6. If the task later calls sched_yield(), yield_task_fair() advances se->vruntime to se->deadline. 7. The inflated vruntime is then used by the following enqueue path, where the vruntime-derived key can overflow when multiplied by the entity weight. 8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility calculation, and can eventually make all entities appear ineligible. pick_next_entity() may then return NULL unexpectedly, leading to a later NULL dereference. A captured trace shows the effect clearly. Before yield, the entity's vruntime was around: 9834017729983308 After yield_task_fair() executed: se->vruntime = se->deadline the vruntime jumped to: 19668035460670230 and the deadline was later advanced further to: 19668035463470230 This shows that the deadline had already become abnormally large before yield_task_fair() copied it into vruntime. rel_deadline is only meaningful when se->deadline really carries a relative deadline that still needs to be placed against vruntime. A freshly forked sched_entity should not inherit or retain this state. Clear se->rel_deadline in __sched_fork(), together with the other sched_entity runtime state, so that the first enqueue does not interpret the new entity's deadline as a stale relative deadline.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.5
In the Linux kernel, the following vulnerability has been resolved: neigh: let neigh_xmit take skb ownership neigh_xmit always releases the skb, except when no neighbour table is found. But even the first added user of neigh_xmit (mpls) relied on neigh_xmit to release the skb (or queue it for tx). sashiko reported: If neigh_xmit() is called with an uninitialized neighbor table (for example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT and bypasses its internal out_kfree_skb error path. Because the return value of neigh_xmit() is ignored here, does this leak the SKB? Assume full ownership and remove the last code path that doesn't xmit or free skb.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0084712e0bee204b284510cdb63182fd5a30c2b7
- https://git.kernel.org/stable/c/4438113be604ee67a7bf4f81da6e1cca41332ce4
- https://git.kernel.org/stable/c/445e45a2c3a078316a62d2d331a570cf34ef5079
- https://git.kernel.org/stable/c/63063ba60d2dc334e34f1e3f9271d7f3f6f30307
- https://git.kernel.org/stable/c/8a89054a1ec0767aec25ed2bbac933da6ba3cf5a
- https://git.kernel.org/stable/c/9247d59ca15bf60a57dca08103f055d8a4340877
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit() syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called: BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226 The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action(): CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter. The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/23f0e34c64acba15cad4d23e50f41f533da195fa
- https://git.kernel.org/stable/c/24831b0b2ada9fef18d1f486b7b7c444ee5ba637
- https://git.kernel.org/stable/c/30cf9829d09ca958279c937af8e35495cd2f1e09
- https://git.kernel.org/stable/c/423b5b86e14e190f6e3161eb5f2ea5f908295ba7
- https://git.kernel.org/stable/c/4dd7eb94f79486b77ca6b4c8676aedbc465dc802
- https://git.kernel.org/stable/c/5af290c86fa81ddbc86a08d54229af5daa40c6a4
- https://git.kernel.org/stable/c/5db090ca07b28a63fb1499690cf19a3f3adafacb
- https://git.kernel.org/stable/c/6999d70e0eda39af029fa1891c48f0a8832b09d5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/sched: netem: fix queue limit check to include reordered packets The queue limit check in netem_enqueue() uses q->t_len which only counts packets in the internal tfifo. Packets placed in sch->q by the reorder path (__qdisc_enqueue_head) are not counted, allowing the total queue occupancy to exceed sch->limit under reordering. Include sch->q.qlen in the limit check.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0f875d52db4c921da610e481b72f03cc82fdcb72
- https://git.kernel.org/stable/c/39a66e83ea41fe845631eeb8d326953de27d13f9
- https://git.kernel.org/stable/c/4185701fcce6b426b6c3630b25330dddd9c47b0d
- https://git.kernel.org/stable/c/54b5dbacd00dedffd5e2eed76de1c3839996b5e6
- https://git.kernel.org/stable/c/74fcd8e127200a50ee22ba2b45c164722bdb9177
- https://git.kernel.org/stable/c/8450462eaf91d5d2a9e863507b16d18e814baef3
- https://git.kernel.org/stable/c/936a7dd87251f6f3e88983350833edf60fe6a80b
- https://git.kernel.org/stable/c/ef9a41b3870fb90577da5b2de5bd140022d4021e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netdevsim: zero initialize struct iphdr in dummy sk_buff Syzbot reports a KMSAN uninit-value originating from nsim_dev_trap_skb_build, with the allocation also being performed in the same function. Fix this by calling skb_put_zero instead of skb_put to guarantee zero initialization of the whole IP header.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/175556c049eaec14efde8c6475e763b7579b9de7
- https://git.kernel.org/stable/c/1b7b6ae0e93b8d512e208b1378d74af052e4f4e7
- https://git.kernel.org/stable/c/35eaa6d8d6c2ee65e96f507add856e0eacf24591
- https://git.kernel.org/stable/c/6e2cfd0904976e701d7a76b86b694e72af230ab0
- https://git.kernel.org/stable/c/750d0091bebf44975421268d37484ef87060d263
- https://git.kernel.org/stable/c/818f7673ed7f4a29d4b9cee8184c47d6e57162b4
- https://git.kernel.org/stable/c/978ca6ff789f1f19c03288ac20cc1f4774e88490
- https://git.kernel.org/stable/c/bc6002865e8c4fcf9e94975f7cf023448d8764e2
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_sip: don't use simple_strtoul
Replace unsafe port parsing in epaddr_len(), ct_sip_parse_header_uri(),
and ct_sip_parse_request() with a new sip_parse_port() helper that
validates each digit against the buffer limit, eliminating the use of
simple_strtoul() which assumes NUL-terminated strings.
The previous code dereferenced pointers without bounds checks after
sip_parse_addr() and relied on simple_strtoul() on non-NUL-terminated
skb data. A port that reaches the buffer limit without a trailing
character is also rejected as malformed.
Also get rid of all simple_strtoul() usage in conntrack, prefer a
stricter version instead. There are intentional changes:
- Bail out if number is > UINT_MAX and indicate a failure, same for
too long sequences.
While we do accept 05535 as port 5535, we will not accept e.g.
'sip:10.0.0.1:005060'. While its syntactically valid under RFC 3261,
we should restrict this to not waste cycles when presented with
malformed packets with 64k '0' characters.
- Force base 10 in ct_sip_parse_numerical_param(). This is used to fetch
'expire=' and 'rports='; both are expected to use base-10.
- In nf_nat_sip.c, only accept the parsed value if its within the 1k-64k
range.
- epaddr_len now returns 0 if the port is invalid, as it already does
for invalid ip addresses. This is intentional. nf_conntrack_sip
performs lots of guesswork to find the right parts of the message
to parse. Being stricter could break existing setups.
Connection tracking helpers are designed to allow traffic to
pass, not to block it.
Based on an earlier patch from Jenny Guanni Qu .
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/523762e3b6933fff81f01dfa3c60c0774044cdab
- https://git.kernel.org/stable/c/7df9863bf538a626e8a684e59cb2c43eac0ef3c8
- https://git.kernel.org/stable/c/8cd0358379570003659186706e077929d6930c40
- https://git.kernel.org/stable/c/8cf6809cddcbe301aedfc6b51bcd4944d45795f6
- https://git.kernel.org/stable/c/9c6afcb1c3cbb2c0da65b8515ac14d7273872f84
- https://git.kernel.org/stable/c/9f69c323ae0ab517e595c2cc74e0ae0d9d085611
- https://git.kernel.org/stable/c/b3264c977e79d8a25778d4fd11520f00fea1329c
- https://git.kernel.org/stable/c/ea2ecd29b8f4433e52607192ca91084f95787ca0
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/046fa5c72d15cd8e2d592e275697ea399d8f76b0
- https://git.kernel.org/stable/c/3df42a854686fa06484e37ac1a3931c8e3e3453c
- https://git.kernel.org/stable/c/c2a11441538bdbbc5aa003f190995eba93a89b88
- https://git.kernel.org/stable/c/d7c8f95f599b3b38a717d2e771c3f8c174f657c3
- https://git.kernel.org/stable/c/ea8e356acb165cb1fd75537a52e1f66e5e76c538
- https://git.kernel.org/stable/c/f9204a2b78dd18374d3bcf9bf93d9021ce22de1b
- https://access.redhat.com/security/cve/CVE-2026-52989
- https://bugzilla.redhat.com/show_bug.cgi?id=2492443
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52989.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fsnotify: fix inode reference leak in fsnotify_recalc_mask() fsnotify_recalc_mask() fails to handle the return value of __fsnotify_recalc_mask(), which may return an inode pointer that needs to be released via fsnotify_drop_object() when the connector's HAS_IREF flag transitions from set to cleared. This manifests as a hung task with the following call trace: INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotify_sb_delete generic_shutdown_super kill_anon_super cleanup_mnt task_work_run do_exit do_group_exit The race window that triggers the iref leak: Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotify_add_mark_locked(): fsnotify_add_mark_list(): spin_lock(conn->lock) add mark_B(evictable) to list spin_unlock(conn->lock) return /* ---- gap: no lock held ---- */ fsnotify_detach_mark(mark_A): spin_lock(mark_A->lock) clear ATTACHED flag on mark_A spin_unlock(mark_A->lock) fsnotify_put_mark(mark_A) fsnotify_recalc_mask(): spin_lock(conn->lock) __fsnotify_recalc_mask(): /* mark_A skipped: ATTACHED cleared */ /* only mark_B(evictable) remains */ want_iref = false has_iref = true /* not yet cleared */ -> HAS_IREF transitions true -> false -> returns inode pointer spin_unlock(conn->lock) /* BUG: return value discarded! * iput() and fsnotify_put_sb_watched_objects() * are never called */ Fix this by deferring the transition true -> false of HAS_IREF flag from fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fs/adfs: validate nzones in adfs_validate_bblk() Reject ADFS disc records with a zero zone count during boot block validation, before the disc record is used. When nzones is 0, adfs_read_map() passes it to kmalloc_array(0, ...) which returns ZERO_SIZE_PTR, and adfs_map_layout() then writes to dm[-1], causing an out-of-bounds write before the allocated buffer. adfs_validate_dr0() already rejects nzones != 1 for old-format images. Add the equivalent check to adfs_validate_bblk() for new-format images so that a crafted image with nzones == 0 is rejected at probe time. Found by syzkaller.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1586bd2d2fb436a26df20a70e78b000d34a7d159
- https://git.kernel.org/stable/c/1f0ed0f57f0fc87e46fe19a05435c214dc464be2
- https://git.kernel.org/stable/c/33aafd2418a59c96c0389d47ea09026661fa9ec6
- https://git.kernel.org/stable/c/60d82592ac8b5637fbed871381eb0a16df0a492e
- https://git.kernel.org/stable/c/6ff8cca5cdb4f2e0ea6d28ecd78479dd3f221ebc
- https://git.kernel.org/stable/c/a11372a8b1ceaa5e950a84b3b5fbf8228f25e277
- https://git.kernel.org/stable/c/a3fd5dc1c7b0aae947a67dc2e2c037d57557a4de
- https://git.kernel.org/stable/c/dd9d3e16c2d5fa166e13dce07413be51f42c8f5d
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0274f24485fc38032d4093e463dc3ff5c7a667c9
- https://git.kernel.org/stable/c/1d5e589055880fae229e229e1929e087dbe08cf3
- https://git.kernel.org/stable/c/29940fff14110ca48c5ccc168d121665b51bb778
- https://git.kernel.org/stable/c/4d104882bc815d4ec666ace9155f5f52715879a6
- https://git.kernel.org/stable/c/4ee4deadaae7cb2e3d53af0fc889cf92a73413c0
- https://git.kernel.org/stable/c/a438975a6dcdbd70865978c021650d1485586f0b
- https://git.kernel.org/stable/c/d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a
- https://git.kernel.org/stable/c/d3556656c6daebf8def751c7e71d11dd0a180d24
- https://access.redhat.com/errata/RHSA-2026:45115
- https://access.redhat.com/errata/RHSA-2026:45116
- https://access.redhat.com/errata/RHSA-2026:47017
- https://access.redhat.com/errata/RHSA-2026:49212
- https://access.redhat.com/security/cve/CVE-2026-52993
- https://bugzilla.redhat.com/show_bug.cgi?id=2492437
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52993.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/rds: zero per-item info buffer before handing it to visitors rds_for_each_conn_info() and rds_walk_conn_path_info() both hand a caller-allocated on-stack u64 buffer to a per-connection visitor and then copy the full item_len bytes back to user space via rds_info_copy() regardless of how much of the buffer the visitor actually wrote. rds_ib_conn_info_visitor() and rds6_ib_conn_info_visitor() only write a subset of their output struct when the underlying rds_connection is not in state RDS_CONN_UP (src/dst addr, tos, sl and the two GIDs via explicit memsets). Several u32 fields (max_send_wr, max_recv_wr, max_send_sge, rdma_mr_max, rdma_mr_size, cache_allocs) and the 2-byte alignment hole between sl and cache_allocs remain as whatever stack contents preceded the visitor call and are then memcpy_to_user()'d out to user space. struct rds_info_rdma_connection and struct rds6_info_rdma_connection are the only rds_info_* structs in include/uapi/linux/rds.h that are not marked __attribute__((packed)), so they have a real alignment hole. The other info visitors (rds_conn_info_visitor, rds6_conn_info_visitor, rds_tcp_tc_info, ...) write all fields of their packed output struct today and are not known to be vulnerable, but a future visitor that adds a conditional write-path would have the same bug. Reproduction on a kernel built without CONFIG_INIT_STACK_ALL_ZERO=y: a local unprivileged user opens AF_RDS, sets SO_RDS_TRANSPORT=IB, binds to a local address on an RDMA-capable netdev (rxe soft-RoCE on any netdev is sufficient), sendto()'s any peer on the same subnet (fails cleanly but installs an rds_connection in the global hash in RDS_CONN_CONNECTING), then calls getsockopt(SOL_RDS, RDS_INFO_IB_CONNECTIONS). The returned 68-byte item contains 26 bytes of stack garbage including kernel text/data pointers: 0..7 0a 63 00 01 0a 63 00 02 src=10.99.0.1 dst=10.99.0.2 8..39 00 ... gids (memset-zeroed) 40..47 e0 92 a3 81 ff ff ff ff kernel pointer (max_send_wr) 48..55 7f 37 b5 81 ff ff ff ff kernel pointer (rdma_mr_max) 56..59 01 00 08 00 rdma_mr_size (garbage) 60..61 00 00 tos, sl 62..63 00 00 alignment padding 64..67 18 00 00 00 cache_allocs (garbage) Fix by zeroing the per-item buffer in both rds_for_each_conn_info() and rds_walk_conn_path_info() before invoking the visitor. This covers the IPv4/IPv6 IB visitors and hardens all current and future visitors against the same class of bug. No functional change for visitors that fully populate their output. Changes in v2: - retarget at the net tree (subject prefix "[PATCH net v2]", net/rds: prefix in the title) - pick up Reviewed-by tags from Sharath Srinivasan and Allison Henderson
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0797b2e6901827694aa9c34c4c72118c8c97fba1
- https://git.kernel.org/stable/c/5e67cc262afb384e835c3327e9d954eeaedc6a87
- https://git.kernel.org/stable/c/81651e9d7dea1c048d2952f57632a042931d7b43
- https://git.kernel.org/stable/c/912ba2e5704fdb8bc5decda96dfc1a57838f0099
- https://git.kernel.org/stable/c/91ce1bb6e4194dc2321748f68145359dcf86e350
- https://git.kernel.org/stable/c/b6ba93a7b71ed443c9843eb12d27ed86f1e52694
- https://git.kernel.org/stable/c/c7cb9eed8215a790f052f49cdccf577720d2bb62
- https://git.kernel.org/stable/c/c88eb7e8d8397a8c1db59c425332c5a30b2a1682
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix durable fd leak on ClientGUID mismatch in durable v2 open ksmbd_lookup_fd_cguid() returns a ksmbd_file with its refcount incremented via ksmbd_fp_get(). parse_durable_handle_context() in the DURABLE_REQ_V2 case properly releases this reference on every path inside the ClientGUID-match branch, either by calling ksmbd_put_durable_fd() or by transferring ownership to dh_info->fp for a successful reconnect. However, when an entry exists in the global file table with the same CreateGuid but a different ClientGUID, the code simply falls through to the new-open path without dropping the reference obtained from ksmbd_lookup_fd_cguid(). Per MS-SMB2 section 3.3.5.9.10 ("Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context"), the server MUST locate an Open whose Open.CreateGuid matches the request's CreateGuid AND whose Open.ClientGuid matches the ClientGuid of the connection that received the request. If no such Open is found, the server MUST continue with the normal open execution phase. A CreateGuid hit with a ClientGUID mismatch is therefore the "Open not found" case: proceeding with a new open is correct, but the reference obtained purely as a side effect of the lookup must not be leaked. Repeated requests that hit this mismatch pin global_ft entries, prevent __ksmbd_close_fd() from ever running for the corresponding files, and defeat the durable scavenger, leading to long-lived resource leaks. Release the reference in the mismatch path and clear dh_info->fp so subsequent logic does not mistake a non-matching lookup result for a reconnect target.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/06f709d0e531f3e54d88665dd426be3998a774e6
- https://git.kernel.org/stable/c/407b6e699ba8b45b72cc265eed8a1bc8a7191609
- https://git.kernel.org/stable/c/804054d19886ac6628883d82410f6ee42a818664
- https://git.kernel.org/stable/c/8c4a0ef19c8264c150833131af34541495832cd0
- https://git.kernel.org/stable/c/f31beef633fbf2b5af7805fa187a10bcff1d4b49
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/5d05de2f0928d81309a815ecc76d1a3ad72cbc16
- https://git.kernel.org/stable/c/711987ba281fd806322a7cd244e98e2a81903114
- https://git.kernel.org/stable/c/79b90a96688e521771fa6ed3dc7864b76b8df293
- https://git.kernel.org/stable/c/83fc5dd63455a779ea2dd0f7ffee3c920919d80b
- https://git.kernel.org/stable/c/95be653a76793856ff8b2d8bd82c2943c23f5ca8
- https://git.kernel.org/stable/c/c996a90f3071cf43683e5423da31aadbe002b8b4
- https://git.kernel.org/stable/c/edc806f9122961f0d3819f7c69c14cccde31f277
- https://git.kernel.org/stable/c/f4de0777e4554a7de19c920accde6319dd530782
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix out-of-bounds read on option matching In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once and passed by reference to nf_osf_match_one() for each fingerprint checked. During TCP option parsing, nf_osf_match_one() advances the shared ctx->optp pointer. If a fingerprint perfectly matches, the function returns early without restoring ctx->optp to its initial state. If the user has configured NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint. However, because ctx->optp was not restored, the next call to nf_osf_match_one() starts parsing from the end of the options buffer. This causes subsequent matches to read garbage data and fail immediately, making it impossible to log more than one match or logging incorrect matches. Instead of using a shared ctx->optp pointer, pass the context as a constant pointer and use a local pointer (optp) for TCP option traversal. This makes nf_osf_match_one() strictly stateless from the caller's perspective, ensuring every fingerprint check starts at the correct option offset.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/0145548346c4a30981a870a8ca00eac46ba27e85
- https://git.kernel.org/stable/c/1c136f2c44a5913646bac85303612fd0825197a0
- https://git.kernel.org/stable/c/1e19a07291bb8682c14c39a64725a3ae54ab8ccc
- https://git.kernel.org/stable/c/21883587593d7c8bb519a79460a0b5bc5ffbdabd
- https://git.kernel.org/stable/c/32e50f92c7cf3f4eba29622179a5fcdc2aebab41
- https://git.kernel.org/stable/c/70a3f31d25cf2ec9d4ddfa408120171ead955623
- https://git.kernel.org/stable/c/edb78a142d2e5948e63647c0646aa7e7886935f0
- https://git.kernel.org/stable/c/f5ca450087c3baf3651055e7a6de92600f827af3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: restrict several matches to inet family This is a partial revert of: commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions") to allow ipv4 and ipv6 only. - xt_mac - xt_owner - xt_physdev These extensions are not used by ebtables in userspace. Moreover, xt_realm is only for ipv4, since dst->tclassid is ipv4 specific.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/14203f9edf944b3fb63faadd62f38452421ecdfc
- https://git.kernel.org/stable/c/689a91ff18d6448d94c1ab7c076fecdb2b668bef
- https://git.kernel.org/stable/c/76160e04440c9698b989dbd9492a7ec4f520c9ee
- https://git.kernel.org/stable/c/7eaf9c740f33230cb224dc265f3c69f8531ff57b
- https://git.kernel.org/stable/c/9a109751b297b0f2135495749ef5a18ba31ec7d4
- https://git.kernel.org/stable/c/b6fe26f86a1649f84e057f3f15605b08eda15497
- https://git.kernel.org/stable/c/cbeb259f31382de70a70a59ffd0e66f5e80d9818
- https://git.kernel.org/stable/c/fa88161ef56e29bdaa05cc89dbc4ee221e94bfe9
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: remove sprintf usage Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. Increase buffer size in mangle_content_len() while at it. BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270 Write of size 1 at addr [..] vsnprintf+0xea5/0x1270 sprintf+0xb1/0xe0 mangle_content_len+0x1ac/0x280 nf_nat_sdp_session+0x1cc/0x240 process_sdp+0x8f8/0xb80 process_invite_request+0x108/0x2b0 process_sip_msg+0x5da/0xf50 sip_help_tcp+0x45e/0x780 nf_confirm+0x34d/0x990 [..]
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1c9fb8aeed06790d42cdcd00f6c3ce0b9e926c1e
- https://git.kernel.org/stable/c/2f793ba78470a99f40389b7dc60a81d9f5ad3956
- https://git.kernel.org/stable/c/6bbf829b4c1b44c941c47dd0d710f1393258f3d5
- https://git.kernel.org/stable/c/6e7066bdb481a87fe88c4fa563e348c03b2d373d
- https://git.kernel.org/stable/c/8e3be0d12615a173fe260cd42753ca7a001acbf2
- https://git.kernel.org/stable/c/a8e0a32a23d3f34862af3b4da792ecb3a891a9a3
- https://git.kernel.org/stable/c/ab64e61c9323fa6de21bd20da1ddb29a0fb65d34
- https://git.kernel.org/stable/c/c08ff52e44945e6ef4ce0790f49ea761b060c45b
- https://access.redhat.com/security/cve/CVE-2026-53002
- https://bugzilla.redhat.com/show_bug.cgi?id=2492329
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53002.json
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: pppoe: drop PFC frames RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames. If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures. To reduce the attack surface, drop PPPoE PFC frames. Introduce ppp_skb_is_compressed_proto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0cab5d077dd1efd2bd1a47271acc35894f945b4f
- https://git.kernel.org/stable/c/2b5c3c040d020e3ab3b9a8887031202d96843b1e
- https://git.kernel.org/stable/c/49e41b60ccd1bdbe9e218420f716dd5f9a2f9c71
- https://git.kernel.org/stable/c/8a5e840babc5c0fbd10c73728a13192347771ec6
- https://git.kernel.org/stable/c/ba758fdf1399f310b30098b6faa3fd043de47dd2
- https://git.kernel.org/stable/c/cb3beef35ab5e0c1afca9fd7648c6ae499786377
- https://git.kernel.org/stable/c/cc1ff87bce1ccd38410ab10960f576dcd17db679
- https://git.kernel.org/stable/c/fcca1df05322bb04e344dd1178b54b76a08eb7c3
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks sctp_getsockopt_peer_auth_chunks() checks that the caller's optval buffer is large enough for the peer AUTH chunk list with if (len < num_chunks) return -EINVAL; but then writes num_chunks bytes to p->gauth_chunks, which lives at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8 inside optval. The check is missing the sizeof(struct sctp_authchunks) = 8-byte header. When the caller supplies len == num_chunks (for any num_chunks > 0) the test passes but copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes past the declared buffer. The sibling function sctp_getsockopt_local_auth_chunks() at the next line already has the correct check: if (len < sizeof(struct sctp_authchunks) + num_chunks) return -EINVAL; Align the peer variant with its sibling. Reproducer confirms on v7.0-13-generic: an unprivileged userspace caller that opens a loopback SCTP association with AUTH enabled, queries num_chunks with a short optval, then issues the real getsockopt with len == num_chunks and sentinel bytes painted past the buffer observes those sentinel bytes overwritten with the peer's AUTH chunk type. The bytes written are under the peer's control but land in the caller's own userspace; this is not a kernel memory corruption, but it is a kernel-side contract violation that can silently corrupt adjacent userspace data.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0cf004ffb61cd32d140531c3a84afe975f9fc7ea
- https://git.kernel.org/stable/c/2b5a2c957c7769d40110f725cf23987fcef50d75
- https://git.kernel.org/stable/c/6849b995cda88a677bf08a05765d1db7905974fc
- https://git.kernel.org/stable/c/6bcf8fe4ef7967b22b814cbae9a57bbd3c853410
- https://git.kernel.org/stable/c/70a089cc9590aa347a61e84434116ab74619e3c3
- https://git.kernel.org/stable/c/a132e199de69e2a45628aa8534df1bf5d44e1b6e
- https://git.kernel.org/stable/c/d45c7e99caf915b0f6c716bd8ffe9d45b9685761
- https://git.kernel.org/stable/c/d67fbc6dea5dbf7f46c618ebf65910a276078e20
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0069813e6ca9309eca78022bcb3aeb1e9ef90a12
- https://git.kernel.org/stable/c/085e31a811ef234ef8c3e219c4636dfebfe7e10f
- https://git.kernel.org/stable/c/1e1f0f89ee4692a64be3f3707ff8ac1ae57b03e7
- https://git.kernel.org/stable/c/38bdbc897c0d83a3e2b925a51b69420f1feba29a
- https://git.kernel.org/stable/c/7bff2c8fe5c35ae58bf73104f53db3676e6e5d94
- https://git.kernel.org/stable/c/7c66b368c6ff453f99cb39d84af93e908e51eef2
- https://git.kernel.org/stable/c/aff0f28f5be803de2452ce702631c021fcd9ce8a
- https://git.kernel.org/stable/c/f996edd7615e686ada141b7f3395025729ff8ccb
- https://access.redhat.com/errata/RHSA-2026:45192
- https://access.redhat.com/errata/RHSA-2026:47010
- https://access.redhat.com/errata/RHSA-2026:47011
- https://access.redhat.com/errata/RHSA-2026:47017
- https://access.redhat.com/security/cve/CVE-2026-53006
- https://bugzilla.redhat.com/show_bug.cgi?id=2492363
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53006.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: fix use-after-free in advance_sched() on schedule switch In advance_sched(), when should_change_schedules() returns true, switch_schedules() is called to promote the admin schedule to oper. switch_schedules() queues the old oper schedule for RCU freeing via call_rcu(), but 'next' still points into an entry of the old oper schedule. The subsequent 'next->end_time = end_time' and rcu_assign_pointer(q->current_entry, next) are use-after-free. Fix this by selecting 'next' from the new oper schedule immediately after switch_schedules(), and using its pre-calculated end_time. setup_first_end_time() sets the first entry's end_time to base_time + interval when the schedule is installed, so the value is already correct. The deleted 'end_time = sched_base_time(admin)' assignment was also harmful independently: it would overwrite the new first entry's pre-calculated end_time with just base_time.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0e62171df8ed4804d00db088f17eed06468233fa
- https://git.kernel.org/stable/c/105425b1969c5affe532713cfac1c0b320d7ac2b
- https://git.kernel.org/stable/c/1bd286fa3e21200133478ed523cc6a2788baf38a
- https://git.kernel.org/stable/c/3471874578160a28c171a607fa069f24062634b8
- https://git.kernel.org/stable/c/7256996e1ef553716817f3bfd077c2f3b48b582f
- https://git.kernel.org/stable/c/a8fc396519ef4f081bc545e88f61241728bb78d7
- https://git.kernel.org/stable/c/b73235da5dde77ed1264f9767b62c28c9d71fd78
- https://git.kernel.org/stable/c/eee072fe16c646190d33ae69c9983d8de1562bf8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nexthop: fix IPv6 route referencing IPv4 nexthop syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/29c95185ba32b621fbc3800fb86e7dc3edf5c2be
- https://git.kernel.org/stable/c/613c8f4a501421dd258b07ea614205d4e16ec845
- https://git.kernel.org/stable/c/6275796f22bb382f3e9aa58ed0b4ef7bdad78cb8
- https://git.kernel.org/stable/c/9c2d6770a5f4545a307eb66979bef7656a34d621
- https://git.kernel.org/stable/c/aaac3bed034239e1d75732211d9b05f30b0b4f35
- https://git.kernel.org/stable/c/ad85961004fd4bd2f31209ac4b07612c6cefb9e7
- https://git.kernel.org/stable/c/b3b7e850e1541f0520c4a12ec884255c30427ff6
- https://git.kernel.org/stable/c/ceffe81a0be92afc0cd1340bc8ca46559cce9bb4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: macvlan: fix macvlan_get_size() not reserving space for IFLA_MACVLAN_BC_CUTOFF macvlan_get_size() does not account for IFLA_MACVLAN_BC_CUTOFF, but macvlan_fill_info() conditionally includes it when port->bc_cutoff != 1. This causes nla_put_s32() to fail with -EMSGSIZE when the netlink skb runs out of space, triggering a WARN_ON in rtnetlink and preventing the interface from being dumped. The bug can be reproduced with: ip link add macvlan0 link eth0 type macvlan mode bridge ip link set macvlan0 type macvlan bc_cutoff 0 ip -d link show macvlan0 # fails with -EMSGSIZE The bc_cutoff feature was added in commit 954d1fa1ac93 ("macvlan: Add netlink attribute for broadcast cutoff"), which added the nla_put_s32() call in macvlan_fill_info() but missed adding the corresponding nla_total_size(4) in macvlan_get_size(). A follow-up commit 55cef78c244d ("macvlan: add forgotten nla_policy for IFLA_MACVLAN_BC_CUTOFF") fixed the missing nla_policy entry but still did not fix the size calculation.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1c004f14ccdc11585625c168bb9a7c5e1b8afb0c
- https://git.kernel.org/stable/c/4979252758387b338ca968ba7e0515b0ae2257e3
- https://git.kernel.org/stable/c/77ecfa4e27f282d224215895ddfbeb916fc75e24
- https://git.kernel.org/stable/c/b6b7154e9f5d75b608ceb2d05b376de8c638c40e
- https://git.kernel.org/stable/c/fa92a77b0ed4d5f11a71665a232ac5a54a4b055d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir In tcf_blockcast_redir(), when iterating block ports to redirect packets to multiple devices, the mac_header_xmit flag is queried from the wrong device. The loop sends to dev_prev but queries dev_is_mac_header_xmit(dev) — which is the NEXT device in the iteration, not the one being sent to. This causes tcf_mirred_to_dev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong mac_header_xmit flag, leading to skb header corruption. In the worst case, skb_push_rcsum with an incorrect mac_len can exhaust headroom and panic. The last device in the loop is handled correctly (line 365-366 uses dev_is_mac_header_xmit(dev_prev)), confirming this is a copy-paste oversight for the intermediate devices. Fix by using dev_prev instead of dev for the mac_header_xmit query, consistent with the device actually being sent to.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: erofs: unify lcn as u64 for 32-bit platforms As sashiko reported [1], `lcn` was typed as `unsigned long` (or `unsigned int` sometimes), which is only 32 bits wide on 32-bit platforms, which causes `(lcn << lclusterbits)` to be truncated at 4 GiB. In order to consolidate the logic, just use `u64` consistently around the codebase. [1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - copy IV using skcipher ivsize AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/227c1e1d9e2aa4cfc65ba446d5690da1f546cda4
- https://git.kernel.org/stable/c/798d409a8949f3f495f238549b86de2886b129bd
- https://git.kernel.org/stable/c/939061b2d0f7f15114e34b4ce878ef50ff4089c3
- https://git.kernel.org/stable/c/a7a1f3cdd64d8a165d9b8c9e9ad7fb46ac19dfc4
- https://git.kernel.org/stable/c/bb01d8f1f385bc9034ca114d3508c7fdea24fc9a
- https://git.kernel.org/stable/c/df9784bb5b637ac80f4a2768a58ca9a50bef28a9
- https://git.kernel.org/stable/c/dfb2cf434829819268fe50f41542aad318ad62b2
- https://git.kernel.org/stable/c/eecee15e263ccb8cd77170a56ab6c969cb54dd6a
- https://access.redhat.com/errata/RHSA-2026:38491
- https://access.redhat.com/errata/RHSA-2026:39494
- https://access.redhat.com/security/cve/CVE-2026-53016
- https://bugzilla.redhat.com/show_bug.cgi?id=2492269
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53016.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix integer overflow in UNMAP bounds check sbc_execute_unmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow. Add an overflow check matching the pattern already used for WRITE_SAME in the same file.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/02115986d027ade793e7f6be87e91d6a796d0aa3
- https://git.kernel.org/stable/c/2bf2d65f76697820dbc4227d13866293576dd90a
- https://git.kernel.org/stable/c/2e1ed9a7b6ea5bfefb5d80a02b1c71c7dee1f0dd
- https://git.kernel.org/stable/c/3facdecc3fcf115cc4f9b3d8f118d6705e2456a8
- https://git.kernel.org/stable/c/51075df70c46e60a9773f2dcd28299e40dac36fb
- https://git.kernel.org/stable/c/5efc3ef4758f8d98c257419fa21daca3227de61a
- https://git.kernel.org/stable/c/c08ab702c4699c6efb9d60bdb15b73e7a627ee7e
- https://git.kernel.org/stable/c/d7aef29573c7c5cdb2dfad939253287a6329c2a4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: bound enumeration string aggregation populate_enum_data() aggregates firmware-provided value-modifier and possible-value strings into fixed 512-byte struct members. The current code bounds each individual source string but then appends every string and separator with raw strcat() and no remaining-space check. Switch the aggregation loops to a bounded append helper and reject enumeration packages whose combined strings do not fit in the destination buffers. [ij: add include]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3c34471c26abc52a37f5ad90949e2e4b8027eb14
- https://git.kernel.org/stable/c/5a04f9a36930792f6d64e28d43609e158d09b665
- https://git.kernel.org/stable/c/75c738d4f27fa18a2a033de153bd40302bde6a66
- https://git.kernel.org/stable/c/7b3dc1f764bf24eb99474a5de8173b0b43a8b071
- https://git.kernel.org/stable/c/90b118d264845f7aaf539ac49f7c75f1f29590e2
- https://git.kernel.org/stable/c/ba0843c1955864401295f7ba3b420afe19f2266d
- https://git.kernel.org/stable/c/c5683ca4949a514fbe656c6d0d08c4c126e21db9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: terminate the cached volume label after UTF-8 conversion ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0b11fcbe80a59acdf58337d80ebb5f72201d73d6
- https://git.kernel.org/stable/c/32b0686369e0afbb3549a0d93e2d8517da84cd30
- https://git.kernel.org/stable/c/54d564b762389679e2f8fb9eeb20af7e82371e1c
- https://git.kernel.org/stable/c/5cd0707b81cb4589f00aec5c4c1288bd0980d2a4
- https://git.kernel.org/stable/c/6136bbb054f7ab9f51ae99915541633b18bcef90
- https://git.kernel.org/stable/c/a6cd43fe9b083fa23fe1595666d5738856cb261a
- https://git.kernel.org/stable/c/bc7a0c34c4ca259cfddf3bc18fc5b3c6411d26ed
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Validate node_id in arena_alloc_pages() arena_alloc_pages() accepts a plain int node_id and forwards it through the entire allocation chain without any bounds checking. Validate node_id before passing it down the allocation chain in arena_alloc_pages().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL deref in map_kptr_match_type for scalar regs Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") refactored map_kptr_match_type() to branch on btf_is_kernel() before checking base_type(). A scalar register stored into a kptr slot has no btf, so the btf_is_kernel(reg->btf) call dereferences NULL. Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf access.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a36c1f72888bca0237295a4da19cd91821a90be
- https://git.kernel.org/stable/c/4d0a375887ab4d49e4da1ff10f9606cab8f7c3ad
- https://git.kernel.org/stable/c/520454e839710c327808c2fcc98e28cee77355fc
- https://git.kernel.org/stable/c/6982653ce5f119982aa58f1af58e7bfbebf39252
- https://git.kernel.org/stable/c/da1d615ce49a47986a8864e2371a26e97861085c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Take state lock for af_unix iter When a BPF iterator program updates a sockmap, there is a race condition in unix_stream_bpf_update_proto() where the `peer` pointer can become stale[1] during a state transition TCP_ESTABLISHED -> TCP_CLOSE. CPU0 bpf CPU1 close -------- ---------- // unix_stream_bpf_update_proto() sk_pair = unix_peer(sk) if (unlikely(!sk_pair)) return -EINVAL; // unix_release_sock() skpair = unix_peer(sk); unix_peer(sk) = NULL; sock_put(skpair) sock_hold(sk_pair) // UaF More practically, this fix guarantees that the iterator program is consistently provided with a unix socket that remains stable during iterator execution. [1]: BUG: KASAN: slab-use-after-free in unix_stream_bpf_update_proto+0x155/0x490 Write of size 4 at addr ffff8881178c9a00 by task test_progs/2231 Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x170/0x4f3 kasan_report+0xe4/0x1c0 kasan_check_range+0x125/0x200 unix_stream_bpf_update_proto+0x155/0x490 sock_map_link+0x71c/0xec0 sock_map_update_common+0xbc/0x600 sock_map_update_elem+0x19a/0x1f0 bpf_prog_bbbf56096cdd4f01_selective_dump_unix+0x20c/0x217 bpf_iter_run_prog+0x21e/0xae0 bpf_iter_unix_seq_show+0x1e0/0x2a0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x63/0x80 kmem_cache_alloc_noprof+0x1d5/0x680 sk_prot_alloc+0x59/0x210 sk_alloc+0x34/0x470 unix_create1+0x86/0x8a0 unix_stream_connect+0x318/0x15b0 __sys_connect+0xfd/0x130 __x64_sys_connect+0x72/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2236: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x47/0x70 kmem_cache_free+0x11c/0x590 __sk_destruct+0x432/0x6e0 unix_release_sock+0x9b3/0xf60 unix_release+0x8a/0xf0 __sock_release+0xb0/0x270 sock_close+0x18/0x20 __fput+0x36e/0xac0 fput_close_sync+0xe5/0x1a0 __x64_sys_close+0x7d/0xd0 do_syscall_64+0xf7/0x5e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1a59cc6b65fd3ad9915aae5970d859109d4ce9fb
- https://git.kernel.org/stable/c/64c2f93fc3254d3bf5de4445fb732ee5c451edb6
- https://git.kernel.org/stable/c/921920c34cb591947dd30c692500795a69f1e3fa
- https://git.kernel.org/stable/c/98f744d204e5d6fca589cd2c44c3190a0c71697f
- https://git.kernel.org/stable/c/c6f4015eac2e3cbc3cb7a17539e10bbb5c2049c3
- https://git.kernel.org/stable/c/d0d124dbcef9318e326956137b31671407094bd4
- https://access.redhat.com/security/cve/CVE-2026-53033
- https://bugzilla.redhat.com/show_bug.cgi?id=2492281
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53033.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix af_unix null-ptr-deref in proto update unix_stream_connect() sets sk_state (`WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED)`) _before_ it assigns a peer (`unix_peer(sk) = newsk`). sk_state == TCP_ESTABLISHED makes sock_map_sk_state_allowed() believe that socket is properly set up, which would include having a defined peer. IOW, there's a window when unix_stream_bpf_update_proto() can be called on socket which still has unix_peer(sk) == NULL. CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) ... sk_pair = unix_peer(sk) sock_hold(sk_pair) sock_hold(newsk) smp_mb__after_atomic() unix_peer(sk) = newsk BUG: kernel NULL pointer dereference, address: 0000000000000080 RIP: 0010:unix_stream_bpf_update_proto+0xa0/0x1b0 Call Trace: sock_map_link+0x564/0x8b0 sock_map_update_common+0x6e/0x340 sock_map_update_elem_sys+0x17d/0x240 __sys_bpf+0x26db/0x3250 __x64_sys_bpf+0x21/0x30 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Initial idea was to move peer assignment _before_ the sk_state update[1], but that involved an additional memory barrier, and changing the hot path was rejected. Then a NULL check during proto update in unix_stream_bpf_update_proto() was considered[2], but the follow-up discussion[3] focused on the root cause, i.e. sockmap update taking a wrong lock. Or, more specifically, missing unix_state_lock()[4]. In the end it was concluded that teaching sockmap about the af_unix locking would be unnecessarily complex[5]. Complexity aside, since BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT are allowed to update sockmaps, sock_map_update_elem() taking the unix lock, as it is currently implemented in unix_state_lock(): spin_lock(&unix_sk(s)->lock), would be problematic. unix_state_lock() taken in a process context, followed by a softirq-context TC BPF program attempting to take the same spinlock -- deadlock[6]. This way we circled back to the peer check idea[2]. [1]: https://lore.kernel.org/netdev/ba5c50aa-1df4-40c2-ab33-a72022c5a32e@rbox.co/ [2]: https://lore.kernel.org/netdev/20240610174906.32921-1-kuniyu@amazon.com/ [3]: https://lore.kernel.org/netdev/7603c0e6-cd5b-452b-b710-73b64bd9de26@linux.dev/ [4]: https://lore.kernel.org/netdev/CAAVpQUA+8GL_j63CaKb8hbxoL21izD58yr1NvhOhU=j+35+3og@mail.gmail.com/ [5]: https://lore.kernel.org/bpf/CAAVpQUAHijOMext28Gi10dSLuMzGYh+jK61Ujn+fZ-wvcODR2A@mail.gmail.com/ [6]: https://lore.kernel.org/bpf/dd043c69-4d03-46fe-8325-8f97101435cf@linux.dev/ Summary of scenarios where af_unix/stream connect() may race a sockmap update: 1. connect() vs. bpf(BPF_MAP_UPDATE_ELEM), i.e. sock_map_update_elem_sys() Implemented NULL check is sufficient. Once assigned, socket peer won't be released until socket fd is released. And that's not an issue because sock_map_update_elem_sys() bumps fd refcnf. 2. connect() vs BPF program doing update Update restricted per verifier.c:may_update_sockmap() to BPF_PROG_TYPE_TRACING/BPF_TRACE_ITER BPF_PROG_TYPE_SOCK_OPS (bpf_sock_map_update() only) BPF_PROG_TYPE_SOCKET_FILTER BPF_PROG_TYPE_SCHED_CLS BPF_PROG_TYPE_SCHED_ACT BPF_PROG_TYPE_XDP BPF_PROG_TYPE_SK_REUSEPORT BPF_PROG_TYPE_FLOW_DISSECTOR BPF_PROG_TYPE_SK_LOOKUP Plus one more race to consider: CPU0 bpf CPU1 connect -------- ------------ WRITE_ONCE(sk->sk_state, TCP_ESTABLISHED) sock_map_sk_state_allowed(sk) sock_hold(newsk) smp_mb__after_atomic() ---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/041eb6348d73ee5e15fc8161f1eac5a6e8289ca0
- https://git.kernel.org/stable/c/37bfcd164161b47d00b1c3bd20adc816a6977ce0
- https://git.kernel.org/stable/c/4913c94a3adcdbb64c552110c0c243cb1fdbb317
- https://git.kernel.org/stable/c/75b7d3b3f8bd4e59eb3af1b11a43c64c0c2db6f4
- https://git.kernel.org/stable/c/a94d3dd78ee8b63e6b8ad629081c952c93ee5a10
- https://git.kernel.org/stable/c/dca38b7734d2ea00af4818ff3ae836fab33d5d5a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix af_unix iter deadlock bpf_iter_unix_seq_show() may deadlock when lock_sock_fast() takes the fast path and the iter prog attempts to update a sockmap. Which ends up spinning at sock_map_update_elem()'s bh_lock_sock(): WARNING: possible recursive locking detected test_progs/1393 is trying to acquire lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: sock_map_update_elem+0xdb/0x1f0 but task is already holding lock: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(slock-AF_UNIX); lock(slock-AF_UNIX); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by test_progs/1393: #0: ffff88814b59c790 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x59/0x10d0 #1: ffff88811ec25fd8 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: bpf_seq_read+0x42c/0x10d0 #2: ffff88811ec25f58 (slock-AF_UNIX){+...}-{3:3}, at: __lock_sock_fast+0x37/0xe0 #3: ffffffff85a6a7c0 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x51d/0xb00 Call Trace: dump_stack_lvl+0x5d/0x80 print_deadlock_bug.cold+0xc0/0xce __lock_acquire+0x130f/0x2590 lock_acquire+0x14e/0x2b0 _raw_spin_lock+0x30/0x40 sock_map_update_elem+0xdb/0x1f0 bpf_prog_2d0075e5d9b721cd_dump_unix+0x55/0x4f4 bpf_iter_run_prog+0x5b9/0xb00 bpf_iter_unix_seq_show+0x1f7/0x2e0 bpf_seq_read+0x42c/0x10d0 vfs_read+0x171/0xb20 ksys_read+0xff/0x200 do_syscall_64+0x6b/0x3a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3cef33b9813b78f227942572fb317afcd5c9ac94
- https://git.kernel.org/stable/c/4d328dd695383224aa750ddee6b4ad40c0f8d205
- https://git.kernel.org/stable/c/527057ebe8076dfbcaef51195ff1b7508646be2c
- https://git.kernel.org/stable/c/66d9fab4565eafe1afe7ba0581f79b76073b60fa
- https://git.kernel.org/stable/c/87828b380956d4986f59f2c086e0b09b3e6cdaae
- https://git.kernel.org/stable/c/bd3592129f24243713673a07225cf1f15a9bb835
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix off-by-one in check_imm signed range check check_imm(bits, imm) is used in the arm64 BPF JIT to verify that a branch displacement (in arm64 instruction units) fits into the signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding before it is handed to the encoder. The macro currently tests for (imm > 0 && imm >> bits) || (imm < 0 && ~imm >> bits) which admits values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check admits one extra bit of range on each side. In particular, for check_imm19(), values in [2^18, 2^19) slip past the check but do not fit into the 19-bit signed imm19 field of B.cond. aarch64_insn_encode_immediate() then masks the raw value into the 19-bit field, setting bit 18 (the sign bit) and flipping a forward branch into a backward one. Same class of issue exists for check_imm26() and the B/BL encoding. Shift by (bits - 1) instead of bits so the actual signed N-bit range is enforced.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1a113b5497297871699cd498b1b83542e0db7f15
- https://git.kernel.org/stable/c/1dd8be4ec722ce54e4cace59f3a4ba658111b3ec
- https://git.kernel.org/stable/c/6927f0d6794aa73318bbfa929f1ff6065b0620df
- https://git.kernel.org/stable/c/7fd3b41260c6120e7b60164afea5d961af6224f9
- https://git.kernel.org/stable/c/a5dfeb3b61065039488342d43ae06d4729d955d4
- https://git.kernel.org/stable/c/fb74defa1cca1a73177c0c761e641332e4f979a3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix deadlock in hid_post_reset() You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4e900465296ce9fb12ed47dc77389b8dde95bfe0
- https://git.kernel.org/stable/c/56d318ef8766f0deb08517fd8f3007256ea7997d
- https://git.kernel.org/stable/c/8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72
- https://git.kernel.org/stable/c/90550af0aad5e75110073c501e4fb42fca20ff80
- https://git.kernel.org/stable/c/ad4505d2ab3aaac6498f17649608e70e80034bf2
- https://git.kernel.org/stable/c/b3d16611d7cd78e9d5c6baa19b61b7caf9f1ab5e
- https://git.kernel.org/stable/c/c7abd0e6c87441e99c759d40eb6fe589634e3041
- https://git.kernel.org/stable/c/eeceb6f4dd42065fdda3a526a93d08b8fb90fb69
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ima_fs: Correctly create securityfs files for unsupported hash algos
ima_tpm_chip->allocated_banks[i].crypto_id is initialized to
HASH_ALGO__LAST if the TPM algorithm is not supported. However there
are places relying on the algorithm to be valid because it is accessed
by hash_algo_name[].
On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
==================================================================
BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
Call Trace:
dump_stack_lvl+0x61/0x90
print_report+0xc4/0x580
? kasan_addr_to_slab+0x26/0x80
? create_securityfs_measurement_lists+0x396/0x440
kasan_report+0xc2/0x100
? create_securityfs_measurement_lists+0x396/0x440
create_securityfs_measurement_lists+0x396/0x440
ima_fs_init+0xa3/0x300
ima_init+0x7d/0xd0
init_ima+0x28/0x100
do_one_initcall+0xa6/0x3e0
kernel_init_freeable+0x455/0x740
kernel_init+0x24/0x1d0
ret_from_fork+0x38/0x80
ret_from_fork_asm+0x11/0x20
The buggy address belongs to the variable:
hash_algo_name+0xb8/0x420
Memory state around the buggy address:
ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
^
ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
==================================================================
Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
tpm tpm0: TPM with unsupported bank algorithm 0x0027
That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0
Library Part 2: Structures", page 51 [1].
See also the related U-Boot algorithms update [2].
Thus solve the problem by creating a file name with "_tpm_alg_"
postfix if the crypto algorithm isn't initialized.
This is how it looks on the test machine (patch ported to v6.12 release):
# ls -1 /sys/kernel/security/ima/
ascii_runtime_measurements
ascii_runtime_measurements_tpm_alg_27
ascii_runtime_measurements_sha1
ascii_runtime_measurements_sha256
binary_runtime_measurements
binary_runtime_measurements_tpm_alg_27
binary_runtime_measurements_sha1
binary_runtime_measurements_sha256
policy
runtime_measurements_count
violations
[1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf
[2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate group add input before caching [BUG] OCFS2_IOC_GROUP_ADD can trigger a BUG_ON in ocfs2_set_new_buffer_uptodate(): kernel BUG at fs/ocfs2/uptodate.c:509! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_set_new_buffer_uptodate+0x194/0x1e0 fs/ocfs2/uptodate.c:509 Code: ffffe88f 42b9fe4c 89e64889 dfe8b4df Call Trace: ocfs2_group_add+0x3f1/0x1510 fs/ocfs2/resize.c:507 ocfs2_ioctl+0x309/0x6e0 fs/ocfs2/ioctl.c:887 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 x64_sys_call+0x1144/0x26a0 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x93/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7bbfb55a966d [CAUSE] ocfs2_group_add() calls ocfs2_set_new_buffer_uptodate() on a user-controlled group block before ocfs2_verify_group_and_input() validates that block number. That helper is only valid for newly allocated metadata and asserts that the block is not already present in the chosen metadata cache. The code also uses INODE_CACHE(inode) even though the group descriptor belongs to main_bm_inode and later journal accesses use that cache context instead. [FIX] Validate the on-disk group descriptor before caching it, then add it to the metadata cache tracked by INODE_CACHE(main_bm_inode). Keep the validation failure path separate from the later cleanup path so we only remove the buffer from that cache after it has actually been inserted. This keeps the group buffer lifetime consistent across validation, journaling, and cleanup.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/22544ddedf381ed5191cfc783aea8d6c936bc201
- https://git.kernel.org/stable/c/6c5e70409c1961fe1278968f038eaaed6cc1145a
- https://git.kernel.org/stable/c/70b672833f4025341c11b22c7f83778a5cd611bc
- https://git.kernel.org/stable/c/76bd722db0a92b84ccd99e03796a0b6f1ae71c31
- https://git.kernel.org/stable/c/aed87e866d1a321edb9703563c2faa8fec89835d
- https://git.kernel.org/stable/c/b9ae3942deec4c9e3fa2070521f90910f7490011
- https://git.kernel.org/stable/c/e7c2cb552e6eb85c0f5aefdd7f0f7c3c8591a6a3
- https://git.kernel.org/stable/c/f7e139d7563f6947ad509fb468903941d0bb7ddd
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate bg_bits during freefrag scan [BUG] A crafted filesystem can trigger an out-of-bounds bitmap walk when OCFS2_IOC_INFO is issued with OCFS2_INFO_FL_NON_COHERENT. BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: use-after-free in test_bit_le include/asm-generic/bitops/le.h:21 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] BUG: KASAN: use-after-free in ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] BUG: KASAN: use-after-free in ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 Read of size 8 at addr ffff888031bce000 by task syz.0.636/1435 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xd1/0x650 mm/kasan/report.c:482 kasan_report+0xfb/0x140 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 [inline] kasan_check_range+0x11c/0x200 mm/kasan/generic.c:200 __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] test_bit_le include/asm-generic/bitops/le.h:21 [inline] ocfs2_info_freefrag_scan_chain fs/ocfs2/ioctl.c:495 [inline] ocfs2_info_freefrag_scan_bitmap fs/ocfs2/ioctl.c:588 [inline] ocfs2_info_handle_freefrag fs/ocfs2/ioctl.c:662 [inline] ocfs2_info_handle_request+0x1c66/0x3370 fs/ocfs2/ioctl.c:754 ocfs2_info_handle+0x18d/0x2a0 fs/ocfs2/ioctl.c:828 ocfs2_ioctl+0x632/0x6e0 fs/ocfs2/ioctl.c:913 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x197/0x1e0 fs/ioctl.c:583 ... [CAUSE] ocfs2_info_freefrag_scan_chain() uses on-disk bg_bits directly as the bitmap scan limit. The coherent path reads group descriptors through ocfs2_read_group_descriptor(), which validates the descriptor before use. The non-coherent path uses ocfs2_read_blocks_sync() instead and skips that validation, so an impossible bg_bits value can drive the bitmap walk past the end of the block. [FIX] Compute the bitmap capacity from the filesystem format with ocfs2_group_bitmap_size(), report descriptors whose bg_bits exceeds that limit, and clamp the scan to the computed capacity. This keeps the freefrag report going while avoiding reads beyond the buffer.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/05d0cbea41167b6b061c6ba5b70ee5a9a7a24c9e
- https://git.kernel.org/stable/c/0998674eec138c55e9e349b9cbd9dbc5129a9cc8
- https://git.kernel.org/stable/c/3e167e230d19cd273108bab2e4c61800fc335ae8
- https://git.kernel.org/stable/c/4c2d62ddde8928db12f4608950b67a20e67deab2
- https://git.kernel.org/stable/c/8f687eeed3da3012152b0f9473f578869de0cd7b
- https://git.kernel.org/stable/c/bb2906a1065ec28de021bac2ed03f2624edd7d07
- https://git.kernel.org/stable/c/bb3c54d1e71578521111f1a1ee7d5f4761a242b8
- https://git.kernel.org/stable/c/e0dcf12665d6dde37facf790803cdad44d5c328c
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix listxattr handling when the buffer is full [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/2323084c17370304f49c84b354fe7b3edbb264fe
- https://git.kernel.org/stable/c/2685df8577a38d83b367c8cf52eda9dc286959ff
- https://git.kernel.org/stable/c/46e66fefb83811958127bc9ad736983ec629d82b
- https://git.kernel.org/stable/c/50033ec1350fe68abdc63b950ced7ae57364b77a
- https://git.kernel.org/stable/c/6f702b00b8124c5d3525f19172934544826a114d
- https://git.kernel.org/stable/c/a35a1c2b170b5b578b1b3fecb95694796552af9a
- https://git.kernel.org/stable/c/d12f558e6200b3f47dbef9331ed6d115d2410e59
- https://git.kernel.org/stable/c/d919b905939eda93393e3572900ff70dbad2b47f
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: validate qr_numregions in dlm_match_regions() Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()". In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues: - Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer. - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds. This patch (of 2): The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer. Add a bounds check for qr_numregions before entering the loops.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/1f8b91275912cd428289c1fb424bebd7ff5302bd
- https://git.kernel.org/stable/c/3c2d0de23ae4be22b6c18e8f0915be74d3b5fb21
- https://git.kernel.org/stable/c/3f474c33ebc2e2ca3fcb587d7de4375348f13373
- https://git.kernel.org/stable/c/6c6e8fc3c007319981647b410c29bb5775048551
- https://git.kernel.org/stable/c/7ab3fbb01bc6d79091bc375e5235d360cd9b78be
- https://git.kernel.org/stable/c/d3d5efade0c79dac1cac98c0cb1115432f804439
- https://git.kernel.org/stable/c/f37de46149db49abd2b24f4f0c5a88cf4dfb5f47
- https://git.kernel.org/stable/c/f69551139caf6d24242a0ad049ee46b264e3aee0
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: memory: tegra124-emc: Fix dll_change check The code checking whether the specified memory timing enables DLL in the EMRS register was reversed. DLL is enabled if bit A0 is low. Fix the check.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/05f138fc7e27ee8e7a83ccf966c3fa26cda44dda
- https://git.kernel.org/stable/c/1793249c067a4b28e1aba0ad0e4d73aa9f9e165a
- https://git.kernel.org/stable/c/1ebbbef47d11cc90219c081492ccf995aaa3e9b3
- https://git.kernel.org/stable/c/2369b1831161356e1bcb51385d3e532dc4fe2771
- https://git.kernel.org/stable/c/7e19e72f306484996c52ff96cc92f69b78ed5435
- https://git.kernel.org/stable/c/9597ab9a8296ab337e6820f8a717ff621078b632
- https://git.kernel.org/stable/c/a85967331144fde9300be38bb44d2558eb6b742e
- https://git.kernel.org/stable/c/db0ae80865b515cc0b705c85877ec00f7eebe9fe
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine ksmbd_crypt_message() sets a NULL completion callback on AEAD requests and does not handle the -EINPROGRESS return code from async hardware crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns -EINPROGRESS, ksmbd treats it as an error and immediately frees the request while the hardware DMA operation is still in flight. The DMA completion callback then dereferences freed memory, causing a NULL pointer crash: pc : qce_skcipher_done+0x24/0x174 lr : vchan_complete+0x230/0x27c ... el1h_64_irq+0x68/0x6c ksmbd_free_work_struct+0x20/0x118 [ksmbd] ksmbd_exit_file_cache+0x694/0xa4c [ksmbd] Use the standard crypto_wait_req() pattern with crypto_req_done() as the completion callback, matching the approach used by the SMB client in fs/smb/client/smb2ops.c. This properly handles both synchronous engines (immediate return) and async engines (-EINPROGRESS followed by callback notification).
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3e298897f41c61450c2e7a4f457e8b2485eb35b3
- https://git.kernel.org/stable/c/57b47231055b431ed0a1a55f33cac32981564405
- https://git.kernel.org/stable/c/7164b3953cefd540e7ebca828c793bc6869cfbc4
- https://git.kernel.org/stable/c/8ef183216feaa24b66b940510d8b68f680eb56e9
- https://git.kernel.org/stable/c/8fcefe840fa8c14ce667768e5b043286ac3bbcbe
- https://git.kernel.org/stable/c/b46aa129fa2807bfe1545fe74d9295d53c51520b
- https://git.kernel.org/stable/c/cc2da381875d4a67026e4c8feb3dba51a2a2d1bc
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect sizeof in phys array reallocation The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/22022cd8851703a58f67615a17bc7e9e8682785b
- https://git.kernel.org/stable/c/48a428215782321b56956974f23593e40ce84b7a
- https://git.kernel.org/stable/c/5e185330d902b12fe8e6eb4b8514b5d736d8d66d
- https://git.kernel.org/stable/c/608e1f7bc9d171ab26c1fba288c97fc76363c27d
- https://git.kernel.org/stable/c/67adde6bfdfd563a54b045d59aeb9a2d90c80697
- https://git.kernel.org/stable/c/8be69e9245f805566bac68ffc8574b64735fd996
- https://git.kernel.org/stable/c/ab3f7098a3a27175b91cfc947950f5c26855801b
- https://git.kernel.org/stable/c/e0e6b14995fd6fa2c0df8c712d76ab32f0694c31
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: gfs2: prevent NULL pointer dereference during unmount When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/233a0945a4b1dbe3f38c30afb7d05b76c67f1193
- https://git.kernel.org/stable/c/2fc4c868c9060f424fd4a7cacb0aec5082aba4de
- https://git.kernel.org/stable/c/74b4dbb946060a3233604d91859a9abd3708141d
- https://git.kernel.org/stable/c/abd73229f0e886a91a16ea781ab656bd9b4d1ee8
- https://git.kernel.org/stable/c/cec55674354794eddb80b914f73a6bf9b7fc304a
- https://git.kernel.org/stable/c/d8ffae016c4a78693fe1283335d0b6833a9c1366
- https://git.kernel.org/stable/c/e15f16761594e80b15776980b27c35477655a135
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: gfs2: add some missing log locking Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(), gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp->sd_log_flush_lock, but these functions require exclusion against concurrent transactions. To fix that, add a non-locking __gfs2_log_flush() function. Then, in gfs2_logd(), take sdp->sd_log_flush_lock before calling the above mentioned log flushing functions and __gfs2_log_flush().
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/3b28eb75afe520972bacc833850c2b30aa0824cd
- https://git.kernel.org/stable/c/49d9be0722da3a4a893ba905720cba1921834ec3
- https://git.kernel.org/stable/c/98e8bf249c790d56de1abc4a5f8bd68035a00921
- https://git.kernel.org/stable/c/bf5fcd9c37c2546beaf7b401d31aefd89017dc3d
- https://git.kernel.org/stable/c/ca95342cb1b39062a03c115830286f0a426053d5
- https://git.kernel.org/stable/c/f2f225cf505ac016132ded21690f3ba0a080a4e8
- https://git.kernel.org/stable/c/fe2c8d051150b90b3ccb85f89e3b1d636cb88ec8
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: quota: Fix race of dquot_scan_active() with quota deactivation dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/2bdc80f4619411e5bd4a3ef23f51e14021ed457c
- https://git.kernel.org/stable/c/61e25f664dc2a08299e07d84c85776abc2350f75
- https://git.kernel.org/stable/c/6678dde265708003c2b42551af4a2e3cb05decd5
- https://git.kernel.org/stable/c/82cbdb4c1ebb5ea7d7bd45c18d3483b5bd32ebc1
- https://git.kernel.org/stable/c/ac8a2e0d287ebf35e5d7e51e260b4e146648ba4a
- https://git.kernel.org/stable/c/e93ab401da4b2e2c1b8ef2424de2f238d51c8b2d
- https://git.kernel.org/stable/c/f9438cb8c8ec3adc84b2b450a3aab0123d074c3b
- https://git.kernel.org/stable/c/fdd424d7c35633ac577fd87d1b043d1b8a6cd350
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on When PERST# is deasserted twice (assert -> deassert -> assert -> deassert), a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc (PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify() and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers on the controller core. The call chain that causes the timeout: pex_ep_event_pex_rst_deassert() pci_epc_deinit_notify() pci_epf_test_epc_deinit() pci_epf_test_clear_bar() pci_epc_clear_bar() dw_pcie_ep_clear_bar() __dw_pcie_ep_reset_bar() dw_pcie_dbi_ro_wr_en() <- Accesses 0x8bc DBI register reset_control_deassert(pcie->core_rst) <- Core powered on HERE The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only accessible after the controller core is powered on via reset_control_deassert(pcie->core_rst). Accessing them before this point results in a CBB timeout because the hardware is not yet operational. Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to after reset_control_deassert(pcie->core_rst), ensuring the controller is fully powered on before any DBI register accesses occur.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: qdsp6: topology: check widget type before accessing data Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1ac96689ce2984f4f6ef8892fcb65da377408421
- https://git.kernel.org/stable/c/296810e91f21a21794886c57f954495d8afd7f32
- https://git.kernel.org/stable/c/6d2491a585202a967ed91f30ec5960024f2536d0
- https://git.kernel.org/stable/c/8e8cd78b6000c9d19db249a5a68287158f288ef3
- https://git.kernel.org/stable/c/a1a24d4b8c9682f9b7a9138f636ff004c721aef1
- https://git.kernel.org/stable/c/d5bfdd28e0cdd45043ae6e0ac168a451d59283dc
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix clone_alias() to use the original device's devid Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument. This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device. Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: fix mismatch between power and frequency During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Patchwork: https://patchwork.freedesktop.org/patch/710077/
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0ccf4f27b4652570b5de3de02a89a86435559de9
- https://git.kernel.org/stable/c/0f7dd5839cfabaf9c007fb718ec66e907a473c93
- https://git.kernel.org/stable/c/1181a7028d37e0b1e720a36125a03f5db97e3d27
- https://git.kernel.org/stable/c/9830999c9e065c1813ec5435bfe4eab98ee54a87
- https://git.kernel.org/stable/c/bc1dccc518cc5ab5140fba06c27e7188e0ed342b
- https://git.kernel.org/stable/c/c5735c7d0eef7a5240f9c1c66e44ba52a1be58d6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. We need the connector to be set before that. Unlike in legacy cases with flag !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1af3b42e08a957e53bab8e1897393fe0a27d9fbf
- https://git.kernel.org/stable/c/43d6508ddbf9fb974fbc359a033154f78c9d4c8b
- https://git.kernel.org/stable/c/5302015daf26ef6b48e067f2b86c9482ac19e015
- https://git.kernel.org/stable/c/a3611554e599d1a24b45fd8415bacb72ce861e4b
- https://git.kernel.org/stable/c/cf2ac2cac8b319f89b3a3851ca0c5ffb6a549575
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm log: fix out-of-bounds write due to region_count overflow The local variable region_count in create_log_context() is declared as unsigned int (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297, because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit overflow check before the value is assigned to lc->region_count.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/12bd5b88e91a02785244ff1d20fb157e96e9cdc8
- https://git.kernel.org/stable/c/3ec74da927b4e171a6fc0e77b1188ba4d019af51
- https://git.kernel.org/stable/c/44ab8875ae4a2842bde2d756bed195d375e0debb
- https://git.kernel.org/stable/c/4ec8323b9f0764a14d532b1ae9b87f8a9fecb867
- https://git.kernel.org/stable/c/b455903eed4558982be0811f5b7f44f6bbc4ff57
- https://git.kernel.org/stable/c/c20e36b7631d83e7535877f08af8b0af72c44b1a
- https://git.kernel.org/stable/c/d4ac87567f86a55c3c92e9a5144dcd943a9772a1
- https://git.kernel.org/stable/c/defe483e47173768c227532694dc78cb65db5f09
- https://access.redhat.com/errata/RHSA-2026:45114
- https://access.redhat.com/errata/RHSA-2026:45115
- https://access.redhat.com/errata/RHSA-2026:45116
- https://access.redhat.com/errata/RHSA-2026:45192
- https://access.redhat.com/errata/RHSA-2026:47248
- https://access.redhat.com/security/cve/CVE-2026-53059
- https://bugzilla.redhat.com/show_bug.cgi?id=2492277
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53059.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
dm cache metadata: fix memory leak on metadata abort retry
When failing to acquire the root_lock in dm_cache_metadata_abort because
the block_manager is read-only, the temporary block_manager created
outside the root_lock is not properly released, causing a memory leak.
Reproduce steps:
This can be reproduced by reloading a new table while the metadata
is read-only. While the second call to dm_cache_metadata_abort is
caused by lack of support for table preload in dm-cache, mentioned
in commit 9b1cc9f251af ("dm cache: share cache-metadata object across
inactive and active DM tables"), it exposes the memory leak in
dm_cache_metadata_abort when the function is called multiple times.
Specifically, dm-cache fails to sync the new cache object's mode during
preresume, creating the reproducer condition.
This issue could also occur through concurrent metadata_operation_failed
calls due to races in cache mode updates, but the table preload scenario
below provides a reliable reproducer.
1. Create a cache device with some faulty trailing metadata blocks
dmsetup create cmeta <
unreferenced object 0xffff8880080c2010 (size 16):
comm "dmsetup", pid 132, jiffies 4294982580
hex dump (first 16 bytes):
00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ...
backtrace (crc 3118f31c):
kmemleak_alloc+0x28/0x40
__kmalloc_cache_noprof+0x3d9/0x510
dm_block_manager_create+0x51/0x140
dm_cache_metadata_abort+0x85/0x320
metadata_operation_failed+0x103/0x1e0
cache_preresume+0xacd/0xe70
dm_table_resume_targets+0xd3/0x320
__dm_resume+0x1b/0xf0
dm_resume+0x127/0x170
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/044ca491d4086dc5bf233e9fcb71db52df32f633
- https://git.kernel.org/stable/c/14f60e957f34f95a626caec76a8fae88cf4c397f
- https://git.kernel.org/stable/c/15c30997dca681f90dbf2d45ee629c1828bf0c0d
- https://git.kernel.org/stable/c/322a3b70368d49e39591fe9fc6c07d262128b05f
- https://git.kernel.org/stable/c/4311ca59a1891d33c4c8b7946f98c34f167fe833
- https://git.kernel.org/stable/c/6b97cc7a42905755c56bbddc33aa8b792205caee
- https://git.kernel.org/stable/c/b0bd35535bdb6f58505f3a30ee5793986943997a
- https://git.kernel.org/stable/c/d1a79620c419a0af1911f99c873014b30740e303
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix dirty mapping checking in passthrough mode switching As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/01b22656d8a68dbeae59f8b80866e7b11936b20a
- https://git.kernel.org/stable/c/12105c7f18375d7615dad7605d89eadae7eb12a6
- https://git.kernel.org/stable/c/1443c32f24d6d8bcdf4beceef2afc09290b98717
- https://git.kernel.org/stable/c/21c503d60a257e54ca3ac58e2721bd24501d5bde
- https://git.kernel.org/stable/c/322586745bd1a0e5f3559fd1635fdeb4dbd1d6b8
- https://git.kernel.org/stable/c/5c98a3f1d7a554c9e920aa31daf92af6b5bbb8cc
- https://git.kernel.org/stable/c/bd5a2c1018938e6b32670728bdb32a3f0efff00f
- https://git.kernel.org/stable/c/c2e86f647561fcf5e1c6eba7d75e9e0c4299c94d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: fix missing locks in invalidating cache blocks In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted"
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1b2bec4a7dcf5f00b7a1cbeeec8997841d783513
- https://git.kernel.org/stable/c/2b62d0611c9af14a16bddf22df2612b4f40eb5a1
- https://git.kernel.org/stable/c/2d1f7b65f5deedd2e6b09fdc6ea27f8375f24b45
- https://git.kernel.org/stable/c/4991b5a08751e2e82488fb93ae08849b6aea10d9
- https://git.kernel.org/stable/c/93627a29d4b66d4a2def938dfb8610cc80ae454b
- https://git.kernel.org/stable/c/9a5fdfb9e57ec3a8ad2b8fce5e5ffa42d53b130e
- https://git.kernel.org/stable/c/ac5ee99443891bdb161f5539606a66a1b5e72542
- https://git.kernel.org/stable/c/c348ae47d8e65f06429fa41adce9ad986b696766
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix write hang in passthrough mode The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/05798d091ebcfb6d68228890e593f209e8ac940d
- https://git.kernel.org/stable/c/4ca8b8bd952df7c3ccdc68af9bd3419d0839a04b
- https://git.kernel.org/stable/c/64d6519b00be4116d365bd31f33a5e5ce2944c1a
- https://git.kernel.org/stable/c/9fa18d0b981776b190ca4632942a7c2174052b78
- https://git.kernel.org/stable/c/b8ace9e96983abb20ccf39edce8a60f1bb0b83d8
- https://git.kernel.org/stable/c/ecb10c193cbebf5e6984246a9b4ff1f95d45ed87
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix null-deref with concurrent writes in passthrough mode
In passthrough mode, when dm-cache starts to invalidate a cache
entry and bio prison cell lock fails due to concurrent write to
the same cached block, mg->cell remains NULL. The error path in
invalidate_complete() attempts to unlock and free the cell
unconditionally, causing a NULL pointer dereference:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT
RIP: 0010:dm_cell_unlock_v2+0x3f/0x210
Call Trace:
invalidate_complete+0xef/0x430
map_bio+0x130f/0x1a10
cache_map+0x320/0x6b0
__map_bio+0x458/0x510
dm_submit_bio+0x40e/0x16d0
__submit_bio+0x419/0x870
Reproduce steps:
1. Create a cache device
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 262144 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
2. Promote the first data block into cache
fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \
--direct=1 --size=64k
3. Reload the cache into passthrough mode
dmsetup suspend cache
dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0"
dmsetup resume cache
4. Write to the first cached block concurrently
fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \
--randrepeat=0 --direct=1 --numjobs=2 --size 64k
Fix by checking if mg->cell is valid before attempting to unlock it.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/01264a6a3a3ad7ac1d73443299cd5a9568002454
- https://git.kernel.org/stable/c/0aa745fea1f8dc81bcdd0a45e215b6706727b482
- https://git.kernel.org/stable/c/25dcc1989c194ba2b5fb6d03cbb9b83814ac0d15
- https://git.kernel.org/stable/c/7d1f98d668ee34c1d15bdc0420fdd062f24a27c0
- https://git.kernel.org/stable/c/a2635d541a93fd111e743cf14b6275dc81be2abc
- https://git.kernel.org/stable/c/c7fb6bc864c4910b344dafa36dd5028e9b980768
- https://git.kernel.org/stable/c/df3b8ef06cc62de4fca5d2108e285085b3cffd44
- https://git.kernel.org/stable/c/ee38fb00e1a80f46a4990e38f25ecb04ae7b7417
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: use managed regmap_field allocations The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/002a5f925d42eca8ad547e55a4ae22714cfe9dec
- https://git.kernel.org/stable/c/1696fad8b259a2d46e51cd6e17e4bcdbe02279fa
- https://git.kernel.org/stable/c/43b67761d486d719128e164536e58de5a81dff9b
- https://git.kernel.org/stable/c/4b8dba4527727623a97948aff9f0969a14c203a9
- https://git.kernel.org/stable/c/7422a11a753daacbc2409513cf65e1de0d17c291
- https://git.kernel.org/stable/c/9641071e3a8e0bc664477a0e54db5f9815f0fb79
- https://git.kernel.org/stable/c/a3f3c332882c98ae7553af372191116d1384ca52
- https://git.kernel.org/stable/c/c3af3bcfc1deb3b230cc266a2ac75bca8f4dfba9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/sun4i: backend: fix error pointer dereference The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR()
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/06277983eca4a31d3c2114fa33d99a6e82484b11
- https://git.kernel.org/stable/c/47038159c559824f4dbfb5b0d87b9b3416663372
- https://git.kernel.org/stable/c/779c2f10743fc021f2f0ebe2b188cadfb973c5e4
- https://git.kernel.org/stable/c/cf615b90a11a39a28e313be5e508e94bcde72016
- https://git.kernel.org/stable/c/e9bef62f1bb9fcb38223730657af20f4c6283c16
- https://git.kernel.org/stable/c/ea51fd96aca01381e8f1ac0c671a57b7619193bb
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/komeda: fix integer overflow in AFBC framebuffer size check The AFBC framebuffer size validation calculates the minimum required buffer size by adding the AFBC payload size to the framebuffer offset. This addition is performed without checking for integer overflow. If the addition oveflows, the size check may incorrectly succed and allow userspace to provide an undersized drm_gem_object, potentially leading to out-of-bounds memory access. Add usage of check_add_overflow() to safely compute the minimum required size and reject the framebuffer if an overflow is detected. This makes the AFBC size validation more robust against malformed. Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/02ff8a7d3d0eecc546b9ab4c07b3d7c65d485583
- https://git.kernel.org/stable/c/779ec12c85c9e4547519e3903a371a3b26a289de
- https://git.kernel.org/stable/c/8165e8b28fdf392c2c7412518d602b4f193812a8
- https://git.kernel.org/stable/c/872d923b852705054bc099af663da862fdc1097d
- https://git.kernel.org/stable/c/a3a2a9bdc0f9c2d863a5a290cb2d4a565f7268e7
- https://git.kernel.org/stable/c/d8a541906860aa3519b1874780d933c766918a7c
- https://git.kernel.org/stable/c/e27b58095d7d3ac72f230e318838dee956258460
- https://git.kernel.org/stable/c/fe1f80f8f6e8611ac6349b9d464e8750443390cf
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndo_open() is protected.
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/183128da0406b1c10e6f60b7b9fe70788b9c8c1d
- https://git.kernel.org/stable/c/1921f91298d1388a0bb9db8f83800c998b649cb3
- https://git.kernel.org/stable/c/3128b294b426533c8d9162187446d93a8a160359
- https://git.kernel.org/stable/c/7bad93e99737e4a5c0c14ac50c05152cf4e28022
- https://git.kernel.org/stable/c/866d3d9b87751b1944168fd82615505e0c0fd6cf
- https://git.kernel.org/stable/c/acbf45bd584d924b320bee2a7fe2a26f64904d95
- https://git.kernel.org/stable/c/ea690b3b6e58ae00979af8195b4cc24df466b65e
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0ccd75c51f620374086f359e906917676e699a1c
- https://git.kernel.org/stable/c/330b20ec97916961ee0e6c29c06bc0fa7c96e64c
- https://git.kernel.org/stable/c/42776497cdbc9a665b384a6dcb85f0d4bd927eab
- https://git.kernel.org/stable/c/5501d055a1ce3c747141e3955ba8cf034d193f3e
- https://git.kernel.org/stable/c/77a853aec710b2fdf41fa298ea3cbc9a4358f917
- https://git.kernel.org/stable/c/96dca51715d86559ed6ed8028e5445cecb80f3ae
- https://git.kernel.org/stable/c/dc89961b76f12aff47124c1df4bdb32a080f4d0c
- https://git.kernel.org/stable/c/fe1188abdae9b7a8199dcdfcf9244d5e5d61eb14
- https://access.redhat.com/errata/RHSA-2026:42550
- https://access.redhat.com/errata/RHSA-2026:42552
- https://access.redhat.com/errata/RHSA-2026:42919
- https://access.redhat.com/errata/RHSA-2026:43307
- https://access.redhat.com/security/cve/CVE-2026-53071
- https://bugzilla.redhat.com/show_bug.cgi?id=2492458
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53071.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF. Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held. Fix by holding the lock.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/385b2d0468a0871fc716c549fa3b0c257c7dbcb3
- https://git.kernel.org/stable/c/541d5bf9b5afaf41090b2a3aa7b47f2db2ff801f
- https://git.kernel.org/stable/c/5c7209a341ff2ac338b2b0375c34a307b37c9ac2
- https://git.kernel.org/stable/c/60e3f4ff02d1f2d55bfbf2ca32a97285a9771ee4
- https://git.kernel.org/stable/c/6b4d226d01ab7da0d2027a2a1e3a6079152e5065
- https://git.kernel.org/stable/c/9d4a6c0f43fc5e4d4f062e8e450e5483eb74176e
- https://git.kernel.org/stable/c/c27224daf0b08efbb2b24ed64b6139b294f5473a
- https://git.kernel.org/stable/c/c7777f534a8018ae4bb1c80d8925af4df588a314
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/194f029a4d7f739e44ebc1f473120187b4de5104
- https://git.kernel.org/stable/c/356dee1bcac4d0d9152390561fa63331ebff211b
- https://git.kernel.org/stable/c/3daa5818e473ed60eb69d8b5c71b651909d28c5a
- https://git.kernel.org/stable/c/68d39ea5e0adc9ecaea1ce8abd842ec972eb8718
- https://git.kernel.org/stable/c/a673cf6c4ac702cb79ac1f4d7fc4de763a6a3e40
- https://git.kernel.org/stable/c/ebb39b2d81731b83ee71a1ba6dd0291a57b5ac07
- https://git.kernel.org/stable/c/ed4033fb85ccaaf6c3983be3c7b037e48253d232
- https://git.kernel.org/stable/c/f4b69c35813c432973d340d3600c01de106ed474
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a04db240effd85773f66244645a28cedddb72d2
- https://git.kernel.org/stable/c/12bec2bd4b76d81c5d3996bd14ec1b7f4d983747
- https://git.kernel.org/stable/c/1f882c492d46f90bdb36f4936876c88c28dab21c
- https://git.kernel.org/stable/c/6a9f38d5ff11e00bc54baab752642978805e81eb
- https://git.kernel.org/stable/c/6def5fe753cbe5b279ee5fd10327b2611cbddaca
- https://git.kernel.org/stable/c/7254267799d083280c0e53effc101a33add95f7b
- https://git.kernel.org/stable/c/8042240412de3222d27b31e89d29336961cad9e4
- https://git.kernel.org/stable/c/e6aa481f21fc7a41ed344767ea25aae9d03fae71
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1a8a51ce85075a56a743b6f142606dd2696a391c
- https://git.kernel.org/stable/c/2bb6379416fd19f44c3423a00bfd8626259f6067
- https://git.kernel.org/stable/c/3b2c2157dc2afc5c17cd7238afefca92f1ef330e
- https://git.kernel.org/stable/c/5013be175c7ffd8b39efbc3c9c4db5b10b85fea8
- https://git.kernel.org/stable/c/5080e188c914110034bbc569d5cfa2f06204681d
- https://git.kernel.org/stable/c/67e901e28d177ac9a9bed76d69ce3471e704a89e
- https://git.kernel.org/stable/c/954745d0223e7caec917c0b2d1a889ff56fa6e54
- https://git.kernel.org/stable/c/c9edd90c57ae23692fff6b049fdfa4572a9fd532
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix OOB in pcpu_init_value An out-of-bounds read occurs when copying element from a BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the same value_size that is not rounded up to 8 bytes. The issue happens when: 1. A CGROUP_STORAGE map is created with value_size not aligned to 8 bytes (e.g., 4 bytes) 2. A pcpu map is created with the same value_size (e.g., 4 bytes) 3. Update element in 2 with data in 1 pcpu_init_value assumes that all sources are rounded up to 8 bytes, and invokes copy_map_value_long to make a data copy, However, the assumption doesn't stand since there are some cases where the source may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data. the verifier verifies exactly the size that the source claims, not the size rounded up to 8 bytes by kernel, an OOB happens when the source has only 4 bytes while the copy size(4) is rounded up to 8.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/576afddfee8d1108ee299bf10f581593540d1a36
- https://git.kernel.org/stable/c/6086079e6d1c32ba4c4b422612b8aebb1129a96c
- https://git.kernel.org/stable/c/634a793d0e1c822412095d25a1338f8831ad894c
- https://git.kernel.org/stable/c/e0378419b0e20178b5d100b27c9cc7e51064202e
- https://git.kernel.org/stable/c/e19c5ed9f1922a6854073f8651a63fa7be26e9e9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/rds: Restrict use of RDS/IB to the initial network namespace Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/07035306bf722f4676a1aee35cbeb3732c76194e
- https://git.kernel.org/stable/c/3174fc703d081d2ca538b22fba734e3ad5b52322
- https://git.kernel.org/stable/c/3e7f14cd5a51533404e1ae4809caab46073fb5c7
- https://git.kernel.org/stable/c/a7494479757d60d2413bfaa087f8431a26eea032
- https://git.kernel.org/stable/c/b6a54f5e9ce9b97ae641855378d71c5154a085c0
- https://git.kernel.org/stable/c/c244b79adffad89a5173cf8bfaa06a6b40bbd09b
- https://git.kernel.org/stable/c/ebf71dd4aff46e8e421d455db3e231ba43d2fa8a
- https://git.kernel.org/stable/c/fb407343c0c16e94584707b2dfdd350a5f81b000
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/13c02881e49aac4c82b261faa26db9edf2567231
- https://git.kernel.org/stable/c/2f2ec8e7730e21fc9bd49e0de9cdd58213ea24d0
- https://git.kernel.org/stable/c/691adf738817275368ed56311b7d798d617823a3
- https://git.kernel.org/stable/c/7d73c72cccac651acc891377a5e623e4021c6380
- https://access.redhat.com/security/cve/CVE-2026-53081
- https://bugzilla.redhat.com/show_bug.cgi?id=2492322
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53081.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1d3abf0c3ddeefc6f6d913aa129acc06fce8240a
- https://git.kernel.org/stable/c/2951656b0de00153f2687f3a093890bce72b6215
- https://git.kernel.org/stable/c/578f3aba427c938fecfa0d8c83d9acb213a9b24a
- https://git.kernel.org/stable/c/987af7625ceb1ee59d70eb0abd7af11c75e45d79
- https://git.kernel.org/stable/c/bf9a38803b2626b01cc769aaf13485d8650f576f
- https://git.kernel.org/stable/c/d4cceb5184538613572fb79319453f281b1eeacb
- https://git.kernel.org/stable/c/d9ce2a4b679122397d7f35bad7be46913ad1ca80
- https://git.kernel.org/stable/c/e9cf4018d74237d142cd66243c821d13593270f0
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix RCU stall in bpf_fd_array_map_clear()
Add a missing cond_resched() in bpf_fd_array_map_clear() loop.
For PROG_ARRAY maps with many entries this loop calls
prog_array_map_poke_run() per entry which can be expensive, and
without yielding this can cause RCU stalls under load:
rcu: Stack dump where RCU GP kthread last ran:
CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef)
Workqueue: events prog_array_map_clear_deferred
RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246
Call Trace:
prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096
__fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925
bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline]
prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141
process_one_work+0x898/0x19d0 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3319 [inline]
worker_thread+0x770/0x10b0 kernel/workqueue.c:3400
kthread+0x465/0x880 kernel/kthread.c:464
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153
ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4406942e65ca128c56c67443832988873c21d2e9
- https://git.kernel.org/stable/c/67bdb4b0d26f2d6bbf1798a925ef5a3b9ed7357a
- https://git.kernel.org/stable/c/71ddb7defc442ab38c53123c384fedbfd8410a15
- https://git.kernel.org/stable/c/b1f7158a86f3cbac4d5a32beb55ca0f8027d44cd
- https://git.kernel.org/stable/c/e1ed678855e315f90c70c1723e94157a9a82e660
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bpf: return VMA snapshot from task_vma iterator Holding the per-VMA lock across the BPF program body creates a lock ordering problem when helpers acquire locks that depend on mmap_lock: vm_lock -> i_rwsem -> mmap_lock -> vm_lock Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then drop the lock before returning. The BPF program accesses only the snapshot. The verifier only trusts vm_mm and vm_file pointers (see BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference- counted with get_file() under the lock and released via fput() on the next iteration or in _destroy(). vm_mm is already correct because lock_vma_under_rcu() verifies vma->vm_mm == mm. All other pointers are left as-is by memcpy() since the verifier treats them as untrusted.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: fix mm lifecycle in open-coded task_vma iterator The open-coded task_vma iterator reads task->mm locklessly and acquires mmap_read_trylock() but never calls mmget(). If the task exits concurrently, the mm_struct can be freed as it is not SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free. Safely read task->mm with a trylock on alloc_lock and acquire an mm reference. Drop the reference via bpf_iter_mmput_async() in _destroy() and error paths. bpf_iter_mmput_async() is a local wrapper around mmput_async() with a fallback to mmput() on !CONFIG_MMU. Reject irqs-disabled contexts (including NMI) up front. Operations used by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async) take spinlocks with IRQs disabled (pool->lock, pi_lock). Running from NMI or from a tracepoint that fires with those locks held could deadlock. A trylock on alloc_lock is used instead of the blocking task_lock() (get_task_mm) to avoid a deadlock when a softirq BPF program iterates a task that already holds its alloc_lock on the same CPU.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/239cec25a22662dbd80f57d94b38178c8be95269
- https://git.kernel.org/stable/c/43683bb280330f3d36f0f2a3932a4867b9603e9c
- https://git.kernel.org/stable/c/d0862de7c866c5bd7c32531f66738c21197af888
- https://git.kernel.org/stable/c/d8e27d2d22b6e2df3a0125b8c08e9aace38c954c
- https://access.redhat.com/security/cve/CVE-2026-53085
- https://bugzilla.redhat.com/show_bug.cgi?id=2492404
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53085.json
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix racing timeout handler The bcmgenet_timeout handler tries to take down all tx queues when a single queue times out. This is over zealous and causes many race conditions with queues that are still chugging along. Instead lets only restart the timed out queue.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/5393b2b5bee2ac51a0043dc7f4ac3475f053d08d
- https://git.kernel.org/stable/c/681fdfe823b4f1036ed50b58b8838c7917ea389c
- https://git.kernel.org/stable/c/7ce1c26aac3b318886a57425f64b522da7389153
- https://git.kernel.org/stable/c/c270e2bec3e55a716d25c35341091339457ac883
- https://git.kernel.org/stable/c/e8206538cbaf4f4068e99a4cb1138690a1e00499
- https://git.kernel.org/stable/c/e85b0c0a12e967930044608311471b665baa315c
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix off-by-one in bcmgenet_put_txcb The write_ptr points to the next open tx_cb. We want to return the tx_cb that gets rewinded, so we must rewind the pointer first then return the tx_cb that it points to. That way the txcb can be correctly cleaned up.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/14e9f86564fff7bcf7f45c1b69080e837b31d185
- https://git.kernel.org/stable/c/29394f722f620281f2ee9a47f947734e53d72c90
- https://git.kernel.org/stable/c/2a74590170427a3ca7cc4bb8690cdd559129c29c
- https://git.kernel.org/stable/c/4cab761fc51c65aef741fcece4a18f3554edbc09
- https://git.kernel.org/stable/c/57f3f53d2c9c5a9e133596e2f7bc1c50688a6d38
- https://git.kernel.org/stable/c/72df896e31ddd06fcc5a789f025ad7a62a18bc9b
- https://git.kernel.org/stable/c/85f34ec320d3881badfd4edc5fee5cd5012bb54d
- https://git.kernel.org/stable/c/fb9a3c1f547d0ff024dbfe7b6f327626ddf0a3de
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix error pointer dereference The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() [add missing wifi: prefix]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2e0e5a43ed126f896a4ad31ade66c90270601bae
- https://git.kernel.org/stable/c/334c68750eee84c2327db1d152be83ff5ad8e20b
- https://git.kernel.org/stable/c/99ef547659178eef6d6ba4738a9d989ce90cf909
- https://git.kernel.org/stable/c/a3b45090a91e2f0b9715870d8f8d9ca2fdfbc1af
- https://git.kernel.org/stable/c/bd6c906e0c4af6d5d0c49c3c4ee090b4913da17d
- https://git.kernel.org/stable/c/cbea71b4480394708f9a6e007a0385acfe5e1ec8
- https://git.kernel.org/stable/c/d3f280be48f1c672cb10e8026c236d0cca60048a
- https://git.kernel.org/stable/c/dd8592fc6007a451c3e4b9025de365e39de8178a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stale offload->prog pointer after constant blinding When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog. This leaves offload->prog pointing to the freed original program. When the network namespace is subsequently destroyed, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(offload->prog). Accessing the freed prog causes a page fault: BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660 ... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP program on a veth inside a netns (./test_progs -t xdp_metadata) 3. cleanup_net -> page fault in __bpf_prog_offload_destroy Dev-bound-only programs are unique in that they have an offload structure but go through the normal JIT path instead of bpf_prog_offload_compile(). This means they are subject to constant blinding's prog clone-and-replace, while also having offload->prog that must stay in sync. Fix this by updating offload->prog in bpf_jit_prog_release_other(), alongside the existing aux->prog update. Both are back-pointers to the prog that must be kept in sync when the prog is replaced.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/059525cf18e69a9313baf947d8898c6ee7ca6b65
- https://git.kernel.org/stable/c/25484c39d1ec82a0368798d956da3de5039b3fe8
- https://git.kernel.org/stable/c/a1aa9ef47c299c5bbc30594d3c2f0589edf908e6
- https://git.kernel.org/stable/c/a713b72ff88cdab4d5d692908ab1259ada511f4d
- https://git.kernel.org/stable/c/c79f8503d83d4665be461fb9e45e215d0380c67b
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/4a3d0fe30b907ff324b1b49756f7e713d67f3645
- https://git.kernel.org/stable/c/571a05ea1baaccc0dc1e0d227b2cbc978b96d392
- https://git.kernel.org/stable/c/7027e705062482a8cea43a1c13ede3c35653966f
- https://git.kernel.org/stable/c/8ed82f807bb09d2c8455aaa665f2c6cb17bc6a19
- https://git.kernel.org/stable/c/b089aa6e94d7a08e74d076a0fe274842dc9feccc
- https://git.kernel.org/stable/c/cb2c1f3cf65b855548e1b8d55a08bfbaa5a0901a
- https://git.kernel.org/stable/c/d4c4bd231ebad70e6f30db429e9640bf378b2f52
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work() When the mt7915 pci chip is detaching, the mt7915_crash_data is released in mt7915_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7915_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7915_pci_remove() | mt7915_sys_recovery_set() mt7915_unregister_device() | mt7915_reset() mt7915_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7915_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7915_unregister_device() to synchronize with any pending or executing dump work.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1146d0946b5358fad24812bd39d68f31cd40cc34
- https://git.kernel.org/stable/c/21ce6d867867645fff0ef657be18f61d9f39dcd8
- https://git.kernel.org/stable/c/6b7cbb13c838cf2a5f2e7be0e96fe15250087939
- https://git.kernel.org/stable/c/6d5202409467d621b6d1dfd7fc7dadb997fe66d2
- https://git.kernel.org/stable/c/e6856af8a22a8e2cd18241a465ed00c2301b3a5e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to avoid a potential kernel panic in scenarios where `vif` might not be initialized.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Zero-extend bpf prog return values and kfunc arguments s390x ABI requires callers to zero-extend unsigned arguments and sign-extend signed arguments, and callees to zero-extend unsigned return values and sign-extend signed return values. s390 BPF JIT currently implements only sign extension. Fix this omission and implement zero extension too.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/202e42e4aa890172366354b233c42c73107a3f59
- https://git.kernel.org/stable/c/366b0e05ee24f5ba62bdc7ec1346038258b9a797
- https://git.kernel.org/stable/c/44c4f999b03f55debb1a0c5ab5c1796895a1adf8
- https://git.kernel.org/stable/c/834918a77be51419383bf1dda9f02b81ecf26b34
- https://git.kernel.org/stable/c/edc90a12073b9a530064a99945c183dde120cb99
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap
The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev to
calculate the needed headroom:
err = skb_cow_head(skb,
len + LL_RESERVED_SPACE(skb_dst(skb)->dev));
But skb->_skb_refdst may not be initialized when the skb is set up by
bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function
in this scenario will trigger null pointer dereference, causing a kernel
crash as Yinhao reported:
[ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 105.186382] #PF: supervisor read access in kernel mode
[ 105.186388] #PF: error_code(0x0000) - not-present page
[ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0
[ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1
[ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520
[ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0
[ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246
[ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00
[ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500
[ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000
[ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98
[ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002
[ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000
[ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0
[ 105.186499] PKRU: 55555554
[ 105.186502] Call Trace:
[ 105.186507]
[ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40
[ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49
[ 105.186536] ? kvm_clock_get_cycles+0x18/0x30
[ 105.186547] ? ktime_get+0x3c/0xa0
[ 105.186554] bpf_test_run+0x195/0x320
[ 105.186563] ? bpf_test_run+0x10f/0x320
[ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0
[ 105.186590] __sys_bpf+0x69c/0xa40
[ 105.186603] __x64_sys_bpf+0x1e/0x30
[ 105.186611] do_syscall_64+0x59/0x110
[ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0
[ 105.186649] RIP: 0033:0x7f166a97455d
Temporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/5500913516e071dbe23e5a404c861dd2d82c9589
- https://git.kernel.org/stable/c/599905c3f10bb83e6e6881d5a7f5cea5df07dc23
- https://git.kernel.org/stable/c/5c8d1f91fc4898d79f29d79c1a6f7c2b3ee66fb0
- https://git.kernel.org/stable/c/94f95328b9070909b5b875c647b17a11d3d85567
- https://git.kernel.org/stable/c/972787479ee73006fddb5e59ab5c8e733810ff42
- https://git.kernel.org/stable/c/c7ad31fb948fdd4905263f4324160682c3fa7bc6
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/008c456b76e9070979bc0e763897a5d3b0fdd4dc
- https://git.kernel.org/stable/c/039cd522dc70151da13329a5e3ae19b1736f468a
- https://git.kernel.org/stable/c/3c0e8a3179e6325a7dc6ce221aef0e03d854ab4b
- https://git.kernel.org/stable/c/7731b67bd59d1284d150cbe40a47e95a10613234
- https://git.kernel.org/stable/c/aa10a452e34810987fb9f4a047995b30003fb53f
- https://git.kernel.org/stable/c/ae10d4a1ab6bcaa1336abb171908a9a365761d3e
- https://git.kernel.org/stable/c/e40873820c9d245ce482faa7ad514ebdb3b8d23d
- https://git.kernel.org/stable/c/fac1079e0fdec6df6d7562c21941587236dc3def
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: s390/cio: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/106d594711e97762788046c5bbb94f580abc4bf4
- https://git.kernel.org/stable/c/2081957d8c323ffb58a10bc64837717ac5a042a1
- https://git.kernel.org/stable/c/ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4
- https://git.kernel.org/stable/c/b660ba045b2b22cf3b4be72773de00cb48f47be5
- https://git.kernel.org/stable/c/c4295487124f461405e1ef64dfa8c4ab0cb7ebcf
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: platform/wmi: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: PCI: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock between reflink and transaction commit when using flushoncommit
When using the flushoncommit mount option, we can have a deadlock between
a transaction commit and a reflink operation that copied an inline extent
to an offset beyond the current i_size of the destination node.
The deadlock happens like this:
1) Task A clones an inline extent from inode X to an offset of inode Y
that is beyond Y's current i_size. This means we copied the inline
extent's data to a folio of inode Y that is beyond its EOF, using a
call to copy_inline_to_page();
2) Task B starts a transaction commit and calls
btrfs_start_delalloc_flush() to flush delalloc;
3) The delalloc flushing sees the new dirty folio of inode Y and when it
attempts to flush it, it ends up at extent_writepage() and sees that
the offset of the folio is beyond the i_size of inode Y, so it attempts
to invalidate the folio by calling folio_invalidate(), which ends up at
btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it
tries to lock the folio's range in inode Y's extent io tree, but it
blocks since it's currently locked by task A - during a reflink we lock
the inodes and the source and destination ranges after flushing all
delalloc and waiting for ordered extent completion - after that we
don't expect to have dirty folios in the ranges, the exception is if
we have to copy an inline extent's data (because the destination offset
is not zero);
4) Task A then attempts to start a transaction to update the inode item,
and then it's blocked since the current transaction is in the
TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the
current transaction to become unblocked (its state >=
TRANS_STATE_UNBLOCKED).
So task A is waiting for the transaction commit done by task B, and
the later waiting on the extent lock of inode Y that is currently
held by task A.
Syzbot recently reported this with the following stack traces:
INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000
Workqueue: writeback wb_workfn (flush-btrfs-46)
Call Trace:
context_switch kernel/sched/core.c:5298 [inline]
__schedule+0x1553/0x5240 kernel/sched/core.c:6911
__schedule_loop kernel/sched/core.c:6993 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7008
wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]
btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914
btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]
btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704
extent_writepage fs/btrfs/extent_io.c:1852 [inline]
extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]
btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713
do_writepages+0x32e/0x550 mm/page-writeback.c:2554
__writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750
writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042
wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227
wb_do_writeback fs/fs-writeback.c:2374 [inline]
wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
INFO: task syz.4.64:6910 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.4.64 state:D stack:22752 pid:6910 tgid:
---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: md: wake raid456 reshape waiters before suspend During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current() Add the missing put_disk() on the error path in blkcg_maybe_throttle_current(). When blkcg lookup, blkg lookup, or blkg_tryget() fails, the function jumps to the out label which only calls rcu_read_unlock() but does not release the disk reference acquired by blkcg_schedule_throttle() via get_device(). Since current->throttle_disk is already set to NULL before the lookup, blkcg_exit() cannot release this reference either, causing the disk to never be freed. Restore the reference release that was present as blk_put_queue() in the original code but was inadvertently dropped during the conversion from request_queue to gendisk.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/000e8454692cab9d1f1b80130e2870e355301d06
- https://git.kernel.org/stable/c/23308af722fefed00af5f238024c11710938fba3
- https://git.kernel.org/stable/c/4048ed98860d3785645ebbd34f69566a6c7320c3
- https://git.kernel.org/stable/c/73a5af059905d171b398c8b2381632ee499948b5
- https://git.kernel.org/stable/c/b3e005f16cd98f815429a87aef4c61e9c140779f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drbd: Balance RCU calls in drbd_adm_dump_devices() Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1f112240531f0a0b437b2e001c1d89e8b25a8328
- https://git.kernel.org/stable/c/282e06e6d494a7bee85af78c747527b7d4009cc3
- https://git.kernel.org/stable/c/2b31e86387e60b3689339f0f0fbb4d3623d9d494
- https://git.kernel.org/stable/c/68ebb9183ac3621b96b18e046841eadb9508783c
- https://git.kernel.org/stable/c/6cd27bcb71bb73f955d104cc3a62be6f83724392
- https://git.kernel.org/stable/c/8092713a10c19fa0f731b71b2853af4319ca54fd
- https://git.kernel.org/stable/c/996d279f2c985d771d6cfdd923e447d825726e06
- https://git.kernel.org/stable/c/ae12bb44b392637a8321ade305c883f9ffc0daea
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fs/mbcache: cancel shrink work before destroying the cache mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first. If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free. This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem. Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START omfs_fill_super() rejects oversized s_sys_blocksize values (> PAGE_SIZE), but it does not reject values smaller than OMFS_DIR_START (0x1b8 = 440). Later, omfs_make_empty() uses sbi->s_sys_blocksize - OMFS_DIR_START as the length argument to memset(). Since s_sys_blocksize is u32, a crafted filesystem image with s_sys_blocksize < OMFS_DIR_START causes an unsigned underflow there, wrapping to a value near 2^32. That drives a ~4 GiB memset() from bh->b_data + OMFS_DIR_START and overwrites kernel memory far beyond the backing block buffer. Add the corresponding lower-bound check alongside the existing upper-bound check in omfs_fill_super(), so that malformed images are rejected during superblock validation before any filesystem data is processed.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0621c385fda1376e967f37ccd534c26c3e511d14
- https://git.kernel.org/stable/c/131ea3e57fc22936ed0e2c8330f2e36106172f51
- https://git.kernel.org/stable/c/5822a05a841a10794ad818620dd2af490b0705d3
- https://git.kernel.org/stable/c/6561afc38398e3518a29c5eebb975c30468f98a6
- https://git.kernel.org/stable/c/754ff1bea3819a90c6f33cccfc1a299ef7609f07
- https://git.kernel.org/stable/c/79f84af38c9fef9deb0e02c79eb969b5541c2644
- https://git.kernel.org/stable/c/817f16ed62bc58a168417bfb5e859c2a370bab03
- https://git.kernel.org/stable/c/fbc72f5c645155dc2ed3573243ed20f9913e3a54
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/gma500/oaktrail_lvds: fix hang on init failure The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released. Fix this by only destroying adapters allocated during LVDS init on errors.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4e04b564c005c9900643c56656d751ad677889be
- https://git.kernel.org/stable/c/5fe9f505d8578852c30668567bc3ce52e776e8c7
- https://git.kernel.org/stable/c/657a091ab6d01d0091b77660c75cfed573c9a53e
- https://git.kernel.org/stable/c/7877f7e231a8bd5c817af1491276550a5e195cd7
- https://git.kernel.org/stable/c/ab9256936b58eb178caddcf5b5b1638f079909d2
- https://git.kernel.org/stable/c/f6fc44af3bbd5ab0fb6bdec6f47decca11b38425
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: audit: fix incorrect inheritable capability in CAPSET records __audit_log_capset() records the effective capability set into the inheritable field due to a copy-paste error. Every CAPSET audit record therefore reports cap_pi (process inheritable) with the value of cap_effective instead of cap_inheritable. This silently corrupts audit data used for compliance and forensic analysis: an attacker who modifies inheritable capabilities to prepare for a privilege-escalating exec would have the change masked in the audit trail. The bug has been present since the original introduction of CAPSET audit records in 2008.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0a065c51a225854768b772a0b733a44d77162582
- https://git.kernel.org/stable/c/151ee470edc3d7ed29fe72df678f8357d2ad8ced
- https://git.kernel.org/stable/c/75bd76c9eb2de9afeca03dc5152ebca5fb8fc816
- https://git.kernel.org/stable/c/95de7bb4bf535a9288549d401ebde83cdcbf2792
- https://git.kernel.org/stable/c/d782e4d200cd9036ef353eeb29525bfbfd13a14e
- https://git.kernel.org/stable/c/e35f3550c5b4fab33103c18654c293cee9850b0a
- https://git.kernel.org/stable/c/e4a640475e43f406fdfd56d370b1f34b0cbbc18d
- https://git.kernel.org/stable/c/febb4bf373ac565d3fb8d1f429827bdd983be496
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: arm64: Reserve an extra page for early kernel mapping The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_reset_all_vfs() ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi(). When the VSI rebuild fails (e.g. during NVM firmware update via nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path, leaving txq_map and rxq_map as NULL. The subsequent unconditional call to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0]. The single-VF reset path in ice_reset_vf() already handles this correctly by checking the return value of ice_vf_reconfig_vsi() and skipping ice_vf_post_vsi_rebuild() on failure. Apply the same pattern to ice_reset_all_vfs(): check the return value of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and ice_eswitch_attach_vf() on failure. The VF is left safely disabled (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can be recovered via a VFLR triggered by a PCI reset of the VF (sysfs reset or driver rebind). Note that this patch does not prevent the VF VSI rebuild from failing during NVM update — the underlying cause is firmware being in a transitional state while the EMP reset is processed, which can cause Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This patch only prevents the subsequent NULL pointer dereference that crashes the kernel when the rebuild does fail. crash> bt PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5" #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540 #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997 #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595 #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2 [exception RIP: ice_ena_vf_q_mappings+0x79] RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206 RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000 RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040 R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000 R13: 0000000000000010 R14: R15: ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice] #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice] #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice] #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4 #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663 #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9 The panic occurs attempting to dereference the NULL pointer in RDX at ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi). The faulting VSI is an allocated slab object but not fully initialized after a failed ice_vsi_rebuild(): crash> struct ice_vsi 0xff34c9efc27d4828 netdev = 0x0, rx_rings = 0x0, tx_rings = 0x0, q_vectors = 0x0, txq_map = 0x0, rxq_map = 0x0, alloc_txq = 0x10, num_txq = 0x10, alloc_rxq = 0x10, num_rxq = 0x10, The nvmupdate64e process was performing NVM firmware update: crash> bt 0xff34c9edd1a30000 PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e" #0 [ff72159bcd617618] __schedule at ffffffffab5333f8 #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice] #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice] #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice] #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice] #8 ---truncated---
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1e9185b13ce57b86844447e092e58abb3be849b1
- https://git.kernel.org/stable/c/3ad2471e61e9f0c4d25046d08e3d747501c3b0dd
- https://git.kernel.org/stable/c/429024f3a407e4137aee825c2a6be0aba857937d
- https://git.kernel.org/stable/c/4c2ac52eeeb672624b06c7a135301d7b8a21d52e
- https://git.kernel.org/stable/c/54ef02487914c24170c7e1c061e45212dc55365e
- https://git.kernel.org/stable/c/acc76b97902757b63ba5136f787d107647236a19
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/conexant: Fix missing error check for jack detection In cx_probe(), the return value of snd_hda_jack_detect_enable_callback() is ignored. This function returns a pointer, and if it fails (e.g., due to memory allocation failure), it returns an error pointer which must be checked using IS_ERR(). If the registration fails, the driver continues to probe, but the jack detection callback will not be registered. This can lead to a kernel crash later when the driver attempts to handle jack events or accesses the uninitialized structure. Check the return value using IS_ERR() and propagate the error via PTR_ERR() to the probe caller.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1da5c73f3793b224696617a2a21def7500ba18d6
- https://git.kernel.org/stable/c/49c2c5924552e1d2f8b635dee663abebbb7cf63b
- https://git.kernel.org/stable/c/a2a33e87a2ffce3046c574d24eec4390c27c9365
- https://git.kernel.org/stable/c/b0e2333a231107adedd38c6fcfe1adc6162716fc
- https://git.kernel.org/stable/c/d68f753d89f4ef6e410d7e8b7e8ab2fdde921b80
- https://git.kernel.org/stable/c/dd110cc00cf854a8ecd8d003127a4178c28574ea
- https://git.kernel.org/stable/c/f837c7b85143a7c54140ff41ad5c076b73cd9933
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix AMDGPU_INFO_READ_MMR_REG There were multiple issues in that code. First of all the order between the reset semaphore and the mm_lock was wrong (e.g. copy_to_user) was called while holding the lock. Then we allocated memory while holding the reset semaphore which is also a pretty big bug and can deadlock. Then we used down_read_trylock() instead of waiting for the reset to finish. (cherry picked from commit 361b6e6b303d4b691f6c5974d3eaab67ca6dd90e)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0ef196a208385b7d7da79f411c161b04e97283e2
- https://git.kernel.org/stable/c/5c29d20470d4566d1b68df57097d642d01f8b427
- https://git.kernel.org/stable/c/61957c2e467b39b528a290016367d32a433fa846
- https://git.kernel.org/stable/c/8c4254c8f5836e77ae83e7fc037f02b69f7a0977
- https://git.kernel.org/stable/c/a31c3feb54b15a90232e497ad0e27e8a82052d8d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mailbox: mailbox-test: don't free the reused channel The RX channel can be aliased to the TX channel if it has a different MMIO. This special case needs to be handled when freeing the channels otherwise a double-free occurs.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/240c71a2aea36a1a4210f911a1c32ea88777e8e4
- https://git.kernel.org/stable/c/3afca89fae501dbd7421e1777b5b8f033b1d98d0
- https://git.kernel.org/stable/c/5c209299b0113e289e238fa5f2e8f00c59f76060
- https://git.kernel.org/stable/c/5d4f3d0f64f1016cb78b400a70b67df91fac99b5
- https://git.kernel.org/stable/c/82f6dcea46cf5de65c4ba7283f7c7b34de4a324d
- https://git.kernel.org/stable/c/88ebadbf0deefdaccdab868b44ff70a0a257f473
- https://git.kernel.org/stable/c/c494a11da45ad7ec9b0ff216c3e3ace351193bb6
- https://git.kernel.org/stable/c/fc0089f82c3e36060c2c79156bc2018bfb16b56b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mailbox: add sanity check for channel array Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/0f11444271110d9b5bc6316a153c6431abda899c
- https://git.kernel.org/stable/c/14aed0d4e58389cc6a88acf8610b12d3e476272b
- https://git.kernel.org/stable/c/37792091ab28ba030fd8d61184c47d4d51294170
- https://git.kernel.org/stable/c/5cc3300fab262b26c28bc2fc06df693410c3840b
- https://git.kernel.org/stable/c/6362c4a7d7e21e68cd9aa04df7cde16befba3a4b
- https://git.kernel.org/stable/c/9dd7489943324298bb0f385495795a82f1dd6507
- https://git.kernel.org/stable/c/c1aad75595fb67edc7fda8af249d3b886efa1be9
- https://git.kernel.org/stable/c/d44872a569b8fbacde457ff2587a775e5004bb79
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mailbox: mailbox-test: free channels on probe error On probe error, free the previously obtained channels. This not only prevents a leak, but also UAF scenarios because the client structure will be removed nonetheless because it was allocated with devm.
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/02beb178e2e159daeb8f992d7abb16a37da31664
- https://git.kernel.org/stable/c/0ad8c4a03a358de7811ba1ab8cbd1fe76ad0ff6b
- https://git.kernel.org/stable/c/15c4cc3850cfe1b973eb7b63c02314b267f06a64
- https://git.kernel.org/stable/c/187069ccc3474516af32350e20d7e449160fa6de
- https://git.kernel.org/stable/c/6c6ce2ccb4fcf1617fec83f91b21aa0265f30701
- https://git.kernel.org/stable/c/742001919653e7313b4e91780c5d108be1692365
- https://git.kernel.org/stable/c/81c9e7e4030e71391ab479c4c6e17b64802577aa
- https://git.kernel.org/stable/c/c02053a9055d5fdfd32432287cca8958db1d5bc5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue() If queue entry or DMA descriptor list allocation fails in airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a NULL pointer dereference running netif_napi_del() for RX queue NAPIs since netif_napi_add() has never been executed to this particular RX NAPI. The issue is due to the early ndesc initialization in airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc value to check if the queue is properly initialized. Fix the issue moving ndesc initialization at end of airoha_qdma_init_tx routine. Move page_pool allocation after descriptor list allocation in order to avoid memory leaks if desc allocation fails.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/4b3a1bf4c2ffd4c9595d900ead78c9035894a025
- https://git.kernel.org/stable/c/5909bedbed38c558bee7cb6758ceedf9bc3a9194
- https://git.kernel.org/stable/c/cea15f66b7b68b2c50943a6660e0692c6635e4eb
- https://git.kernel.org/stable/c/d0e877810baf613b018fd9747440b9d4d9db1428
- https://git.kernel.org/stable/c/d3ff0c121bbaef026df6248ab7ef6f0b068b0647
- https://git.kernel.org/stable/c/ea3ab43a1f3cf2c7cecd75c8be1ee99a5e94a92e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Resolve soft lockup issue when opening /dev/sgX The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/1afd963fcd963db0dc5d47df6dfcf010c9c4647e
- https://git.kernel.org/stable/c/3d74e0654ac908c65a8f20373091826fe43b1363
- https://git.kernel.org/stable/c/9676ca7b1ef31a3a65b3e61e7ce3b54ce7364202
- https://git.kernel.org/stable/c/c47ccfb3d80dfed522ca06a5954ac97488d78c5a
- https://git.kernel.org/stable/c/c5f4a211e82d04ccc1809311322c47023bbe66e2
- https://git.kernel.org/stable/c/d06a310b45e153872033dd0cf19d5a2279121099
- https://git.kernel.org/stable/c/fe671d3c84ffb1b763d590c25195755adeaadaba
- https://git.kernel.org/stable/c/feade299e932967de27519338d41de348fb5b061
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tty: hvc_iucv: fix off-by-one in number of supported devices MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8. This is the number of entries in: static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES]; Sometimes hvc_iucv_table[] is limited by: (a) if (num > hvc_iucv_devices) // for error detection or (b) for (i = 0; i < hvc_iucv_devices; i++) // in 2 places (so these 2 don't agree; second one appears to be correct to me.) hvc_iucv_devices can be 0..8. This is a counter. (c) if (hvc_iucv_devices > MAX_HVC_IUCV_LINES) If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8]. Oops.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/11207e42a332eb8bbcb9fe74df9edd2a807c5607
- https://git.kernel.org/stable/c/3104a3f40feb107f77d7116ad9bf6c210ab7babf
- https://git.kernel.org/stable/c/3d3b89e6ab93bdd0efd45828bda6b0e61cc46dff
- https://git.kernel.org/stable/c/484357dff256c816d9466bda35eb765685e4dc86
- https://git.kernel.org/stable/c/a76511bc654819425d3b15e77b523d7f9d81f064
- https://git.kernel.org/stable/c/f1dc8e72de9aabe5d96767a4e97219ac26b79fe5
- https://git.kernel.org/stable/c/f2a880e802ad12d1e38039d1334fb1475d0f5241
- https://git.kernel.org/stable/c/fed8b8f33a46db0ee2efdb000f4f630c86ed8ca4
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'. Fix the loop condition to use '<' for consistency and correctness.
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/01b61e8dda9b0fdb0d4cda43de25f4e390554d7b
- https://git.kernel.org/stable/c/1fb7f356547d9688822315cd2b205ff0bd5429b4
- https://git.kernel.org/stable/c/2a0673836f019e7c032acbf48d022d5ccf02a845
- https://git.kernel.org/stable/c/426cd8eedac89b86148d4478990eeef16e8a2520
- https://git.kernel.org/stable/c/760ab35040aca8399021fdb9ff1db1089feb7194
- https://git.kernel.org/stable/c/819d8ebad3200a53de99bd7e297bc428e41ced54
- https://git.kernel.org/stable/c/c60a2710b73838d250cda57344c049b89abc5d52
- https://git.kernel.org/stable/c/d5403ae28085761d58b555645bc7d5feadb10073
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: padata: Put CPU offline callback in ONLINE section to allow failure syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/3e6c08dd97dcd22a00aee469e0adfa819071d80e
- https://git.kernel.org/stable/c/5a9f29a3e076b637d2234093e57989cf755ded5b
- https://git.kernel.org/stable/c/65dae8b34f0810f3fa9f77c4c63650cd20820693
- https://git.kernel.org/stable/c/9afe53f14a2aae8c4beb30e5ea51641a34f1a3d3
- https://git.kernel.org/stable/c/a6d44f477000c6352de6b05e9e276e62083e5fbf
- https://git.kernel.org/stable/c/c8c4a2972f83c8b68ff03b43cecdb898939ff851
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Place upper limit on station AID Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash. This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() Move the NULL check for 'sta' before dereferencing it to prevent a possible crash.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4525658002be3ad310b16bf8db48c8adb6a55d32
- https://git.kernel.org/stable/c/65e07964b4b2daf9a54e686cf0fa72d74a9648a8
- https://git.kernel.org/stable/c/94094e70fe292c9566502772d4d4d6d6a99204b1
- https://git.kernel.org/stable/c/9472d37799a0b9ff9b99639f35961ac2f0b3c9be
- https://git.kernel.org/stable/c/b88f905d4449b70da6bda547be546e365e44352e
- https://git.kernel.org/stable/c/be3e5d10643d3be1cbac9d9939f220a99253f980
- https://git.kernel.org/stable/c/e0a0c4903cbba351f0f5b5d104960d3a5b23202f
- https://git.kernel.org/stable/c/e5ff0ba4b6983cdbcc826efc201e7179ece5d46f
HIGH8.4
In the Linux kernel, the following vulnerability has been resolved: udf: reject descriptors with oversized CRC length udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block.
CVSS 3.xHIGH 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/1873eb81c65d3f849418d7386baa39c439c9fc38
- https://git.kernel.org/stable/c/31605bbe94557bff721eaf041001169d44ac6f98
- https://git.kernel.org/stable/c/3dede76d525919bb966f9213e131af685de5ff99
- https://git.kernel.org/stable/c/50dfaf4a027742b4fcdc3e9305e7199ece9bc6a6
- https://git.kernel.org/stable/c/55d41b0a20128e86b9e960dd2e3f0a2d69a18df7
- https://git.kernel.org/stable/c/7d1b6adbf90df6c8941090d5646fbeca25ba9770
- https://git.kernel.org/stable/c/832ab4a882dc9b3c0155490d9993642ef545fd22
- https://git.kernel.org/stable/c/fdb26e628d2a211a23815d375bd33bdf863344e2
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: zero-initialize GART table on allocation GART TLB is flushed after unmapping but not after mapping. Since amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a single PTE is written the TLB may speculatively load other uninitialized entries from the same cacheline. Those garbage entries can appear valid, and a subsequent write to another PTE in the same cacheline may cause the GPU to use a stale garbage PTE from the TLB. Fix this by calling memset_io() to zero-initialize the GART table with gart_pte_flags immediately after allocation. Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work since SDMA needs GART to be initialized to work. (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/40df11255d71b02e20e70579f1b12b687e396e26
- https://git.kernel.org/stable/c/791941be5da125d9a1b228582bfdc300c05d05b3
- https://git.kernel.org/stable/c/8ae8b9e74bab94aab1d79f1688129bcc61c8b29a
- https://git.kernel.org/stable/c/91fbb5e635c8fb1b49e15c19da06480089ef719f
- https://git.kernel.org/stable/c/b17175d0a375b3ed5e81597dac4983fdb46e478d
- https://git.kernel.org/stable/c/e6c2e6c2e1fa066968a16aca1cb66cd1bdde7741
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: Prevent partial address patches In the case that only one of lo/hi is valid, the patching could result in a bad address written to in FW.
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/0ee17150763962671f43a62ddf8f6ea1feaff438
- https://git.kernel.org/stable/c/2d66d1f5d8c0434e9a5ad21cc6eaf3a5e32141d5
- https://git.kernel.org/stable/c/944db9cfa5373f67eb94621d4c2eee572c05fa3f
- https://git.kernel.org/stable/c/b3d1a0a45c4aec484fa2a5b060b611e3d3064470
- https://git.kernel.org/stable/c/de2a02cc28d6d5d37db07d00a9a684c754a5fd74
- https://git.kernel.org/stable/c/ea2c554e700b86a04534b4c24ece5844e8c5f07e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Add upper bound check for num_of_nodes drm/amdkfd: Add upper bound check for num_of_nodes in kfd_ioctl_get_process_apertures_new. (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/44d5a450c04d3d734c13a03561c3131020d66edf
- https://git.kernel.org/stable/c/4a8093c7def141cc6e854fbe3f9693867982418f
- https://git.kernel.org/stable/c/6ba6ec5fcbb0d03ca11ed1cc38d57a7deb6c6b20
- https://git.kernel.org/stable/c/74b73fa56a395d46745e4f245225963e9f8be7f1
- https://git.kernel.org/stable/c/7b80137eb8aa9d1cbfe7ccf3eeb1faa94ae35d7e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov8856: free control handler on error in ov8856_init_controls() The control handler wasn't freed if adding controls failed, add an error exit label and convert the existing error return to use it.
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/791598484fd558bb426ef5e051effa5c227d5390
- https://git.kernel.org/stable/c/ba9e9274c4ecfc039c45752dd6055137eaa5f08e
- https://git.kernel.org/stable/c/c13721040a566d832ee8a20ecf04b7ef288a1525
- https://git.kernel.org/stable/c/d1b3811c6b0f67fb7f0acfe09bf8244aa8b12465
- https://git.kernel.org/stable/c/f727e3251ceee91f3d6e6d87e323aaf070f0de8e
- https://git.kernel.org/stable/c/f75e160745663ce9b13362ae6e90bd439c58df69
- https://git.kernel.org/stable/c/fd10fb4c33bdc9c25c9b9d5e7e39f635e34c44a3