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-9859-10Package update kernel-image-rpi-un in branch sisyphus
Severity:
Closed issues (259)
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
HIGH8.8
Уязвимость функции cifs_get_spnego_key() инструмента cifs.upcall пакета cifs-utils ядра операционных систем 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:CReferences
HIGH7.1
Уязвимость функции tcf_pedit_act() модуля act_pedit ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:HCVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/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
CRITICAL9.1
Уязвимость функции nft_inner_parse_l2l3() модуля net/netfilter/nft_inner.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NCVSS 2.0CRITICAL 9.4
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:NReferences
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/security/cve/CVE-2026-43284
- https://bugzilla.redhat.com/show_bug.cgi?id=2467771
- 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: 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
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: 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: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.
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/05cfe9863ef049d98141dc2969eefde72fb07625
- https://git.kernel.org/stable/c/0bf92a90bf05ecafe52e92d5bc15a585021a64ac
- https://git.kernel.org/stable/c/54add3b7d3c154ca89ef5bac2582b0ed1a3a15d5
- https://git.kernel.org/stable/c/768f665f3685b455ed686370ed7ccb852a125a3b
- https://git.kernel.org/stable/c/9aa7edc1347b98774e5167ca34e5b8aa6083bde7
- https://git.kernel.org/stable/c/a3ca27762ce8476b4fbf9b2a8f5cb74c38e483e4
- https://git.kernel.org/stable/c/cdce1e797addab72393c0dfee31aaca41ef7d937
- https://git.kernel.org/stable/c/d643c1ec80b70508f54dac12179e36920e2c00de
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.
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/54ed418de62a148a655262da682a050fa05f7924
- https://git.kernel.org/stable/c/6fb6a97c86abb8592158088afaea0eb464cf9de1
- https://git.kernel.org/stable/c/963537a26fd892f7e414a091f807b44aeee97a7d
- https://git.kernel.org/stable/c/976612471a9e6ead6ceffc241e4d0a1aac90b36a
- https://git.kernel.org/stable/c/a6a9bc544b675d8b5180f2718ec985ad267b5cbf
- https://git.kernel.org/stable/c/b37da3ac099e145bcd3be82c745a8d335772e3af
- https://git.kernel.org/stable/c/c4f840437e7641764de15f2de951ac8335d641f1
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
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
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: 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.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: 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/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: 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/a2e2d08fb070fab4947447171f1c4e3ca5a188e5
- https://git.kernel.org/stable/c/b4a53add2fa8f1b5aa17d4c5686c320785fab182
- https://access.redhat.com/errata/RHSA-2026:36018
- 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/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/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/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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: ADD_ADDR rtx: always decrease sk refcount When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(). It should then be released in all cases at the end. Some (unlikely) checks were returning directly instead of calling sock_put() to decrease the refcount. Jump to a new 'exit' label to call __sock_put() (which will become sock_put() in the next commit) to fix this potential leak. While at it, drop the '!msk' check which cannot happen because it is never reset, and explicitly mark the remaining one as "unlikely".
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/25e37407442b8766ec2cf52fb4e31b5c3d3aeeae
- https://git.kernel.org/stable/c/9426265e157dd77ec237c795901ed4dea6d69b5c
- https://git.kernel.org/stable/c/9634cb35af17019baec21ca648516ce376fa10e6
- https://git.kernel.org/stable/c/acd3d3562315c99f3c0db16f0fcc5f0306638982
- https://git.kernel.org/stable/c/b41dd76f3b9735096c21d3e799a2b9fe36498d57
MEDIUM4.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: mptcp: pm: ADD_ADDR rtx: free sk if last When an ADD_ADDR is retransmitted, the sk is held in sk_reset_timer(), and released at the end. If at that moment, it was the last reference being held, the sk would not be freed. sock_put() should then be called instead of __sock_put(). But that's not enough: if it is the last reference, sock_put() will call sk_free(), which will end up calling sk_stop_timer_sync() on the same timer, and waiting indefinitely to finish. So it is needed to mark that the timer is done at the end of the timer handler when it has not been rescheduled, not to call sk_stop_timer_sync() on "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/531c537b8fb620beabccfb1594e8d43cbebbb87a
- https://git.kernel.org/stable/c/6a3af482188f6db4186d1605f64d911d7330abb3
- https://git.kernel.org/stable/c/8143a224785ceaf2b0856e08d4498916f38228fb
- https://git.kernel.org/stable/c/b74ad20198652b6b39a761c277ba65ae82b1e107
- https://git.kernel.org/stable/c/b7b9a461569734d33d3259d58d2507adfac107ed
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
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/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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()
When media GT is disabled via configfs, there is no allocation for
media_gt, which is kept as NULL. In such scenario,
intel_hdcp_gsc_check_status() results in a kernel pagefault error due to
>->uc.gsc being evaluated as an invalid memory address.
Fix that by introducing a NULL check on media_gt and bailing out early
if so.
While at it, also drop the NULL check for gsc, since it can't be NULL if
media_gt is not NULL.
v2:
- Get address for gsc only after checking that gt is not NULL.
(Shuicheng)
- Drop the NULL check for gsc. (Shuicheng)
v3:
- Add "Fixes" and "Cc: " tags. (Matt)
(cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)
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: 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/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:HHIGH7.1
In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid, creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to request the key.
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/0aece6685fc80a8de492688ca2315fb86ec379c7
- https://git.kernel.org/stable/c/2035acfb17221729b1b8ac335e941868a04ca079
- https://git.kernel.org/stable/c/3da1fdf4efbc490041eb4f836bf596201203f8f2
- https://git.kernel.org/stable/c/7713bd320ed4fc3d08a227cd8e41242219a16981
- https://git.kernel.org/stable/c/91f89c1d83e80417629791fcef6af8140d7d01c8
- https://git.kernel.org/stable/c/9544559e59438a4b609b2fdfa0763d8360572824
- https://git.kernel.org/stable/c/a3bbda6502a9398b816fa2e71c9a3f955f58013d
- https://git.kernel.org/stable/c/cf20038657d6d4974349556a34e08fe0490bebbc
- http://www.openwall.com/lists/oss-security/2026/06/01/6
- https://access.redhat.com/errata/RHSA-2026:23258
- https://access.redhat.com/errata/RHSA-2026:23259
- https://access.redhat.com/errata/RHSA-2026:23329
- https://access.redhat.com/errata/RHSA-2026:23395
- https://access.redhat.com/errata/RHSA-2026:24381
- https://access.redhat.com/errata/RHSA-2026:25908
- 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:26570
- https://access.redhat.com/errata/RHSA-2026:27708
- https://access.redhat.com/errata/RHSA-2026:27719
- https://access.redhat.com/errata/RHSA-2026:27729
- https://access.redhat.com/errata/RHSA-2026:27735
- https://access.redhat.com/errata/RHSA-2026:28887
- https://access.redhat.com/errata/RHSA-2026:28962
- https://access.redhat.com/errata/RHSA-2026:33219
- https://access.redhat.com/errata/RHSA-2026:33220
- https://access.redhat.com/errata/RHSA-2026:33221
- https://access.redhat.com/errata/RHSA-2026:33222
- https://access.redhat.com/errata/RHSA-2026:33223
- https://access.redhat.com/errata/RHSA-2026:33224
- https://access.redhat.com/errata/RHSA-2026:33225
- https://access.redhat.com/errata/RHSA-2026:33486
- https://access.redhat.com/errata/RHSA-2026:34764
- https://access.redhat.com/errata/RHSA-2026:34788
- https://access.redhat.com/errata/RHSA-2026:34815
- https://access.redhat.com/security/cve/CVE-2026-46243
- https://bugzilla.redhat.com/show_bug.cgi?id=2481486
- https://github.com/manizada/CIFSwitch
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46243.json
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_inner: Fix IPv6 inner_thoff desync In nft_inner_parse_l2l3(), when processing inner IPv6 packets, ipv6_find_hdr() correctly computes the transport header offset traversing all extension headers, but the result is immediately overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only accounts for the IPv6 base header. This creates a desync between inner_thoff (wrong — points to extension header start) and l4proto (correct — e.g., IPPROTO_TCP), enabling transport header forgery and potential firewall bypass. This issue affects stable versions from Linux 6.2. For comparison, the normal (non-inner) IPv6 path correctly preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite ensures that ipv6_find_hdr()'s calculated transport header offset is preserved, thereby fixing the desynchronization.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NReferences
- https://git.kernel.org/stable/c/689bbf48c1f45130086ae1c46ab83ea4c753c601
- https://git.kernel.org/stable/c/870d59e2cf218e7418491e26bad768cb16654582
- https://git.kernel.org/stable/c/b6a91f68ebfed9c38e0e9150f58a9b85da07181c
- https://git.kernel.org/stable/c/c161ad9157f5a0429b5ff94d9770faf3bf48d273
- https://git.kernel.org/stable/c/d0f98a3617f6ae5b1e95cde1e68e7ead4a1279ce
- https://access.redhat.com/errata/RHSA-2026:33215
- https://access.redhat.com/errata/RHSA-2026:34094
- https://access.redhat.com/errata/RHSA-2026:34443
- https://access.redhat.com/errata/RHSA-2026:34911
- https://access.redhat.com/errata/RHSA-2026:36018
- https://access.redhat.com/security/cve/CVE-2026-46244
- https://bugzilla.redhat.com/show_bug.cgi?id=2484451
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46244.json
HIGH8.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: 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/security/cve/CVE-2026-46300
- https://bugzilla.redhat.com/show_bug.cgi?id=2477015
- 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: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.
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/2bec122b9fb91507a758ab5e3e5c4fbe7cb3f61b
- https://git.kernel.org/stable/c/3dee9d0c198faeb95d052c1b94c2958751a28512
- https://git.kernel.org/stable/c/544d857b42a1734b923040e13aa61a6fd4746cf2
- https://git.kernel.org/stable/c/899ee91156e57784090c5565e4f31bd7dbffbc5a
- https://git.kernel.org/stable/c/a071e057518decc5e3bec89855758f5f8786f2c5
- https://git.kernel.org/stable/c/b198ed4e52580a7238c7c7082f03906f8b310313
- https://git.kernel.org/stable/c/b685d6ef6f07a3b5ce814565a25f39f2157538a5
- https://git.kernel.org/stable/c/d5d01d35a5a7d36f7cb679b67d9cbdd5205672dc
- https://access.redhat.com/errata/RHSA-2026:27288
- https://access.redhat.com/errata/RHSA-2026:27353
- https://access.redhat.com/errata/RHSA-2026:27354
- https://access.redhat.com/errata/RHSA-2026:27355
- https://access.redhat.com/errata/RHSA-2026:27704
- https://access.redhat.com/errata/RHSA-2026:27705
- https://access.redhat.com/errata/RHSA-2026:27706
- https://access.redhat.com/errata/RHSA-2026:27707
- https://access.redhat.com/errata/RHSA-2026:27708
- https://access.redhat.com/errata/RHSA-2026:27709
- https://access.redhat.com/errata/RHSA-2026:27713
- https://access.redhat.com/errata/RHSA-2026:27731
- https://access.redhat.com/errata/RHSA-2026:27789
- https://access.redhat.com/errata/RHSA-2026:28887
- https://access.redhat.com/errata/RHSA-2026:28962
- https://access.redhat.com/errata/RHSA-2026:29080
- https://access.redhat.com/errata/RHSA-2026:29794
- https://access.redhat.com/errata/RHSA-2026:29799
- https://access.redhat.com/errata/RHSA-2026:29833
- https://access.redhat.com/errata/RHSA-2026:29856
- https://access.redhat.com/errata/RHSA-2026:29863
- https://access.redhat.com/errata/RHSA-2026:33219
- https://access.redhat.com/errata/RHSA-2026:33220
- https://access.redhat.com/errata/RHSA-2026:33221
- https://access.redhat.com/errata/RHSA-2026:33222
- https://access.redhat.com/errata/RHSA-2026:33223
- https://access.redhat.com/errata/RHSA-2026:33224
- https://access.redhat.com/errata/RHSA-2026:33225
- https://access.redhat.com/errata/RHSA-2026:33666
- https://access.redhat.com/security/cve/CVE-2026-46331
- https://bugzilla.redhat.com/show_bug.cgi?id=2479492
- https://github.com/sgkdev/packet_edit_meme/tree/main
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46331.json
HIGH7.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://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: 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
CRITICAL9.4
In the Linux kernel, the following vulnerability has been resolved: netfilter: require Ethernet MAC header before using eth_hdr() `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)` after either assuming that the skb is associated with an Ethernet device or checking only that the `ETH_HLEN` bytes at `skb_mac_header(skb)` lie between `skb->head` and `skb->data`. Make these paths first verify that the skb is associated with an Ethernet device, that the MAC header was set, and that it spans at least a full Ethernet header before accessing `eth_hdr(skb)`.
CVSS 3.xCRITICAL 9.4
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:HReferences
- https://git.kernel.org/stable/c/063f43361e884acd7300790e90194430275d0d0c
- https://git.kernel.org/stable/c/367abcacc13a8e2e7624408b7f593bd1e60e49d9
- https://git.kernel.org/stable/c/4435888e1bf139d2bfe5911643d4217382136743
- https://git.kernel.org/stable/c/5d634afb8b83b49de562792fd0d047416a43bd4d
- https://git.kernel.org/stable/c/62443dc21114c0bbc476fa62973db89743f2f137
- https://git.kernel.org/stable/c/726abf97566867f808fec9d8a408eb9698bd570a
- https://git.kernel.org/stable/c/cea435ea7e868ea6fdf039bc4f2090c1d829b556
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential unbounded skb queue virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc. virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM. If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0. Fix this by estimating the skb metadata size: (Number of skbs in the queue) * SKB_TRUESIZE(0)
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.
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/15fe76e23615f502d051ef0768f86babaf08746c
- https://git.kernel.org/stable/c/2ff4b7817e5b78070c30f5fb5e678e452a2628b3
- https://git.kernel.org/stable/c/8fe0231adebe086c8a459c790944ac026cd99c6e
- https://git.kernel.org/stable/c/ac1aad8e1281534ce936c250f68084fc79c5469e
- https://git.kernel.org/stable/c/afd35fec9297195b759078745549c2671223f24f
- https://git.kernel.org/stable/c/baf8685bcf56dc1efb44b8f6a57c42516e549068
- https://git.kernel.org/stable/c/cc644d5608e3b0dadc970bd6e6aa26b91ea07d0f
- https://git.kernel.org/stable/c/dee2a49adeeb2a5e16a3fc858fa21b841c519802
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via "*dest = 0". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare "*dest = 0" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
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/3544210609f6d1db282bbdeca639104ef624c393
- https://git.kernel.org/stable/c/6744e49fe51bfba26522acc2d0e9703cb41d8e50
- https://git.kernel.org/stable/c/84d8f58cf28a0415413f43ba7148f7bacd4c1b6e
- https://git.kernel.org/stable/c/8c84885e9790823828bb8084736ea15769b1ac16
- https://git.kernel.org/stable/c/ab185e0c4fb82dfba6fb86f8271e06f931d9c64c
- https://git.kernel.org/stable/c/d19ddef8c327a4773ff81f8e51027d1e0b4cf069
- https://git.kernel.org/stable/c/eb8a8124484dbc3c2b543e207da39bbccb703d31
- https://git.kernel.org/stable/c/eca18feed38b3377a2ec5d1f22af1170c55d0171
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)
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/7ae95c0275c330b5dbae806f8e431720edad776f
- https://git.kernel.org/stable/c/7fc4fab4acc307ad2903312c195872b2953d32c3
- https://git.kernel.org/stable/c/a2de1d71891a038a9346b2c1a72b88c8350f2479
- https://git.kernel.org/stable/c/adf67034b1f61f7119295208085bfd43f85f56af
- https://git.kernel.org/stable/c/b781f90a9528555c709e59789550893581ef0be4
- https://git.kernel.org/stable/c/bb6f705b73b5f191f14ad004e2c8c4b615806187
- https://git.kernel.org/stable/c/c90954cdea4d6998ec345de0d840d030c145b89e
- https://git.kernel.org/stable/c/ee9cfcf77a8e8af637396dc00966df5f701e661c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)
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/029571d51140650783be4fb98fe7cb4754752086
- https://git.kernel.org/stable/c/3f32d52ec604c659725d865cf8cc6a17a33f9c6a
- https://git.kernel.org/stable/c/4d1c3c26c2ab1842e139e61983395d64bd2e518b
- https://git.kernel.org/stable/c/5f8b39452fb16f507c9e4d8b4a83ce27e893307c
- https://git.kernel.org/stable/c/8aaa7e317fbd4beb9c6a9f77aa4cf52fae78b117
- https://git.kernel.org/stable/c/d6be8e59af412623e3d874be3a048406c0edfe60
- https://git.kernel.org/stable/c/fb0707ce00eef4e2d60c3020e1c0432739703e4a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)
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/1906064d50d194a145486e5caf3db3e708b6f6ef
- https://git.kernel.org/stable/c/3c4444aec06c74fbc05661f370954ac814963c38
- https://git.kernel.org/stable/c/79e0273272a05fb26f9b1e55bf1a52eefc3b7b35
- https://git.kernel.org/stable/c/91fb41218c413989d8b6c837748751454b452d68
- https://git.kernel.org/stable/c/964e50ef7b8f09815a7d05b8326af700f8d5bc96
- https://git.kernel.org/stable/c/98cfb7530ea91d8e5e928285cdce58e1131f6e83
- https://git.kernel.org/stable/c/bfba882cfcd08f6540f72f48e786b6404f5d2c5b
- https://git.kernel.org/stable/c/f0f3981c43b32cadfe373d636d9e9ca522bb3702
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)
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/04e271a952b8863bbafc99bd51aca4c32bff0e0d
- https://git.kernel.org/stable/c/0e56f460bddb397fa9a8e6faf7ae7eaa86953eb1
- https://git.kernel.org/stable/c/2645e3caf7e013189da9c6ff621d006cca5a538b
- https://git.kernel.org/stable/c/499c6b43a79dd684bddbd18fe8b2235aa2764db4
- https://git.kernel.org/stable/c/6173cfea2f916e01c4f98e29cd654384a05e32a3
- https://git.kernel.org/stable/c/6723188c42ca3b34a9fce634d7a0ecc9ccd5cd56
- https://git.kernel.org/stable/c/e94f5323c41f32a74160378c3b19850d1f203ad5
- https://git.kernel.org/stable/c/ff287df16a1a58aca78b08d1f3ee09fc44da0351
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.
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: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)
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/2bd550b547deabef98bd3b017ff743b7c34d3a6d
- https://git.kernel.org/stable/c/62bd09e23a23da70f9aae02748eba3e6bd93095d
- https://git.kernel.org/stable/c/72e259a32084c42816152c346096d2edd4213e23
- https://git.kernel.org/stable/c/daeceb0fe2a19651c58bbfa3d9d515ecb6ca8996
- https://git.kernel.org/stable/c/e1965e8913cfbf17622ca12638e7a07f68ba0848
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:NReferences
- https://git.kernel.org/stable/c/033dfa63bf6be2653441a1dccae4a8313a91bb9d
- https://git.kernel.org/stable/c/4db2bd2ed4785dbadaeeab9f4e346b21ac5fb8eb
- https://git.kernel.org/stable/c/7720654b4842bcdfeb64bc002f6186041849e1e7
- https://git.kernel.org/stable/c/a15b6d3136accb2bf84b04d9a3ddd991f7fbf1cb
- https://git.kernel.org/stable/c/b2c1e5d9f1598cc1a4736d5c6bd1218f90805ee4
- https://git.kernel.org/stable/c/b5daa920f44cb582272fc9bfaeb67408776cbaef
- https://git.kernel.org/stable/c/c55da494dfb445fb28df3a9d293c2be6a299cd01
- https://git.kernel.org/stable/c/fc261397295b8ad0654cec747b0ec25ea0011995
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.
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/07cd2787cdf8942d24a1a3ef81aa89b526fb6381
- https://git.kernel.org/stable/c/0dd61ba03d05187726ecdf9c0e2175a81b9b24f6
- https://git.kernel.org/stable/c/46da5c3ea011e884028a91cf913db093920a915b
- https://git.kernel.org/stable/c/79235c8add5da4bf27a12f5a5dbb579f300c059e
- https://git.kernel.org/stable/c/a504b9f2797b739e0304d537e8aa4ce883ecce39
- https://git.kernel.org/stable/c/a770e62923090d7572f1f5a8507ae551d354a057
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.
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/0a32040a48db8cf35de48b85d6115df5623e4964
- https://git.kernel.org/stable/c/1912be23daf4afc8d24ce916021ab68ca4c679db
- https://git.kernel.org/stable/c/4d0b1524caadb04c10a71f3f88692c63dcb39115
- https://git.kernel.org/stable/c/5c7657d38d07268124782f03519f07c22a5814fb
- https://git.kernel.org/stable/c/60ba6217460792356a238299edd675d91d46bab4
- https://git.kernel.org/stable/c/65423079c7420e3dbf9a7aa345c243a3f5752e5d
- https://git.kernel.org/stable/c/b212bc161d8a9937b42153723a4a3f2f74fab528
- https://git.kernel.org/stable/c/cbeb68cbaa0a6f979ef428a7f2d0268c082ba166
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.
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/2e0ddac549ebd713eb9f4a15b6496e3440a17d8b
- https://git.kernel.org/stable/c/35d6c9252a152e756768a26dbf216b9dd9dd8e92
- https://git.kernel.org/stable/c/3b6e68cb97f725385010264a873e14a3921b6b8a
- https://git.kernel.org/stable/c/581c2053ab4dbe27e83c9e62deb4c73aa8dc0c3a
- https://git.kernel.org/stable/c/5f56bc6bddffe8710ba0ba8844023b5a44ca90e4
- https://git.kernel.org/stable/c/99d9dbad1463afb510d42c9714f846361d1b726d
- https://git.kernel.org/stable/c/ca11e7da4fba4b394f69e16448f4463c44c84de6
- https://git.kernel.org/stable/c/cff8eb65d1eafe7793e54b4d0cf6bf831644630b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mmc: dw_mmc-rockchip: Add missing private data for very old controllers The really old controllers (rk2928, rk3066, rk3188) do not support UHS speeds at all, and thus never handled phase data. For that reason it never had a parse_dt callback and no driver private data at all. Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") makes the private data sort of mandatory, because the init function checks whether phases are configured internally or through the clock controller. This results in the old SoCs then experiencing NULL-pointer dereferences when they try to access that private-data struct. While we could have if (priv) conditionals in all places, it's way less cluttery to just give the old types their private-data struct.
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: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path leaks the same way in the child VMA's reserve map, though it requires the much rarer combination of pinned hugetlb anon page + hwpoisoned source. Add the missing restore_reserve_on_error() call before folio_put() on both error paths.
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/40c81856e622a9dc59294a90d169ac07ea25b0b0
- https://git.kernel.org/stable/c/45e33d43243d71d089af42f5077b8213cee6610f
- https://git.kernel.org/stable/c/8d6e1dd3ad1340cd8b6d554b7aa93d8f0a1c6d38
- https://git.kernel.org/stable/c/c72469ac0f274bde3f0df60a4584e14a123d0aa6
- https://git.kernel.org/stable/c/e47bf16af3c45470ea32f2241fa69aefe0dd61bd
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.
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: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.
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/0d8c64511fd45690c5326f013710efcb4f73a97e
- https://git.kernel.org/stable/c/150bf6f1193c69252580c19d3b3cd631ddce61d7
- https://git.kernel.org/stable/c/4bfdf0a9855df55e9e031ca6a25b855820590c70
- https://git.kernel.org/stable/c/5401fb4fe10fac6134c308495df18ed74aebb9c4
- https://git.kernel.org/stable/c/8fb4a23df5b7c02929b62e5dbc270ec7c42b8134
- https://git.kernel.org/stable/c/a3d91218ccca1e990bfb737b5a6da23f0afba22b
- https://git.kernel.org/stable/c/d5de9cb5355db36438edc621dde3673e3f235767
- https://git.kernel.org/stable/c/d77583ca33299fede0c194744ef2284e7ba5b763
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.
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/2d0f47e27c1fa718b29c69aa7c96a2c5161bc2c2
- https://git.kernel.org/stable/c/464c6ad2aa16e1e1df9d559289199356493d1e00
- https://git.kernel.org/stable/c/53e06f8a3c2b085c31bf1284e2ebcb8036e99625
- https://git.kernel.org/stable/c/708c17b52c60fe7a57e73b495bdee50f58feb48c
- https://git.kernel.org/stable/c/7ba7b30ddb04646d4d638f4d8c4718a304bbbddd
- https://git.kernel.org/stable/c/d3e26df2e8eb361e6bef096b2fd565476a1f14c4
- https://git.kernel.org/stable/c/d43afc412d439ffca1567e7ca8652be22f272b3b
- https://git.kernel.org/stable/c/e69e306a4cccb40a73511350cb280825a556ce3c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.
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/07ebe87915d8accdaba20c4f88c5ae430fe62fbb
- https://git.kernel.org/stable/c/0a3b87293fbd34fda651e6aead9964f84b893962
- https://git.kernel.org/stable/c/5b0166112019d1dce30b976ab28fd67f7f0be532
- https://git.kernel.org/stable/c/8b080c89183196fd3e49212f2a1a1c4a29335b9c
- https://git.kernel.org/stable/c/992f121796b7ca83a5a8b93da24e971363206218
- https://git.kernel.org/stable/c/f20f6512ecb75c816e0debf4551a138f098615c4
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.
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/5278ccd357e0d7aeeb1e76c0f3e0e02894a9897c
- https://git.kernel.org/stable/c/c6e5c2be09f814377d7f1ce97370a5b7b3e02814
- https://git.kernel.org/stable/c/d42679eef34dd590b694ce3b666c5e2ba10cd4bf
- https://git.kernel.org/stable/c/df08fadcf0e5f3708365ec3b6d30b5aafd98bea1
- https://git.kernel.org/stable/c/e1e3a05efe5954d5bad01157d79429d39a67a7ae
- https://git.kernel.org/stable/c/e85eb5feca8e254905ffa6c57a3c99c89a674a0f
- https://git.kernel.org/stable/c/ecea4967c2bff92c2fafbc59893f711b39f7b152
- https://git.kernel.org/stable/c/fbe0947420eec18a84638d29468c2d563ce4e6a3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.
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/12df4cfa738aefff21756728e91056d7defb0fe6
- https://git.kernel.org/stable/c/15487f98863dc7156ed43c5be26d478beb82ba35
- https://git.kernel.org/stable/c/99c317d7f8b7bbf3de16d20a01f363e390114cea
- https://git.kernel.org/stable/c/9c954499d43aefac01c5dfb57a82b13d2dcf4b94
- https://git.kernel.org/stable/c/9dbf1b2fadfc6c40805631d8a8276d1639fc9ab6
- https://git.kernel.org/stable/c/bd23fa0c16c5c86e5b7713224ffbb87d9db81cca
- https://git.kernel.org/stable/c/dd92773d4d9cea010474eb08a5133c14ff6ab53a
- https://git.kernel.org/stable/c/e692f0cb86204dcdb9dddc0b355407eda6394a67
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.
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/1ca40b243277c9e88be5e00bd3e083f71aefb93e
- https://git.kernel.org/stable/c/29e7b925ae6df64894e82ab6419994dc25580a8a
- https://git.kernel.org/stable/c/75ee6e4aa096aa9e7b2dd5c8ff98356e30aceefb
- https://git.kernel.org/stable/c/bd22740d7f14cb1c0289444cfd2c8d2938667c1d
- https://git.kernel.org/stable/c/c1234229399f4af12c553b1b0ffd978eeba65548
- https://git.kernel.org/stable/c/c5584e089b5af7b3bf8bd5e8ca0560cbf32b0a47
- https://git.kernel.org/stable/c/df422fd273c96c2ee5beb80fc21adc8c70c29260
- https://git.kernel.org/stable/c/e8a013c0c3ca2f6708341a56612a3f6d6921620a
- https://access.redhat.com/security/cve/CVE-2026-53176
- https://bugzilla.redhat.com/show_bug.cgi?id=2492741
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53176.json
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.
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/08e57d014ea19f303d5d57a849beb846f37788b7
- https://git.kernel.org/stable/c/1449177b87f768353909e930a99b902675119b2b
- https://git.kernel.org/stable/c/1a418ad0e5e525d1d117dd1601681f75455af320
- https://git.kernel.org/stable/c/3884976f87448e269908ae61bd5d62d54ce9c0c7
- https://git.kernel.org/stable/c/580844a9683afe7974856dd5b7886447435b3474
- https://git.kernel.org/stable/c/59c5a3e69c7630a811565937e64be70b08436761
- https://git.kernel.org/stable/c/964b1c3eb71afe58bb61c8b984164447e000ae8a
- https://git.kernel.org/stable/c/d930276f2cddd0b7294cac7a8fe7b877f6d9e08d
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix livelock in tmigr_handle_remote_up() tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), assuming the local softirq path already handled this CPU's timers. This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() evaluates the expiry times. As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel. What's worse is that fetch_next_timer_interrupt_remote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely. Fix this by calling timer_expire_remote() unconditionally. That's minimal overhead for the common case as __run_timer_base() returns immediately if there is nothing to expire in the local wheel. [ tglx: Amend change log and add a comment ]
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on 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/22c587aa3ab1ab5264daff3ec32136fd30436c13
- https://git.kernel.org/stable/c/9698582a4dd9c4a05889d7db96d4c0edc9e69cac
- https://git.kernel.org/stable/c/ba9ad6015937a5e46ba1a31370e3efdec8abbdcc
- https://git.kernel.org/stable/c/bcb275626055df7f8f947f1a349754b4004d9a15
- https://git.kernel.org/stable/c/c05fa14db43ebef3bd862ca9d073981c0358b3f0
- https://git.kernel.org/stable/c/cf7090e255d74c4b61c51f8ede9fcacdd8393b5b
- https://git.kernel.org/stable/c/dfd853197615d322d3a88dbcab91fc0fd2096219
- https://git.kernel.org/stable/c/ea0b03d52881c12a8c634ea0d6cbfa61cefdb488
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().
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/265c07c09c837621730d35f02975207a1224bf05
- https://git.kernel.org/stable/c/30c3fa80f423613efdda3deca4af52ff7d20e4e2
- https://git.kernel.org/stable/c/4cd92957e8f8cc4ebfe8a5d4203c14c592fde6b1
- https://git.kernel.org/stable/c/688fcac7054abc680c0eef753f2bb772cfaf8cf7
- https://git.kernel.org/stable/c/ecbf3c45add30a0857414e156bdb9c79906f0ff6
- https://git.kernel.org/stable/c/fc0ec2fc02dfe52c5821f36fbccf6a45df43f508
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.
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/653245266913f03fcf21cbca68eed5c197a33e52
- https://git.kernel.org/stable/c/aa3861f40ac32706d9e97bfac76984613e278788
- https://git.kernel.org/stable/c/b1fd13074f22105deec45aa02283e322733e0c2d
- https://git.kernel.org/stable/c/bf364b0f10b27679140699821f88af7f01e2a6e3
- https://git.kernel.org/stable/c/c297a4e65c50a2b807d9309b22615080faffa8f3
- https://git.kernel.org/stable/c/da23be77e1292cd611e736c3aa17da633d7ddce7
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved:
udp: clear skb->dev before running a sockmap verdict
On the UDP receive path skb->dev is repurposed as dev_scratch (the
truesize/state cache set by udp_set_dev_scratch()), through the
union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff.
When a UDP socket is in a sockmap, sk_data_ready is
sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor()
(sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq.
If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp,
bpf_skc_lookup_tcp), bpf_skc_lookup() does:
if (skb->dev)
caller_net = dev_net(skb->dev);
skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net()
dereferences it as a struct net_device * and the kernel takes a general
protection fault on a non-canonical address in softirq:
Oops: general protection fault, probably for non-canonical address 0x1010000800004a0
CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full)
RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline]
RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047
Call Trace:
bpf_prog_4675cb904b7071f8+0x12e/0x14e
bpf_prog_run_pin_on_cpu+0xc6/0x1f0
sk_psock_verdict_recv+0x1ba/0x350
udp_read_skb+0x31a/0x370
sk_psock_verdict_data_ready+0x2e3/0x600
__udp_enqueue_schedule_skb+0x4c8/0x650
udpv6_queue_rcv_one_skb+0x3ec/0x740
udp6_unicast_rcv_skb+0x11d/0x140
ip6_protocol_deliver_rcu+0x61e/0x950
ip6_input_finish+0xa9/0x150
NF_HOOK+0x286/0x2f0
ip6_input+0x117/0x220
NF_HOOK+0x286/0x2f0
__netif_receive_skb+0x85/0x200
process_backlog+0x374/0x9a0
__napi_poll+0x4f/0x1c0
net_rx_action+0x3b0/0x770
handle_softirqs+0x15a/0x460
do_softirq+0x57/0x80
The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on
dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear
skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which
skb_set_owner_sk_safe() set just above.
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/1b585673a2249f13678e7ac443ac683ba767e0b6
- https://git.kernel.org/stable/c/263779a6beff03b8b06f6d25566cb0f45af361f2
- https://git.kernel.org/stable/c/3c94f241f776562c489876ff506f366224565c21
- https://git.kernel.org/stable/c/6822eed69572000a181fa4e31fceacc60918c471
- https://git.kernel.org/stable/c/7d6d92d000ebe3a845a17c165c1d3a70c5d84fe1
- https://git.kernel.org/stable/c/90d35188aaa92b8f8b23f66335e0e91bf60103a3
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed.
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/0c2821665ff71be3f4b07ecece384669f2877f6a
- https://git.kernel.org/stable/c/198b5a14cca27263b9c14b20114c8092de15dfcb
- https://git.kernel.org/stable/c/732fd9f0b9c1cdc6dfd77162ded60df005182cc0
- https://git.kernel.org/stable/c/77a602b505ce4802915853cfc435a4722fab3e64
- https://git.kernel.org/stable/c/c96786d6ff1acc1d54d9241e97767554c1dfdd5b
- https://access.redhat.com/security/cve/CVE-2026-53185
- https://bugzilla.redhat.com/show_bug.cgi?id=2492735
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53185.json
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.
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/0b9ee09d5e849591f17d98c078033dadea967293
- https://git.kernel.org/stable/c/0d64bc200ebe4f275b27438c6e593903e0b16fe1
- https://git.kernel.org/stable/c/13e91fd076306f5d0cdfa14f53d69e37274723c4
- https://git.kernel.org/stable/c/2015038195939eac54a1ee83c9d98ef1a8ccbbce
- https://git.kernel.org/stable/c/3523e53ff95f1837ec3f57ff7558532bcb2661b7
- https://git.kernel.org/stable/c/3889517c2ec7f364914aea8209abfff735f7ecde
- https://git.kernel.org/stable/c/ed77cc819ad631264787cade5ae5ec4c535ec6bb
- https://git.kernel.org/stable/c/f92a285db7ff6e598591ccbfb551be155c5f4d57
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_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/108963978a681c0c468d279cac2b930c27672877
- https://git.kernel.org/stable/c/459771c9cf30f378bdbd30fc65d17f7eb931bb59
- https://git.kernel.org/stable/c/5f5b604e1e6bde4e889199168ee80fe8306d06ad
- https://git.kernel.org/stable/c/6c29a8ba084e89499ca77b947e07ae817f9c16ce
- https://git.kernel.org/stable/c/84b3212b166b446faea27ebebb7161405ffceef9
- https://git.kernel.org/stable/c/8d878059924f12c1bc24556a92ec56add74de3c8
- https://git.kernel.org/stable/c/ae9d4caf6f133e884cf5fcda4982c493b35e5194
- https://git.kernel.org/stable/c/ed5b030931292c94133437ac5e5ff580e498eabd
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.
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/3f26bb732cc136ab20176697c92f32c9c84cb125
- https://git.kernel.org/stable/c/73524e9f96a278b521f257a78a845c49eb522bc1
- https://git.kernel.org/stable/c/8348567a6afb24e2c9cafe8a321162d0eebe1411
- https://git.kernel.org/stable/c/898bd0ccfed71651b881660c5d20ad73b5203174
- https://git.kernel.org/stable/c/c0fffc874c264292e769f26194a2a5e66ce31810
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: io_uring/net: inherit IORING_CQE_F_BUF_MORE across bundle recv retries When a bundle recv retries inside io_recv_finish(), the merge logic OR the saved cflags from the previous iteration with the cflags returned by the new iteration: cflags = req->cqe.flags | (cflags & CQE_F_MASK); Bits listed in CQE_F_MASK are inherited from the new iteration, and all other bits (notably IORING_CQE_F_BUFFER and the buffer ID) come from the saved cflags. Before this change CQE_F_MASK covered only IORING_CQE_F_SOCK_NONEMPTY and IORING_CQE_F_MORE. When using provided buffer rings (IOU_PBUF_RING_INC) with incremental mode, and bundle recv, io_kbuf_inc_commit() can leave the head ring entry partially consumed, __io_put_kbufs() then sets IORING_CQE_F_BUF_MORE on the returned cflags so userspace knows the buffer ID will be reused for subsequent completions. Because IORING_CQE_F_BUF_MORE was not in CQE_F_MASK, the merge above silently dropped it whenever the final retry iteration partially consumed the buffer, and the subsequent req->cqe.flags = cflags & ~CQE_F_MASK save would have left a stale IORING_CQE_F_BUF_MORE in the carried-over cflags had one been present. Userspace would then wrongfully advance it ring head past an entry the kernel still uses. Add IORING_CQE_F_BUF_MORE to CQE_F_MASK so it is both inherited from the new iteration into the user-visible CQE and stripped from the saved cflags between iterations.
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: ALSA: timer: Fix UAF at snd_timer_user_params() At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter.
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: ALSA: timer: Forcibly close timer instances at closing When snd_timer object is freed via snd_timer_free() and still pending snd_timer_instance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIG_SND_UTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer. This patch is an attempt to paper over the problem above: now instead of just unlinking, call snd_timer_close[_locked]() forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since snd_timer_close() might be called later by the driver that created that instance, the check of SNDRV_TIMER_IFLG_DEAD is added at the beginning, 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:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.
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/0a57320f71941d4e0b1307453c9a1f0939afe666
- https://git.kernel.org/stable/c/14147b7963685957839c76ba8094924e22777d79
- https://git.kernel.org/stable/c/372f33ebed747d91870f57c0a2e62884a870bffa
- https://git.kernel.org/stable/c/60af1fd82983c26604102e63a3fcc822c186cceb
- https://git.kernel.org/stable/c/70d86e355c564b5510fde61361df014f5476c83e
- https://git.kernel.org/stable/c/96d47e40bf9db4a9efd5c8fb53287a508d165f14
- https://git.kernel.org/stable/c/a1288cd700f721c1a119c4f1e8efa234e59caada
- https://git.kernel.org/stable/c/bde742b076cbe26ecc89c8c68c76ae076a524d02
- https://access.redhat.com/security/cve/CVE-2026-53194
- https://bugzilla.redhat.com/show_bug.cgi?id=2492703
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53194.json
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.
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/0fd2b00b2d3d05e3eaa13342b3dfb0fa85c226ae
- https://git.kernel.org/stable/c/130d6567eb148040eed1b73e1414ad6c27d22bd5
- https://git.kernel.org/stable/c/294692d3296eee3391c348d7ea6401916d27806c
- https://git.kernel.org/stable/c/2fd64bf0ad66ab5de0c73524591d879427ba5aba
- https://git.kernel.org/stable/c/3e187152f44d76d7633a3855ffd0099e1588b82a
- https://git.kernel.org/stable/c/4cb722747ed25971f35cc47ce5c0e79d7f717713
- https://git.kernel.org/stable/c/5a79b634ee58786ca627268daefa7744f2af2e14
- https://git.kernel.org/stable/c/b7faf660eefa2047ebc2959ff76da2b6eae2e9e3
MEDIUM6.8
In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]
CVSS 3.xMEDIUM 6.8
CVSS:3.x/CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- https://git.kernel.org/stable/c/183c1076eca43bbb3e7bdf597456f91d81c73e74
- https://git.kernel.org/stable/c/561edb021486e6723d841926aa4b48097da06190
- https://git.kernel.org/stable/c/b849f30d1a9e66aae6b715aaef66e427390cb081
- https://git.kernel.org/stable/c/cfd634f6dfd40c49a84f9bddc2867a80e2e2623a
- https://git.kernel.org/stable/c/d214d2341d4f9f447e36a7d012cdf6a6631a55f1
- https://git.kernel.org/stable/c/d92f17af7097d10bdeddf26f66f34b354104b277
- https://git.kernel.org/stable/c/e168db91442b94e64fa82a7dd297983d48ea5cc0
- https://git.kernel.org/stable/c/f96cf7bf9fbf15d7fcf0c91fec47ba8a010369ea
- https://access.redhat.com/security/cve/CVE-2026-53196
- https://bugzilla.redhat.com/show_bug.cgi?id=2492750
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53196.json
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on conn->async_requests via setup_async_work(), with cancel_fn = smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock. When the request is cancelled, the worker frees the file_lock with locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never reaches release_async_work() -- the only site that unlinks the work from conn->async_requests and clears cancel_fn/cancel_argv. The work therefore stays matchable on async_requests with a live cancel_fn pointing at the freed file_lock, until connection teardown finally runs release_async_work(). smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free: BUG: KASAN: slab-use-after-free in __locks_delete_block __locks_delete_block locks_delete_block ksmbd_vfs_posix_lock_unblock smb2_remove_blocked_lock smb2_cancel <- 2nd SMB2_CANCEL fires cancel_fn handle_ksmbd_work Allocated by ...: locks_alloc_lock <- smb2_lock Freed by ...: locks_free_lock <- smb2_lock (cancelled branch) ... cache file_lock_cache of size 192 Reproduced on mainline with KASAN by an authenticated SMB client. Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback cannot be fired a second time.
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/0da2e073f9cbf4985a0fd9acb71bc5ff599f8afd
- https://git.kernel.org/stable/c/14d2eee0193ac3cd1bf3d014373449f0b8d35d6d
- https://git.kernel.org/stable/c/2b2eda2821cff1d1b5a423b6ee7d8fc6fbc8e694
- https://git.kernel.org/stable/c/89ae9df09d2c1fb4a4eb495c113a7ce1dca34147
- https://git.kernel.org/stable/c/b7063c7426ea5a4d15e01b60538718765392f49d
- https://git.kernel.org/stable/c/f580d27e8928828693df44ba2db0fffdbe11dfea
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.
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/004e9ecfe6c5384f9e0b2f6f6389d42ec22789af
- https://git.kernel.org/stable/c/09b8a7aa5a341bb345dc492aac139525efa13515
- https://git.kernel.org/stable/c/0b38870d81ab3a04c1ab0598d9d3285f5d9d0584
- https://git.kernel.org/stable/c/16514afeb7d3d121072ba9a0b640d6c1c5507db0
- https://git.kernel.org/stable/c/695c59cf7bf707e6ff8cea01916ee50e86616933
- https://git.kernel.org/stable/c/918c0c988239aa5ab96b254e504d191af6191061
- https://git.kernel.org/stable/c/a82d4251918f37d9c5aab7b365157669fb885ec3
- https://git.kernel.org/stable/c/fe7221b4346418d27ec2daccfc09df6692b76f0b
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix signed integer truncation in IPC receive Fix potential buffer overflow where firmware-supplied data_size is cast to signed int before being used in min_t(). Large unsigned values (>= 0x80000000) become negative, causing unsigned wraparound and oversized memcpy operations that can overflow the stack buffer. Change min_t(int, ...) to min() as both values are unsigned and can be handled by min() without explicit cast.
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/2821bf2b79e47f87e1dbdd9d25c78240965a97d6
- https://git.kernel.org/stable/c/45cb105b8642c65e9be286f7058e92314efe7ea3
- https://git.kernel.org/stable/c/4788556d4dd9d717037e385de178974e9649231d
- https://git.kernel.org/stable/c/d9faef564438d1e4579c692c046603e7ada7bdf4
- https://access.redhat.com/security/cve/CVE-2026-53202
- https://bugzilla.redhat.com/show_bug.cgi?id=2492823
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53202.json
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add buffer overflow check in MS get_info_ioctl Add validation that the info size returned from the metric stream info query is not exceeded when checked against the allocated buffer size. If the firmware returns a size larger than the buffer, reject the operation with -EOVERFLOW instead of proceeding with an incorrect buffer copy.
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/4e5047cc94bea1cc7b670b7f503358e9af0542df
- https://git.kernel.org/stable/c/d3c12ed33e8923f3090909a1738f3e59292996a6
- https://git.kernel.org/stable/c/fa598556ecef412edcb391f144b7642e18fdfd45
- https://git.kernel.org/stable/c/fb176425837693f50c5c9fc8db6fbb04af22bd0a
- https://access.redhat.com/security/cve/CVE-2026-53203
- https://bugzilla.redhat.com/show_bug.cgi?id=2492798
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53203.json
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.
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:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap: thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully madvise(folio, MADV_HWPOISON) unmap(folio) try_memory_failure_hugetlb get_huge_page_for_hwpoison spin_lock_irq(&hugetlb_lock) <- held __get_huge_page_for_hwpoison hugetlb_update_hwpoison() -> MF_HUGETLB_FOLIO_PRE_POISONED goto out: folio_put() refcount: 1 -> 0 free_huge_folio() spin_lock_irqsave(&hugetlb_lock) -> AA DEADLOCK! The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop the GUP reference while the hugetlb_lock is still held by the hugetlb.c wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released the page table mapping reference, folio_put() drops the folio refcount to zero, triggering free_huge_folio() which attempts to re-acquire the non-recursive hugetlb_lock. Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the folio_put() at the out: label so the folio is always released outside the lock. [akpm@linux-foundation.org: fix race, rename label per Miaohe]
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/3c2d42b8ee345b17a4ba56b0f6492d1ff4c1178e
- https://git.kernel.org/stable/c/77b73b54801ae7137479c141fd0473a491c1dc48
- https://git.kernel.org/stable/c/a33bfed648c10f5a1519981dbfad80841191edc8
- https://git.kernel.org/stable/c/bf7ba8f96c258c30393814491930ae4ecdc5fe5e
- https://git.kernel.org/stable/c/dd77a83915b07e2b0205adb284f08b39ae31dc4b
- https://git.kernel.org/stable/c/fc3ff42cb0cbf947e4600ae9761c3783760050e2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.
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/214a2042b16b3c8d798a8b9ef9f36094f13a9859
- https://git.kernel.org/stable/c/a8335f3db15bd1e0e82e0db5d488fabc7d10d1ab
- https://git.kernel.org/stable/c/b20e8a98dd29b121f58fcdf51e8576119aba536a
- https://git.kernel.org/stable/c/dd214733544427587a95f66dbf3adff072568990
- https://git.kernel.org/stable/c/dedc92b96dc1d8919a3bdf2495ede68922ef7ebc
- https://git.kernel.org/stable/c/e05c4ac575b457978a7ef441053394169084869c
- https://git.kernel.org/stable/c/e2b8acf9405bd9b1baf1c54dc897b0905db689bf
- https://git.kernel.org/stable/c/fa5823126239b3e453fac1a2fe50726c7f4a55e1
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failure through the device log. This keeps the existing advertising data intact and avoids overrunning the temporary buffer.
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/02f50e8bb69f9b22516163a09922f5537d3b12d1
- https://git.kernel.org/stable/c/10b0e832cc05d7aef4b92bed912cbd4a395d0862
- https://git.kernel.org/stable/c/1338ee049a8910ba6c9cee963920e978e6893c7d
- https://git.kernel.org/stable/c/5c65b96b549ea2dcfde497436bf9e048deb87758
- https://git.kernel.org/stable/c/cdd8bbdbee763fdf5bf343e6f7d4e79347739f62
- https://git.kernel.org/stable/c/dafc9f57140e66a10945127aa7433c3d715dc253
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm 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:HHIGH7.8
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace metadata_dst_free() with dst_release() so the metadata_dst is freed only after all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set.
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/349df61526d2e39decc685d246202e3e284cfe05
- https://git.kernel.org/stable/c/55b79b1ae42372012413ce0413181d26679b17ef
- https://git.kernel.org/stable/c/5e9ee18b27fde88cb6148202b33916c66693fe82
- https://git.kernel.org/stable/c/8767fe4079affa74314d7eb3220e700150289842
- https://git.kernel.org/stable/c/941d7394efda5e054e2d6f3e0dd0f6a9ba19aaa3
- https://git.kernel.org/stable/c/c32b26aaa2f9216520a38b3f4bfeec846eb3eb8a
- https://git.kernel.org/stable/c/f9a0e4b61054cde89a2a77845293c726cc07cc43
- https://git.kernel.org/stable/c/fda6573a46ad24f35348e024905ee5bdf729797e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().
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/02f5e4db57c0cdd7bac89d503b301a093a0fa95c
- https://git.kernel.org/stable/c/30165a09f76eaf34951c818eb5d9d6e4771d76f6
- https://git.kernel.org/stable/c/4fc692dc6df5bc777cc1bcebf95179e28594875f
- https://git.kernel.org/stable/c/5d563a5da8717629ae72f9eadf1e0e340bd1658b
- https://git.kernel.org/stable/c/c034aa0b1ba5f49cbdf8ef193d6ec714d74aac27
- https://git.kernel.org/stable/c/e0ce103e89d61eef70edc1d1ae3bfd4c0aacbc2e
- https://git.kernel.org/stable/c/fd87d6966041e33ef7d2e5dc59f9a52b71c6ae5f
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix a potential NPD in cleanup_prefix_route()
addrconf_get_prefix_route() can return the fib6_null_entry sentinel
entry which has a NULL fib6_table pointer. Therefore, before setting the
route's expiration time, check that we are not working with this entry,
as otherwise a NPD will be triggered [1].
Note that the other callers of addrconf_get_prefix_route() are not
susceptible to this bug:
1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF |
RTF_PREFIX_RT' flags which are not set on fib6_null_entry.
2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid
possible NULL deref in modify_prefix_route()").
3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for
fib6_null_entry and returns an error.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[...]
Call Trace:
__kasan_check_byte (mm/kasan/common.c:573)
lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1))
_raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1))
cleanup_prefix_route (net/ipv6/addrconf.c:1280)
ipv6_del_addr (net/ipv6/addrconf.c:1342)
inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119)
inet6_rtm_deladdr (net/ipv6/addrconf.c:4812)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6997)
netlink_rcv_skb (net/netlink/af_netlink.c:2555)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1899)
__sock_sendmsg (net/socket.c:802 (discriminator 4))
____sys_sendmsg (net/socket.c:2698)
___sys_sendmsg (net/socket.c:2752)
__sys_sendmsg (net/socket.c:2784)
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:121)
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/07d9a0870a178843cea44cfd58c27445dc94cf5f
- https://git.kernel.org/stable/c/192df376a05c2db15564640f9da7e20907c1fa24
- https://git.kernel.org/stable/c/5f82b02b4059ddc06e4fcfd057bfb59fd6885cd2
- https://git.kernel.org/stable/c/653a2849305708f75260b5296f17b2a759ff9cc7
- https://git.kernel.org/stable/c/b70c687b7cf267fb08586667a3946c8851cad672
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. Returning such a buffer to BM lets hardware DMA into memory that is no longer owned by the RX ring. Refill the BM pool before handing the current buffer to XDP or to the skb. If the allocation fails there, drop the packet and return the still-owned current buffer to BM, preserving the pool depth. Once the refill succeeds, later local drops retire/free the current buffer instead of returning it to BM.
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/02e1b5c4d3b4c658b72c145427cded1bba613fc1
- https://git.kernel.org/stable/c/580f92f27cb8724bcc4be98ee89890eab524a2ae
- https://git.kernel.org/stable/c/5e8e2a9624df72fca7c736b2966b2cbf6c9c3ff6
- https://git.kernel.org/stable/c/8a2126c5afe89f8ceeb60a3afb9f075b736194cd
- https://git.kernel.org/stable/c/a03cdcedb2cbcc42551dc3e4746929e93c5352d5
- https://git.kernel.org/stable/c/a88b3293b556f4d8fba11db9a8061a6b0d3b69e6
- https://git.kernel.org/stable/c/d0c8c4fbd22d260fe28530260656c5fb3c20ce84
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.
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/3b8b0c3631b19faee53f0d15a49924129b063eec
- https://git.kernel.org/stable/c/910617a4e67dbdd5fdb39d9dc6a51e491e1b2c3e
- https://git.kernel.org/stable/c/9545cc5ef18ca22d031f2f47c157192460652359
- https://git.kernel.org/stable/c/994bd2b58d2bd08aa97ec0836cc813cfcb00d749
- https://git.kernel.org/stable/c/a3ee9231ccec6ec3be2de89c56f897055fd9eab1
- https://git.kernel.org/stable/c/ec8e1e5842bc0dbd4c272761f4db3651eecd0339
- https://git.kernel.org/stable/c/f3c6aa078927e6fe8121c9c591ddee8716c5305a
HIGH8.6
In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.
CVSS 3.xHIGH 8.6
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:LReferences
- https://git.kernel.org/stable/c/180235600934bef6add3be637c296d6cf3272e67
- https://git.kernel.org/stable/c/19f8bc139e9b149d1e5bf75ae761d1bb8dd3e7d8
- https://git.kernel.org/stable/c/23548007b3c66d628fc7d6b80d1e23be04ea10d9
- https://git.kernel.org/stable/c/60412bdd1b2576659eac23a23d2d9ff96228a643
- https://git.kernel.org/stable/c/a13199fa224e9f776f4005d5037df03aa9ea8f37
- https://git.kernel.org/stable/c/a3ad9b5767c89531fc7dae951b51b0933dcf7051
- https://git.kernel.org/stable/c/bede0f481b9137d73d1cf64309cbe4b94818a5d6
- https://git.kernel.org/stable/c/e302206ad84a407a7e5f3f6fe767ff5efaace689
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is 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/19748967d59c31d24d21d40b728570788310b237
- https://git.kernel.org/stable/c/46fc15a044e9938e7ea77786fb37edd2cd74f031
- https://git.kernel.org/stable/c/67b27434c43b68a97becda98c9f0c8cf6cba2134
- https://git.kernel.org/stable/c/772cecf198da732faebb5dcfc46d66a505be8495
- https://git.kernel.org/stable/c/78069a6d8bc86c9e036eb82c2af4a19cc1871a53
- https://git.kernel.org/stable/c/8738b1b6d0e639ca1fc0f61516afd3557ac4ecc6
- https://git.kernel.org/stable/c/cd513e43b4b2bd1de39e2367bc4261c699a8652f
- https://git.kernel.org/stable/c/f08fb3d42fd3aad0b7a263da3ac3ebaf0845e265
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter 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/08a3e218064db11f154ad9ad5541751ea7f34ebe
- https://git.kernel.org/stable/c/0b35dc8527ccc16b7dc34e8a3164313e68cd4e45
- https://git.kernel.org/stable/c/8d67e42ad3b1a95a152541015a07110e06992d6c
- https://git.kernel.org/stable/c/a0d16941adf3a501956d74aefd8d6e217906e79c
- https://git.kernel.org/stable/c/b28e2fcad3db7e8687b15bc20bced26b5b7c920e
- https://git.kernel.org/stable/c/b74ba3343eb44b2cbf7e9665918c287df1d52ebb
- https://git.kernel.org/stable/c/f7f2fbb0e893a0238dc464f8d8c0f5609bec584f
- https://git.kernel.org/stable/c/fb0521aff1e10e300d89725cc439d3ea74c828c5
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.
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.8
In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.
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/2abfb19bbb81958714ad1d43ebeb65b30394184b
- https://git.kernel.org/stable/c/2fc7bc087cc7085368263d9d37bfe9a0bddd6a2d
- https://git.kernel.org/stable/c/47fb3c2b4203556308e64354b3e78f2ce221d646
- https://git.kernel.org/stable/c/90fd4513315ca07da99cfd8549d3e553a7160f0d
- https://git.kernel.org/stable/c/a5c0359f5cbc51a2e2b114d6041e0f3c73f903e9
- https://git.kernel.org/stable/c/c327fa4fca31415431202e063767a7ae342e19c6
- https://git.kernel.org/stable/c/f513f308cc4bdb4530d033431592ffbc29b7fca1
- https://git.kernel.org/stable/c/fc657ac0767c49839b3ef0b08dc0953ca30883f8
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.
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/1ee90b77b727df903033db873c75caac5c27ec98
- https://git.kernel.org/stable/c/24a0d548d3a765cd4558224e4f8e06e14cba26e3
- https://git.kernel.org/stable/c/3dde4fb941fa5649ab809f6cd3e20e0c424a4e31
- https://git.kernel.org/stable/c/71ff5cdd5da61d0438e902aa0fd68c28bc901abe
- https://git.kernel.org/stable/c/ad9a0374ee6d11048e1f74cd5180bad58b9848b4
- https://git.kernel.org/stable/c/b903e9b5629ec8dd6db92174070045bf81ad7060
- https://git.kernel.org/stable/c/e0665b2a8e90bb08bd205062c75662b502d31797
- https://git.kernel.org/stable/c/eb51a9ad3ceb01bc6c0fb608dbc856e03ee6f24a
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops after the 4-byte parameter header; reached from the no-association lookup path, from_addr_param() then reads uninitialized bytes past the parameter. Impact: an unauthenticated SCTP peer makes the receive path read up to 16 bytes of uninitialized memory past a truncated ASCONF address parameter. The sibling __sctp_rcv_init_lookup() bounds parameters with sctp_walk_params(); this path open-codes the fetch and omits the bound. Verify the whole address parameter lies within the chunk before from_addr_param() reads it, the same class of fix as commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").
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/446e0ecd845abc394b24ae2030a883572bec9d16
- https://git.kernel.org/stable/c/8ce96f1182644079249a24ac7e2ffc32e0301a46
- https://git.kernel.org/stable/c/8e86817b8af4d552f3c6fe04ca52bb0c8c57411d
- https://git.kernel.org/stable/c/928dd94db23e8ba340f83d68f7f24d831b7a4426
- https://git.kernel.org/stable/c/d6bd0bb7697ea8c0387b0d9d973453f479017b23
- https://git.kernel.org/stable/c/d796cfd06074b579d265b28401306cadd30db945
- https://git.kernel.org/stable/c/f76a8b323e28e0951f979dbef20a7496383c47df
- https://git.kernel.org/stable/c/f8373d7090b745728de66308deeecc67e8d319ce
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error 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/0bb5b2dc1b90aa7dd1473fc8c4d813a29255ff8d
- https://git.kernel.org/stable/c/25fdf53698535fe8790237f5a8a9626791429785
- https://git.kernel.org/stable/c/895d1dd9057cde1687fa0f4286d47ceed0b82997
- https://git.kernel.org/stable/c/971b1b37774f13acc5add0a2843f8598446b8598
- https://git.kernel.org/stable/c/e248fb2e680deb2bd37bac551b72638fe4938a76
- https://git.kernel.org/stable/c/e3d509a1b71396e1452060dbf84a805fd1c3c549
- https://git.kernel.org/stable/c/ecc55aad3390129a87106841f4b68bf3d70c9264
- https://git.kernel.org/stable/c/ee30dd2909d8b98619f4341c70ec8dc8e155ab02
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.
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/0bfa7bba1f41aaf5f0604dc712bb4701493e3aa0
- https://git.kernel.org/stable/c/1132e5edc2866c3530be17622153a597095f0e43
- https://git.kernel.org/stable/c/2fa49b2715e1bad12ce3b0fa64e234d9582c8193
- https://git.kernel.org/stable/c/59f80c919713250fe5d25a4d9aea4e49580fa1d4
- https://git.kernel.org/stable/c/9c67b44edb3598d234efae6e44649eb993c03da5
- https://git.kernel.org/stable/c/cb658c2f5f7977c2a1c77c9f239f4bc8196edb5c
- https://git.kernel.org/stable/c/f0e42f0c4337b1f220de1ddd63f47197c7dee4de
- https://git.kernel.org/stable/c/fddd41445a0537b093e6b3f6232c9933cad1e48b
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.
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:HHIGH8.7
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list
mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using
the PF's log_max_current_uc/mc_list capabilities. When querying a VF
vport with a larger configured max (via devlink), the firmware response
can overflow this buffer:
BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]
Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385
CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core]
Call Trace:
dump_stack_lvl+0x69/0xa0
print_report+0x176/0x4e4
kasan_report+0xc8/0x100
mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]
esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core]
esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core]
esw_vport_change_handler+0x6a/0x90 [mlx5_core]
process_one_work+0x87f/0x15e0
worker_thread+0x62b/0x1020
kthread+0x375/0x490
ret_from_fork+0x4dc/0x810
ret_from_fork_asm+0x11/0x20
Fix by querying the vport's own HCA caps to size the buffer correctly.
Refactor the function to allocate and return the MAC list internally,
removing the caller's dependency on knowing the correct max.
CVSS 3.xHIGH 8.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:HReferences
- https://git.kernel.org/stable/c/0f807764bb122fd63aa45f4229cb1ef2679fbd40
- https://git.kernel.org/stable/c/2398e497389ed4be43f7cfbab499b49cec7dae1a
- https://git.kernel.org/stable/c/41781f2789309462520a93822e946521ed78f97f
- https://git.kernel.org/stable/c/537d87784e81c3d7037525b99416455cee088cdc
- https://git.kernel.org/stable/c/894e036a24a26a6dd7b17d8d3fb5c53ab48a6074
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: netdev: fix double-free in netdev_nl_bind_rx_doit() Sashiko flags that genlmsg_reply() always consumes the skb. The error path calls nlmsg_free(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsg_reply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf.
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: ALSA: seq: dummy: fix UMP event stack overread The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The subscriber delivery path then uses snd_seq_event_packet_size() and copies a UMP-sized packet from that stack object, reading past the end of the temporary. Use the existing union __snd_seq_event storage and copy the packet size reported for the incoming event before rewriting the common routing fields. This preserves the full UMP packet for UMP events while keeping legacy event handling unchanged.
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: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.
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/7c71a9522555ff137a9ca36b15d759ca04d84788
- https://git.kernel.org/stable/c/88fe2e3658726cb21ff2dcf9770bf672f9b9d31b
- https://git.kernel.org/stable/c/b053fcd8912f06c30f932f5b8ec41c72de474695
- https://git.kernel.org/stable/c/cac5bf3500ee6422cf64e0df0b5daeecfed42917
- https://git.kernel.org/stable/c/cd98837db15f323463b8df07282ac723bd5c3fed
- https://git.kernel.org/stable/c/d68b621bb5a48051932f1017a6e1bc9b18f854d0
- https://git.kernel.org/stable/c/d842f26a167e77a36f3ed333b9fa99d36ef99fe6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.
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/36d259711872e3b2f6cd76a4d270c21931c0f35f
- https://git.kernel.org/stable/c/42446ca0f3570663e87183c065e0b4def52dfba2
- https://git.kernel.org/stable/c/6d6e42e8e17f18d61327f8653479c5b5e161ae1d
- https://git.kernel.org/stable/c/6eea6494e542a03cdf755a593b7d74f3f7c260fd
- https://git.kernel.org/stable/c/7561c7fbc694308da73300f036719e63e42bf0b4
- https://git.kernel.org/stable/c/ae65714d96f68bb252eb20085320bdaacab36c00
- https://git.kernel.org/stable/c/cc98717e591a963a616fdf15ecf48eefaf45d758
- https://git.kernel.org/stable/c/fd9c3a47c670bec6b18f44454cea023f93b5adb3
CRITICAL9.8
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown mtk_free_dev() calls metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, a use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed.
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/2d86aeb46d5f69c704065a8c69822582787272a1
- https://git.kernel.org/stable/c/459c6f35c58cf0fd5247e55d73ddaa29571d9b7e
- https://git.kernel.org/stable/c/72775977e89c25c99ee84d2c5baa3f86a8ba5cb4
- https://git.kernel.org/stable/c/80df409e1a483676826a6c66e693dba6ac507751
- https://git.kernel.org/stable/c/e634408d2b0cd939cfe019398a21fb47b7a8ffe3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.
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/00e8845fe3428c69e980dce5071cb3da1d8f7578
- https://git.kernel.org/stable/c/28f5ad1b4055405eb1616e603fe511ba5e3725e7
- https://git.kernel.org/stable/c/2a87c3e8f03ce655ed0ef500d64d5fd924ec3691
- https://git.kernel.org/stable/c/4cd6e9ed49347d3a2fdaaf07e32fb524756dddc2
- https://git.kernel.org/stable/c/89343ff12b3178fc236fe531a3603e7c97c68278
- https://git.kernel.org/stable/c/8ff85dbabbbfb05e86e6cde31d91ac5782179d4d
- https://git.kernel.org/stable/c/a4f3fd6516920988c47ba8d19714985c40c816a1
- https://git.kernel.org/stable/c/d3915a1f5a4bc0ac911032903c3c6ab8df9fcc7c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.
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/06ce6fc106b16dec9b535950db626261be865e5b
- https://git.kernel.org/stable/c/2a58899d11009bffc7b4b32a571858f381121837
- https://git.kernel.org/stable/c/4485d79617520d84ba5a14515e2b5136007d6deb
- https://git.kernel.org/stable/c/c32f30ef5e66adbfa102348e2e8a23776eb007cb
- https://git.kernel.org/stable/c/da8808463882c3f3c357b072e25053c2121f1419
- https://git.kernel.org/stable/c/da8cbb64b47e9066b40af0de170901caf17b768c
- https://git.kernel.org/stable/c/dcb1bec1c32ee5c3878354e087cf5dbee2b7c7af
- https://git.kernel.org/stable/c/f24a58c72a45f4c109f3557a760cc4b60b7a6037
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.
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/18af5d2ef0c4f65787fd1280c8b23286b9f2a835
- https://git.kernel.org/stable/c/1f1b98fea6b9ea30507d0f2fbff6750292d097e2
- https://git.kernel.org/stable/c/5057e1aca011e51ef51498c940ef96f3d3e8a305
- https://git.kernel.org/stable/c/5dd51e09020c65aa53cf128e5e3517cd53b3c113
- https://git.kernel.org/stable/c/8b136f18ac4b2ace5aaad3305b3f8a5d8165a009
- https://git.kernel.org/stable/c/91d105d2cbe002f9c7b43a6183adedc37e1da1f7
- https://git.kernel.org/stable/c/98b2e40879abf0245be5a5b7af69e0f6ff524ac3
- https://git.kernel.org/stable/c/b60e9391142e983fab2be53497aa8f71fdd09cd5
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().
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/153ea96c806aea395daba907a4f88480b6ad5093
- https://git.kernel.org/stable/c/67ba971ae02514d85818fe0c32549ab4bfa3bf49
- https://git.kernel.org/stable/c/76280b78cc9f23bdc6438e10ad6dff148ef8375b
- https://git.kernel.org/stable/c/afd64b59c3de9bbbdd3759e834fdc55cda716e0b
- https://git.kernel.org/stable/c/b18675263db1147c8e1cab625400c13a0d87bd2d
- https://git.kernel.org/stable/c/b7e91939ba9be805a62a257fa4e227dffbb88fa0
- https://git.kernel.org/stable/c/bf84ad7c7a9ede46e31afaa41a1ba06a159e8c87
- https://git.kernel.org/stable/c/c9b5ff59feffb92a147a84a5aa28acd2cb8ff4c5
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers. Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack. [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c
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/2e154b5f53f1b0b490c7b8b02499f90feb86b1d5
- https://git.kernel.org/stable/c/3027ecbdb5fdf9200251c21d4818e4c447ef78e1
- https://git.kernel.org/stable/c/8470f676eadeab99132708acb1a85915664d6115
- https://git.kernel.org/stable/c/af80f78ce984649e1698b841cd33f4fa505ad828
- https://git.kernel.org/stable/c/f071b0bf078146368d18e4eec386bf2ddc0ab7e0
HIGH8.2
In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.
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/0afc802160af0df61ed374fdb97fb34cfe5cdf2f
- https://git.kernel.org/stable/c/4cdda7f868f48e2f81579371584fdbdce37df2c8
- https://git.kernel.org/stable/c/573810f61bcd6b6815e2ff53bbdd2b9c9d747176
- https://git.kernel.org/stable/c/66eba0ffce3b7e11449946b4cbbef8ea36112f56
- https://git.kernel.org/stable/c/7c34f91305292083253df6a9f6c8ede02d4ccaea
- https://git.kernel.org/stable/c/8a1d6e40dedfe1068aee094d851bd69e289c9fd6
- https://git.kernel.org/stable/c/9e5da2379f968a3ea5a6e38921ab6201576466dc
- https://git.kernel.org/stable/c/ddddd8271359961e403d11c90c9ba9fc38914f7e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.
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/0ec9ddc1bda261a2c57636c74c8b4e53000102c9
- https://git.kernel.org/stable/c/0f8ba5e4c53d2e4a536aa68140beda9fe59b2f88
- https://git.kernel.org/stable/c/2fcba19caaeb2a33017459d3430f057967bb91b6
- https://git.kernel.org/stable/c/56ffbe3a08c01dcdb0d6adee9ce1e535bfb3b389
- https://git.kernel.org/stable/c/640441348258220e78daed40528b85b8afcedab6
- https://git.kernel.org/stable/c/aaf80701dc2f7a48fe543961e21f8ca3924d587c
- https://git.kernel.org/stable/c/debc57b83d5b323df74bf010c8d50fe26ad2ed6b
- https://git.kernel.org/stable/c/fbf0591275f50eae5733c3d7a8cd6c1e79933ffa
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.
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/14e4689c113b4c06af1069364ade24fdd7055f33
- https://git.kernel.org/stable/c/193989cc6d80dd8e0460fb3992e69fa03bf0ff9b
- https://git.kernel.org/stable/c/19a9493faa4bf3c7bd0a386f30b60b1bb4a3da03
- https://git.kernel.org/stable/c/25918720ba97f974a4f8d433b5a0132c5b43f6f3
- https://git.kernel.org/stable/c/7d4f5004511757e3984901ffb412fcf858d80ed5
- https://git.kernel.org/stable/c/c6376b9b1b4d2bad638256b1b3588e073344ae69
- https://git.kernel.org/stable/c/d10730a1f2caf08088e0db1b19b242f3e6fa5f06
- https://git.kernel.org/stable/c/e4feec3174036ba772006be74beee0efa09a9eb8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo->conn into a local with neither READ_ONCE() nor a NULL check. Both run from oplock_break() after opinfo_get_list() has dropped ci->m_lock, so a concurrent SMB2 LOGOFF (session_fd_check()) can set op->conn = NULL under ci->m_lock within that window. ksmbd_conn_r_count_inc(conn) then writes through NULL at offset 0xc4 -- a remotely triggerable oops. Guard both reads the way compare_guid_key() already does: read opinfo->conn with READ_ONCE() and return early if it is NULL, before allocating the work struct so nothing leaks. A NULL conn means the client is gone and the break is moot, so return 0; oplock_break() treats that as success and runs the normal 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:HReferences
- https://git.kernel.org/stable/c/1ff58dcfcab434ebb51649da33774fbb8e1f7b67
- https://git.kernel.org/stable/c/75e33deda658c1ab3a9336cbdb1436536f9b3660
- https://git.kernel.org/stable/c/945a86b21b40fb17183f5b27461baa6f03e2467f
- https://git.kernel.org/stable/c/b003086d76968298f22e7cf62239833b5a3a06b1
- https://git.kernel.org/stable/c/e735dbd489e3ea02be78dba991056fe1138be51e
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: erofs: fix use-after-free on sbi->sync_decompress z_erofs_decompress_kickoff() can race with filesystem unmount, causing a use-after-free on sbi->sync_decompress. When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff() to queue z_erofs_decompressqueue_work() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->sync_decompress. Thread (unmount) I/O completion kworker queue_work z_erofs_decompressqueue_work (all folios are unlocked) cleanup_mnt .. erofs_kill_sb erofs_sb_free kfree(sbi) access sbi->sync_decompress // UAF!!
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: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.
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/373152c94e57e9592b68c100e224fbd943cfd608
- https://git.kernel.org/stable/c/387a926ee166814611acecb960207fe2f3c4fd3e
- https://git.kernel.org/stable/c/416259cb5bffecaaae5f76539deb535a8c1b2c34
- https://git.kernel.org/stable/c/724d0caffd4204b46f78efe22f18f8338031c6e1
- https://git.kernel.org/stable/c/9a0dc9279d0907b198f205a693aedf696b08145d
- https://git.kernel.org/stable/c/ae847ab29ded2d7cece4d5970f0edefa4137bf2f
- https://git.kernel.org/stable/c/d366a01475f927402c96a3fe78bfc06b924fc87d
- https://git.kernel.org/stable/c/d5b57bb314d79e99bebb58a53588fa11dd4dbf69
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as the optval, an attacker can halt execution during the copy operation, keeping the lock held. Combined with asynchronous tear-down operations like shutdown(), this exhausts the kernel wq (kworkers) and triggers the hung task watchdog. [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds. [ 240.123489] Call Trace: [ 240.123501] smc_shutdown+... [ 240.123512] lock_sock_nested+... This patch moves the user-space copy outside the lock_sock() critical section to prevent 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/35a22117839602bb52283de08894c5a7dde92420
- https://git.kernel.org/stable/c/5d27d2ffe487df89ce28fda0410eafa05dbe03a0
- https://git.kernel.org/stable/c/89f6fbe0033c942cb790ffd53ca93a45eeaf1c91
- https://git.kernel.org/stable/c/94d286fa5eedc550d42bcb9c85416af8f77736ff
- https://git.kernel.org/stable/c/a3fdd924d88c30b9f488636ce0e4696012cf5511
- https://git.kernel.org/stable/c/dcd90f42a33e4220385f27b515183d0c91b2fc4a
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved:
ipv6: mcast: Fix use-after-free when processing MLD queries
When processing an MLD query, a pointer to the multicast group address
is retrieved when initially parsing the packet. This pointer is later
dereferenced without being reloaded despite the fact that the skb header
might have been reallocated following the pskb_may_pull() calls, leading
to a use-after-free [1].
Fix by copying the multicast group address when the packet is initially
parsed.
[1]
BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512)
Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118
Workqueue: mld mld_query_work
Call Trace:
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_address_description.constprop.0 (mm/kasan/report.c:378)
print_report (mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
__mld_query_work (net/ipv6/mcast.c:1512)
mld_query_work (net/ipv6/mcast.c:1563)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
[...]
Freed by task 118:
kasan_save_stack (mm/kasan/common.c:57)
kasan_save_track (mm/kasan/common.c:78)
kasan_save_free_info (mm/kasan/generic.c:584)
__kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
pskb_expand_head (net/core/skbuff.c:2335)
__pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4))
__mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1))
mld_query_work (net/ipv6/mcast.c:1563)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
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/087dbacf897c020f438f780f0a4a8aa73b6d7c5a
- https://git.kernel.org/stable/c/1354271c89d0e5fbf8b3d94097ff0216695209c7
- https://git.kernel.org/stable/c/2a613bf497029d555a7428406aa8cdb84a503cea
- https://git.kernel.org/stable/c/4203806f700bb44ea0b05d484d9d40044b47fb04
- https://git.kernel.org/stable/c/53baa63a4183291574483f89583dbef13677a2c4
- https://git.kernel.org/stable/c/791c91dc7a9dfb2457d5e29b8216a6484b9c4b40
- https://git.kernel.org/stable/c/b2eb8886200b907fc71806869620609f0f4cacb0
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