HIGH8.8
Уязвимость компонента xfrm ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HCVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
ALT-PU-2026-8289-4Package update kernel-image-6.12 in branch c10f2
Severity:
Closed issues (33)
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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Limit BO list entry count to prevent resource exhaustion Userspace can pass an arbitrary number of BO list entries via the bo_number field. Although the previous multiplication overflow check prevents out-of-bounds allocation, a large number of entries could still cause excessive memory allocation (up to potentially gigabytes) and unnecessarily long list processing times. Introduce a hard limit of 128k entries per BO list, which is more than sufficient for any realistic use case (e.g., a single list containing all buffers in a large scene). This prevents memory exhaustion attacks and ensures predictable performance. Return -EINVAL if the requested entry count exceeds the limit (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/2723e6851309531ce61aed74e93a0cd268cc862a
- https://git.kernel.org/stable/c/5ce4a38e6c2488949e373d5066303f9c128db614
- https://git.kernel.org/stable/c/6270b1a5dab94665d7adce3dc78bc9066ed28bdd
- https://git.kernel.org/stable/c/c833d6c7199c5b5fca9ec95593acd539ec9c171c
- https://git.kernel.org/stable/c/e620378aab78d415bd8a15a2f91c145906520288
- https://git.kernel.org/stable/c/f462624a6e4b5f1ec2664c2c53e408b2f4fb53e9
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: fix use-after-free in bond_xmit_broadcast()
bond_xmit_broadcast() reuses the original skb for the last slave
(determined by bond_is_last_slave()) and clones it for others.
Concurrent slave enslave/release can mutate the slave list during
RCU-protected iteration, changing which slave is "last" mid-loop.
This causes the original skb to be double-consumed (double-freed).
Replace the racy bond_is_last_slave() check with a simple index
comparison (i + 1 == slaves_count) against the pre-snapshot slave
count taken via READ_ONCE() before the loop. This preserves the
zero-copy optimization for the last slave while making the "last"
determination stable against concurrent list mutations.
The UAF can trigger the following crash:
==================================================================
BUG: KASAN: slab-use-after-free in skb_clone
Read of size 8 at addr ffff888100ef8d40 by task exploit/147
CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY
Call Trace:
dump_stack_lvl (lib/dump_stack.c:123)
print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:597)
skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108)
bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334)
bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593)
dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887)
__dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838)
ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136)
ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219)
ip6_output (net/ipv6/ip6_output.c:250)
ip6_send_skb (net/ipv6/ip6_output.c:1985)
udp_v6_send_skb (net/ipv6/udp.c:1442)
udpv6_sendmsg (net/ipv6/udp.c:1733)
__sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Allocated by task 147:
Freed by task 147:
The buggy address belongs to the object at ffff888100ef8c80
which belongs to the cache skbuff_head_cache of size 224
The buggy address is located 192 bytes inside of
freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)
Memory state around the buggy address:
ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM5.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:HHIGH8.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://github.com/V4bel/dirtyfrag
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
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
CRITICAL9.1
In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in smb2_compound_op() If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, check_wsl_eas() returns success without validating that the entire OutputBufferLength fits within iov_len. Then smb2_compound_op() does: memcpy(idata->wsl.eas, data[0], size[0]); Where size[0] is OutputBufferLength. If iov_len is smaller than size[0], memcpy can read beyond the end of the rsp_iov allocation and leak adjacent kernel heap memory.
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
- https://git.kernel.org/stable/c/512d33bc8ea4ea5c19728ee118715f4b1f4d1926
- https://git.kernel.org/stable/c/8d09328dfda089675e4c049f3f256064a1d1996b
- https://git.kernel.org/stable/c/9b3af35645ff9cd334edc130249f9a2fb2bea25f
- https://git.kernel.org/stable/c/a16f70a71be4b5a4eccf39a9bf09b47285f4cb7c
- https://git.kernel.org/stable/c/dffb44b2e06a2908e249f0f93156fc987eee1d1c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang() The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU: lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ... Add a default switch case to fix the panic as below: Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210 ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210 [<9000000000eebc08>] pci_fixup_device+0x108/0x280 [<9000000000ebb70c>] pci_setup_device+0x24c/0x690 [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140 [<9000000000ebc684>] pci_scan_slot+0xc4/0x280 [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0 [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420 [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440 [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0 [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<90000000010e200c>] device_for_each_child+0x6c/0xe0 [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70 [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0 [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280 [<900000000189c028>] acpi_scan_init+0x194/0x310 [<900000000189bc6c>] acpi_init+0xcc/0x140 [<9000000000220cdc>] do_one_initcall+0x4c/0x310 [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4 [<900000000184326c>] kernel_init+0x28/0x13c [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/07d190e4ec689d6478f7f5e36099fb9bf457e7c5
- https://git.kernel.org/stable/c/2cb19b06c09983727573bbe7d7430cbad480a714
- https://git.kernel.org/stable/c/81fef1c278436e6bd68ee4ca05a0acb96e256561
- https://git.kernel.org/stable/c/8dfa2f8780e486d05b9a0ffce70b8f5fbd62053e
- https://git.kernel.org/stable/c/9e1aed63a5552958ef2a9bfd699a3f990e52a77f
- https://git.kernel.org/stable/c/bfde8accc3e3260c0ecbb8cc34361739e1e16f31
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race. And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing. Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HMEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- https://git.kernel.org/stable/c/4fdc6ee0802121d9cd96b8d085e589f51e5a4ec3
- https://git.kernel.org/stable/c/5d12e0ab009ade48c1bff9324fd9bea2c773d088
- https://git.kernel.org/stable/c/973e57c726c1f8e77259d1c8e519519f1e9aea77
- https://git.kernel.org/stable/c/d09d67d5de577cedae3de9497dff217e0ac8b641
- https://git.kernel.org/stable/c/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/36fcc2c7517f8a86379154c9793f867592aa8b7e
- https://git.kernel.org/stable/c/999757231c49376cd1a37308d2c8c4c9932571e1
- https://git.kernel.org/stable/c/aa9c3ecaf7337df3a689318584f879b5339ede0f
- 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: 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
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/c623b63580880cc742255eaed3d79804c1b91143
- https://git.kernel.org/stable/c/d16827cb1d3936f7627d0da6044483f743ebde03
- 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
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/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/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/e4ef723d8975a2694cc90733a6b888a5e2841842
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