HIGH7.8
Уязвимость функции skb_try_coalesce() ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS 2.0СРЕДНЯЯ 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
ALT-PU-2026-9245-1Обновление пакета kernel-image-6.18 в ветке sisyphus_loongarch64
Серьёзность:
Закрытые проблемы (95)
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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
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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:HСсылки
- 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: 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.xСРЕДНЯЯ 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/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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu() Two bugs exist in the vCPU initialisation path: 1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup path jumps to 'unlock' without calling unpin_host_vcpu() or unpin_host_sve_state(), permanently leaking pin references on the host vCPU and SVE state pages. Extract a register_hyp_vcpu() helper that performs the checks and the store. When register_hyp_vcpu() returns an error, call unpin_host_vcpu() and unpin_host_sve_state() inline before falling through to the existing 'unlock' label. 2. register_hyp_vcpu() publishes the new vCPU pointer into 'hyp_vm->vcpus[]' with a bare store, allowing a concurrent caller of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU object. Ensure the store uses smp_store_release() and the load uses smp_load_acquire(). While 'vm_table_lock' currently serialises the store and the load, these barriers ensure the reader sees the fully initialised 'hyp_vcpu' object even if there were a lockless path or if the lock's own ordering guarantees were insufficient for nested object initialization.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: control built-in cs manually The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO. This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled. Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use. As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.
CVSS 3.xСРЕДНЯЯ 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: 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:NСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- 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
HIGH7.0
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Read scx_root under scx_cgroup_ops_rwsem in cgroup setters scx_group_set_{weight,idle,bandwidth}() cache scx_root before acquiring scx_cgroup_ops_rwsem, so the pointer can be stale by the time the op runs. If the loaded scheduler is disabled and freed (via RCU work) and another is enabled between the naked load and the rwsem acquire, the reader sees scx_cgroup_enabled=true (the new scheduler's) but dereferences the freed one - UAF on SCX_HAS_OP(sch, ...) / SCX_CALL_OP(sch, ...). scx_cgroup_enabled is toggled only under scx_cgroup_ops_rwsem write (scx_cgroup_{init,exit}), so reading scx_root inside the rwsem read section correlates @sch with the enabled snapshot.
CVSS 3.xВЫСОКАЯ 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCRITICAL9.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.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HMEDIUM5.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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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: riscv: kvm: fix vector context allocation leak When the second kzalloc (host_context.vector.datap) fails in kvm_riscv_vcpu_alloc_vector_context, the first allocation (guest_context.vector.datap) is leaked. Free it before returning.
CVSS 3.xСРЕДНЯЯ 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: 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HСсылки
- 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.1
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix fsck inconsistency caused by FGGC of node block During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data. The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes. In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing. This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:HHIGH7.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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.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.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event() Sashiko points out the radix_tree itself is RCU safe, but nothing ever frees the mlx4_srq struct with RCU, and it isn't even accessed within the RCU critical section. It also will crash if an event is delivered before the srq object is finished initializing. Use the spinlock since it isn't easy to make RCU work, use refcount_inc_not_zero() to protect against partially initialized objects, and order the refcount_set() to be after the srq is fully initialized.
CVSS 3.xВЫСОКАЯ 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: pseries/papr-hvpipe: Prevent kernel stack memory leak to userspace The hdr variable is allocated on the stack and only hdr.version and hdr.flags are initialized explicitly. Because the struct papr_hvpipe_hdr contains reserved padding bytes (reserved[3] and reserved2[40]), these could leak the uninitialized bytes to userspace after copy_to_user(). This patch fixes that by initializing the whole struct to 0.
CVSS 3.xСРЕДНЯЯ 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: 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xКРИТИЧЕСКАЯ 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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: spi: microchip-core-qspi: don't attempt to transmit during emulated read-only dual/quad operations The core will deal with reads by creating clock cycles itself, there's no need to generate clock cycles by transmitting garbage data at the driver level. Further, transmitting garbage data just bricks the transfer since QSPI doesn't have a dedicated master-out line like MOSI in regular SPI. I'm not entirely sure if the transfer is bricked because of the garbage data being transmitted on the bus or because the core loses track of whether it is supposed to be sending or receiving data.
CVSS 3.xСРЕДНЯЯ 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: 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xКРИТИЧЕСКАЯ 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- 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
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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 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.xВЫСОКАЯ 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:
HID: appletb-kbd: run inactivity autodim from workqueues
The autodim code in hid-appletb-kbd takes backlight_device->ops_lock
via backlight_device_set_brightness() -> mutex_lock() from two
different atomic contexts:
* appletb_inactivity_timer() is a struct timer_list callback, so it
runs in softirq context. Every expiry triggers
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
Call Trace:
__might_resched
__mutex_lock
backlight_device_set_brightness
appletb_inactivity_timer
call_timer_fn
run_timer_softirq
* reset_inactivity_timer() is called from appletb_kbd_hid_event() and
appletb_kbd_inp_event(). On real USB hardware these run in
softirq/IRQ context (URB completion and input-event dispatch).
When the Touch Bar has already been dimmed or turned off, the
reset path calls backlight_device_set_brightness() directly to
restore brightness, producing the same warning.
Both call sites hit the same mutex_lock()-from-atomic bug. Fix them
together by moving the blocking work onto the system workqueue:
* Convert the inactivity timer from struct timer_list to
struct delayed_work; the callback (appletb_inactivity_work) now
runs in process context where mutex_lock() is legal.
* Add a dedicated struct work_struct restore_brightness_work and have
reset_inactivity_timer() schedule it instead of calling
backlight_device_set_brightness() directly.
Cancel both works synchronously during driver tear-down alongside the
existing backlight reference drop.
The semantics are unchanged (same delays, same state transitions on
dim, turn-off and user activity); only the execution context of the
sleeping call changes. The timer field and callback are renamed to
match their new type; reset_inactivity_timer() keeps its name because
it is invoked from input event paths that read naturally as "reset
the inactivity timer".
CVSS 3.xСРЕДНЯЯ 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/vcn4: Prevent OOB reads when parsing IB Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks.
CVSS 3.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 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.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- 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
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in
appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to
both the probe close_hw error path and appletb_kbd_remove(), but the
way it was wired in left the inactivity timer reachable during driver
tear-down via two distinct windows.
Window A -- put_device() before timer_delete_sync():
put_device(&kbd->backlight_dev->dev);
timer_delete_sync(&kbd->inactivity_timer);
The inactivity_timer softirq reads kbd->backlight_dev and calls
backlight_device_set_brightness() -> mutex_lock(&ops_lock). If a
concurrent hid_appletb_bl unbind drops the last devm reference
between these two calls, the backlight_device is freed and the
mutex_lock() touches freed memory.
Window B -- backlight cleanup before hid_hw_stop():
if (kbd->backlight_dev) {
timer_delete_sync(...);
put_device(...);
}
hid_hw_close(hdev);
hid_hw_stop(hdev);
Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run
afterwards, so a late ".event" callback from the HID core (USB URB
completion on real Apple hardware) can arrive after
timer_delete_sync() drained the softirq but before put_device() drops
the reference. That callback reaches reset_inactivity_timer(), which
calls mod_timer() and re-arms the timer. The freshly re-armed timer
can then fire on the about-to-be-freed backlight_device.
Both windows produce the same KASAN slab-use-after-free:
BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0
Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0
Call Trace:
__mutex_lock
backlight_device_set_brightness
appletb_inactivity_timer
call_timer_fn
run_timer_softirq
handle_softirqs
Allocated by task N:
devm_backlight_device_register
appletb_bl_probe
Freed by task M:
(concurrent hid_appletb_bl unbind path)
Close both windows at once by reworking the tear-down in
appletb_kbd_remove() and in the probe close_hw error path so that
1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup,
guaranteeing no further .event callback can fire and re-arm the
timer, and
2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync()
runs before put_device(), so the softirq is drained before the
final reference is dropped.
CVSS 3.xВЫСОКАЯ 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: 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- https://git.kernel.org/stable/c/29371f3cc83e2a92265b4768014a30b80234112f
- https://git.kernel.org/stable/c/2ea5d2c79edcc99c7dbe0bb7518f5e1ee2a2391f
- https://git.kernel.org/stable/c/52bcb57a4e8a0865a76c587c2451906342ae1b2d
- https://git.kernel.org/stable/c/65c484726e74013a2ec7ba67a34d87760ae8f390
- https://git.kernel.org/stable/c/6d3275fc4ed968938e1d556c344798046776668d
- https://git.kernel.org/stable/c/e9edf9893cf26d060705c910a9b62d8cc96ed56a
- https://git.kernel.org/stable/c/f66c7904fb6f0e420a654bc90909e64a25d00896
- https://git.kernel.org/stable/c/fd51e810affa38d735d04261e673b2a5fe9c8665
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths
CVSS 3.xВЫСОКАЯ 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: 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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: EDAC/versalnet: Fix device name memory leak The device name allocated via kzalloc() in init_one_mc() is assigned to dev->init_name but never freed on the normal removal path. device_register() copies init_name and then sets dev->init_name to NULL, so the name pointer becomes unreachable from the device. Thus leaking memory. Use a stack-local char array instead of using kzalloc() for name.
CVSS 3.xСРЕДНЯЯ 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/xe: Fix bo leak in xe_dma_buf_init_obj() on allocation failure When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo is not freed. Add xe_bo_free(storage) before returning the error. xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the bo on error. Therefore, xe_dma_buf_init_obj() must also free the bo on its own error paths. Otherwise, since xe_gem_prime_import() cannot distinguish whether the failure originated from xe_dma_buf_init_obj() or from xe_bo_init_locked(), it cannot safely decide whether the bo should be freed. Add comments documenting the ownership semantics: on success, ownership of storage is transferred to the returned drm_gem_object; on failure, storage is freed before returning. v2: Add comments to explain the free logic. (cherry picked from commit 78a6c5f899f22338bbf48b44fb8950409c5a69b9)
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HMEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: rspi: fix controller deregistration Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the controller and driver data lifetime so that they are released on driver unbind. Note that this also makes sure that the SPI controller is placed correctly under the USB interface in the device tree.
CVSS 3.xСРЕДНЯЯ 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: 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xСРЕДНЯЯ 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- 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: media: iris: Fix use-after-free in iris_release_internal_buffers() The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") introduced a regression where session_release_buf() may free the buffer. The caller, iris_release_internal_buffers(), continued to access `buffer` after the call, leading to a potential use-after-free. Fix this by setting BUF_ATTR_PENDING_RELEASE before calling session_release_buf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing.
CVSS 3.xВЫСОКАЯ 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: 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.xВЫСОКАЯ 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: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.
CVSS 3.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HHIGH8.6
In the Linux kernel, the following vulnerability has been resolved:
ibmveth: Disable GSO for packets with small MSS
Some physical adapters on Power systems do not support segmentation
offload when the MSS is less than 224 bytes. Attempting to send such
packets causes the adapter to freeze, stopping all traffic until
manually reset.
Implement ndo_features_check to disable GSO for packets with small MSS
values. The network stack will perform software segmentation instead.
The 224-byte minimum matches ibmvnic
commit ("ibmvnic: Enforce stronger sanity checks
on GSO packets")
which uses the same physical adapters in SEA configurations.
The issue occurs specifically when the hardware attempts to perform
segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets
(gso_segs == 1) do not trigger the problematic LSO code path and are
transmitted normally without segmentation.
Add an ndo_features_check callback to disable GSO when MSS < 224 bytes.
Also call vlan_features_check() to ensure proper handling of VLAN packets,
particularly QinQ (802.1ad) configurations where the hardware parser may
not support certain offload features.
Validated using iptables to force small MSS values. Without the fix,
the adapter freezes. With the fix, packets are segmented in software
and transmission succeeds. Comprehensive regression testing completedd
(MSS tests, performance, stability).
CVSS 3.xВЫСОКАЯ 8.6
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:HСсылки
- 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.xВЫСОКАЯ 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- 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