MEDIUM5.5
Уязвимость функции sigd_send() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xСРЕДНЯЯ 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HCVSS 2.0СРЕДНЯЯ 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
ALT-PU-2026-7465-12Обновление пакета kernel-image-rt в ветке p10
Серьёзность:
Закрытые проблемы (84)
HIGH7.5
Уязвимость функции tcp_write_xmit() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCVSS 2.0ВЫСОКАЯ 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:CMEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: rpmsg: core: fix race in driver_override_show() and use core helper The driver_override_show function reads the driver_override string without holding the device_lock. However, the store function modifies and frees the string while holding the device_lock. This creates a race condition where the string can be freed by the store function while being read by the show function, leading to a use-after-free. To fix this, replace the rpmsg_string_attr macro with explicit show and store functions. The new driver_override_store uses the standard driver_set_override helper. Since the introduction of driver_set_override, the comments in include/linux/rpmsg.h have stated that this helper must be used to set or clear driver_override, but the implementation was not updated until now. Because driver_set_override modifies and frees the string while holding the device_lock, the new driver_override_show now correctly holds the device_lock during the read operation to prevent the race. Additionally, since rpmsg_string_attr has only ever been used for driver_override, removing the macro simplifies the code.
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/2e4a70f3c30910427e5ea848b799066d67b963d5
- https://git.kernel.org/stable/c/392c6b68334aa0e0ae9aba95c0a366bcb0d92f5d
- https://git.kernel.org/stable/c/42023d4b6d2661a40ee2dcf7e1a3528a35c638ca
- https://git.kernel.org/stable/c/47615557447185917afa432b7958f87583c417cb
- https://git.kernel.org/stable/c/7654e6e3cd6bdee9602f6063b3c670bd556d7e61
- https://git.kernel.org/stable/c/90c8353f471821d7ccd4fe573a2402e056192494
- https://git.kernel.org/stable/c/954557957177c3c13d7c655976665b1170da5e50
- https://git.kernel.org/stable/c/d66b8074c555e8abb0ae19eea1c9f3635498bdde
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: jfs: nlink overflow in jfs_rename If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions.
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/2108829a59f081e822fdab8c2cd7131deb8aa8a1
- https://git.kernel.org/stable/c/5d77c36cd4b698649f5c30c5f6c084f4f61d1880
- https://git.kernel.org/stable/c/9218dc26fd922b09858ecd3666ed57dfd8098da8
- https://git.kernel.org/stable/c/93c325746ae59709b4f9bad4e3e4761c8d566c70
- https://git.kernel.org/stable/c/a3d66089e50a6e0142f8884471f74292102ea9aa
- https://git.kernel.org/stable/c/b4330a0d0947fbdc9d445cbbeabd8cc910a8c9ca
- https://git.kernel.org/stable/c/f70fcbc2ac7c24f087a2c895c5753aa730b1e479
- https://git.kernel.org/stable/c/fe136426e30ca6debcf916fd6a141555ed9fde74
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix potential NULL pointer dereference in header processing If siw_get_hdr() returns -EINVAL before set_rx_fpdu_context(), qp->rx_fpdu can be NULL. The error path in siw_tcp_rx_data() dereferences qp->rx_fpdu->more_ddp_segs without checking, which may lead to a NULL pointer deref. Only check more_ddp_segs when rx_fpdu is present. KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siw_tcp_rx_data+0x13ad/0x1e50
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/14ab3da122bd18920ad57428f6cf4fade8385142
- https://git.kernel.org/stable/c/714c99e1dc8f85f446e05be02ba83972e981a817
- https://git.kernel.org/stable/c/8564dcc12fbb372d984ab45768cae9335777b274
- https://git.kernel.org/stable/c/87b7a036d2c73d5bb3ae2d47dee23de465db3355
- https://git.kernel.org/stable/c/ab61841633d10e56a58c1493a262f0d02dba2f5e
- https://git.kernel.org/stable/c/ab957056192d6bd068b3759cb2077d859cca01f0
- https://git.kernel.org/stable/c/ce025f7f5d070596194315eb2e4e89d568b8a755
- https://git.kernel.org/stable/c/ffba40b67663567481fa8a1ed5d2da36897c175d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80
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/1371ef6b1ecf3676b8942f5dfb3634fb0648128e
- https://git.kernel.org/stable/c/205955f29c26330b1dc7fdeadd5bb97c38e26f56
- https://git.kernel.org/stable/c/362e45fd9069ffa1523f9f1633b606ebf72060d7
- https://git.kernel.org/stable/c/52ab82cc5cf8ada5c3fb6ffe8f32fdb2fc27a34b
- https://git.kernel.org/stable/c/5551b02fdbfd85a325bb857f3a8f9c9f33397ed2
- https://git.kernel.org/stable/c/6eb2919474ca105c5b13d19574e25f0ddcf19ca2
- https://git.kernel.org/stable/c/9c80d688f402539dfc8f336de1380d6b4ee14316
- https://git.kernel.org/stable/c/a6a3e4af10993cb9e4b8f0548680aba0ab5f3b0d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
macvlan: observe an RCU grace period in macvlan_common_newlink() error path
valis reported that a race condition still happens after my prior patch.
macvlan_common_newlink() might have made @dev visible before
detecting an error, and its caller will directly call free_netdev(dev).
We must respect an RCU period, either in macvlan or the core networking
stack.
After adding a temporary mdelay(1000) in macvlan_forward_source_one()
to open the race window, valis repro was:
ip link add p1 type veth peer p2
ip link set address 00:00:00:00:00:20 dev p1
ip link set up dev p1
ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source
(ip link add invalid% link p2 type macvlan mode source macaddr add
00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
RTNETLINK answers: Invalid argument
BUG: KASAN: slab-use-after-free in macvlan_forward_source
(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)
Read of size 8 at addr ffff888016bb89c0 by task e/175
CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
dump_stack_lvl (lib/dump_stack.c:123)
print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)
? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)
kasan_report (mm/kasan/report.c:597)
? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)
macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)
? tasklet_init (kernel/softirq.c:983)
macvlan_handle_frame (drivers/net/macvlan.c:501)
Allocated by task 169:
kasan_save_stack (mm/kasan/common.c:58)
kasan_save_track (./arch/x86/include/asm/current.h:25
mm/kasan/common.c:70 mm/kasan/common.c:79)
__kasan_kmalloc (mm/kasan/common.c:419)
__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657
mm/slub.c:7140)
alloc_netdev_mqs (net/core/dev.c:12012)
rtnl_create_link (net/core/rtnetlink.c:3648)
rtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957
net/core/rtnetlink.c:4072)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)
Freed by task 169:
kasan_save_stack (mm/kasan/common.c:58)
kasan_save_track (./arch/x86/include/asm/current.h:25
mm/kasan/common.c:70 mm/kasan/common.c:79)
kasan_save_free_info (mm/kasan/generic.c:587)
__kasan_slab_free (mm/kasan/common.c:287)
kfree (mm/slub.c:6674 mm/slub.c:6882)
rtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957
net/core/rtnetlink.c:4072)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)
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/19c7d8ac51988d053709c1e85bd8482076af845d
- https://git.kernel.org/stable/c/1e58ae87ad1e6e24368dea9aec9048c758cd0e2b
- https://git.kernel.org/stable/c/3d94323c80d7fc4da5f10f9bb06a45d39d5d3cc4
- https://git.kernel.org/stable/c/721eb342d9ba19bad5c4815ea3921465158b7362
- https://git.kernel.org/stable/c/91e4ff8d966978901630fc29582c1a76d3c6e46c
- https://git.kernel.org/stable/c/a1f686d273d129b45712d95f4095843b864466bd
- https://git.kernel.org/stable/c/d34f7a8aa9a25b7e64e0e46e444697c0f702374d
- https://git.kernel.org/stable/c/e3f000f0dee1bfab52e2e61ca6a3835d9e187e35
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: atm: fix crash due to unvalidated vcc pointer in sigd_send() Reproducer available at [1]. The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged: int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // become ATM signaling daemon struct msghdr msg = { .msg_iov = &iov, ... }; *(unsigned long *)(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values. Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found. Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used. Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety. [1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
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/1c8bda3df028d5e54134077dcd09f46ca8cfceb5
- https://git.kernel.org/stable/c/21c303fec138c002f90ed33bce60e807d53072bb
- https://git.kernel.org/stable/c/3e1a8b00095246a9a2b46b57f6d471c6d3c00ed2
- https://git.kernel.org/stable/c/440c9a5fc477a8ee259d8bf669531250b8398651
- https://git.kernel.org/stable/c/69d3f9ee5489e6e8b66defcfa226e91d82393297
- https://git.kernel.org/stable/c/ae88a5d2f29b69819dc7b04086734439d074a643
- https://git.kernel.org/stable/c/c96549d07dfdd51aadf0722cfb40711574424840
- https://git.kernel.org/stable/c/e3f80666c2739296c3b69a127300455c43aa1067
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: pstore: ram_core: fix incorrect success return when vmap() fails In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() 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/05363abc7625cf18c96e67f50673cd07f11da5e9
- https://git.kernel.org/stable/c/1da904e84de608907662ad8a51ba9c571d61e003
- https://git.kernel.org/stable/c/2c99326dc1c79b7ce3c8dd92929b5ce724ff70eb
- https://git.kernel.org/stable/c/49918dd52615097529811d21ec6074dd02ebe77c
- https://git.kernel.org/stable/c/88d5b28f63c7aac1271784e3b800ed405d1cde75
- https://git.kernel.org/stable/c/8baa234181f632cabacf73e4834a910859e9fcc9
- https://git.kernel.org/stable/c/8d849adfbc3e98417fb541620568db1a759ef441
- https://git.kernel.org/stable/c/d47234840aeb4182ed3ee795c578b1dfa9cbd25b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") relies on pci_dev_is_disconnected() to skip ATS invalidation for safely-removed devices, but it does not cover link-down caused by faults, which can still hard-lock the system. For example, if a VM fails to connect to the PCIe device, "virsh destroy" is executed to release resources and isolate the fault, but a hard-lockup occurs while releasing the group fd. Call Trace: qi_submit_sync qi_flush_dev_iotlb intel_pasid_tear_down_entry device_block_translation blocking_domain_attach_dev __iommu_attach_device __iommu_device_set_domain __iommu_group_set_domain_internal iommu_detach_group vfio_iommu_type1_detach_group vfio_group_detach_container vfio_group_fops_release __fput Although pci_device_is_present() is slower than pci_dev_is_disconnected(), it still takes only ~70 µs on a ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed and width increase. Besides, devtlb_invalidation_with_pasid() is called only in the paths below, which are far less frequent than memory map/unmap. 1. mm-struct release 2. {attach,release}_dev 3. set/remove PASID 4. dirty-tracking setup The gain in system stability far outweighs the negligible cost of using pci_device_is_present() instead of pci_dev_is_disconnected() to decide when to skip ATS invalidation, especially under GDR high-load conditions.
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/01aed2f1d7cb8fdf4c60c5bb4727608cb82b401d
- https://git.kernel.org/stable/c/0da6697e577023d8867c7beb2d16a22510e4eea9
- https://git.kernel.org/stable/c/10e60d87813989e20eac1f3eda30b3bae461e7f9
- https://git.kernel.org/stable/c/581ce094d9eafb78ec4f9de77bd24b780c151236
- https://git.kernel.org/stable/c/9813306610d0d718c863aaa70928bf57d7570ec0
- https://git.kernel.org/stable/c/9deaacc8dcaddb6ddc5b52e1e63b457450ec0f94
- https://git.kernel.org/stable/c/e2c78c69f8faf2885ea4ceee08c71ac738f401a0
- https://git.kernel.org/stable/c/ead67d0378e90f419e385a43af29435242d80c12
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: dm-verity: correctly handle dm_bufio_client_create() failure If either of the calls to dm_bufio_client_create() in verity_fec_ctr() fails, then dm_bufio_client_destroy() is later called with an ERR_PTR() argument. That causes a crash. Fix this.
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/031f2adc1499b112a39ac316bbab3c80bba16cf2
- https://git.kernel.org/stable/c/119f4f04186fa4f33ee6bd39af145cdaff1ff17f
- https://git.kernel.org/stable/c/451cc650e40e8c3222d37877a9e4be0fcaacb9c8
- https://git.kernel.org/stable/c/5c2217ddb3b7e7ac25f4ebe9061258fc8f1c9167
- https://git.kernel.org/stable/c/6283e49af87a9c121bb01e5a64a7fe5706c210bc
- https://git.kernel.org/stable/c/9b8dc1d327e2928f3da59ced0595d850d31c0936
- https://git.kernel.org/stable/c/b154a868a3856fb5216c4f82981d8a503832e095
- https://git.kernel.org/stable/c/d3e1f1adc8a0289efe2d2cdc90edb8c6ffe0b5ef
HIGH8.1
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ This adds a check for encryption key size upon receiving L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAP_CR_LE_BAD_KEY_SIZE.
CVSS 3.xВЫСОКАЯ 8.1
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NСсылки
- https://git.kernel.org/stable/c/138d7eca445ef37a0333425d269ee59900ca1104
- https://git.kernel.org/stable/c/335071c0c3637064ec250481f589075db44fe4e6
- https://git.kernel.org/stable/c/481ea39b342c347b6ac029f3d418486280be4e45
- https://git.kernel.org/stable/c/8dd43f9a9323f9c01bc8246da8d81a4c783c9e97
- https://git.kernel.org/stable/c/9118601ff90b79e8df3c0c98f48ae00c1b02ecef
- https://git.kernel.org/stable/c/96581749c7c14fbec32c35728520867929600041
- https://git.kernel.org/stable/c/ec91078e132179b04e0c3906b599816c056ceaad
- https://git.kernel.org/stable/c/fa6ad76fa8623c0a50d529cd5726fa5d819a3be4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: cx23885: Add missing unmap in snd_cx23885_hw_params() In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map().
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/0b7f56084cc3d7766bf274b71cd14cc9674b76bf
- https://git.kernel.org/stable/c/141c81849fab2ad4d6e3fdaff7cbaa873e8b5eb2
- https://git.kernel.org/stable/c/505630dd1ebf4b53d3f2866c057ddd93157a24d8
- https://git.kernel.org/stable/c/544215cc37d032ccaf1919852c05e2439a4d7540
- https://git.kernel.org/stable/c/9544b73cad4ee667fed6a60f71570c58a870a735
- https://git.kernel.org/stable/c/9c0a6ff538660c36a98081916a24f08d55a91331
- https://git.kernel.org/stable/c/fc4df593a8ffded2f77d69a73ecb51d364932ca5
- https://git.kernel.org/stable/c/fda46c9025b755ea50a969b960f333be62421b71
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Check maxfield in hidpp_get_report_length() Do not crash when a report has no fields. Fake USB gadgets can send their own HID report descriptors and can define report structures without valid fields. This can be used to crash the kernel over USB.
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/1547d41f9f19d691c2c9ce4c29f746297baef9e9
- https://git.kernel.org/stable/c/1acb28123e57b50d737377f400f57eec889fe5e4
- https://git.kernel.org/stable/c/2dc023dbc11b8dfa8afa63242762acd8cddcad03
- https://git.kernel.org/stable/c/7f59999fcd699af06ad2aef446a635ea6aa87db3
- https://git.kernel.org/stable/c/ae81fac9ce81917817d787e6b74e68482d99bdf2
- https://git.kernel.org/stable/c/b74bf7d0d01fa9b53653f58c29aa00772121f6e9
- https://git.kernel.org/stable/c/f1ceaaf93ea32d0f2b95c95f784ee155962c52ad
- https://git.kernel.org/stable/c/fb1725c0804dbec9dd01c4cb5c9f1f77a69e36dc
HIGH8.6
In the Linux kernel, the following vulnerability has been resolved: xfrm6: fix uninitialized saddr in xfrm6_get_saddr() xfrm6_get_saddr() does not check the return value of ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6_get_saddr() still returns 0 (success). This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized address in xfrm_state_find(), triggering KMSAN warning: ===================================================== BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940 xfrm_state_find+0x2424/0xa940 xfrm_resolve_and_create_bundle+0x906/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 xfrm_lookup_route+0x63/0x2b0 ip_route_output_flow+0x1ce/0x270 udp_sendmsg+0x2ce1/0x3400 inet_sendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64_sys_sendto+0x130/0x200 x64_sys_call+0x332b/0x3e70 do_syscall_64+0xd3/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable tmp.i.i created at: xfrm_resolve_and_create_bundle+0x3e3/0x5a20 xfrm_lookup_with_ifid+0xcc0/0x3770 ===================================================== Fix by checking the return value of ipv6_dev_get_saddr() and propagating the error.
CVSS 3.xВЫСОКАЯ 8.6
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:HСсылки
- https://git.kernel.org/stable/c/1799d8abeabc68ec05679292aaf6cba93b343c05
- https://git.kernel.org/stable/c/3dcd1664ac15eee6a690daec7c4ffc59190406f7
- https://git.kernel.org/stable/c/4f28141786e1fe884ce42a5197ba9beed540f0ea
- https://git.kernel.org/stable/c/6535867673bf301d52aa00593a4d1d18cc3922fa
- https://git.kernel.org/stable/c/719918fc88df6da023dfff370cd965151a5afd7f
- https://git.kernel.org/stable/c/c7221e7bd8fc2ef38a0b27be580d9d202281306b
- https://git.kernel.org/stable/c/dc0abce055134cb83b0d981d31ceb20dda419787
- https://git.kernel.org/stable/c/eb2ee15290af14c60b45cf2b73f5687d1d077d9b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: HID: magicmouse: Do not crash on missing msc->input Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, msc->input stays NULL, leading to a crash at a later time. Detect this condition in the input_configured() hook and reject the device. This is not supposed to happen with actual magic mouse devices, but can be provoked by imposing as a magic mouse USB 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/165912d4321c692321c02793068d30700b4e0f1a
- https://git.kernel.org/stable/c/17abd396548035fbd6179ee1a431bd75d49676a7
- https://git.kernel.org/stable/c/243e1165eb03aca97d87aafa9c3130593837a1c2
- https://git.kernel.org/stable/c/36c83c1329dd881f290f7df2feadfb9a21775108
- https://git.kernel.org/stable/c/5bbe266272d86c0657e8253600f3d5b74fb7b2ae
- https://git.kernel.org/stable/c/922bd3e498a4b8e445def6e6ffea2ad3682ad516
- https://git.kernel.org/stable/c/db5ba06e7af9325519a03e52fccf4a9e7c1fd9b2
- https://git.kernel.org/stable/c/f6a3860241fbb556fd72332fa31c5e787004413b
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddown_pow_of_two will cause undefined behaviour and should not be performed. This patch ensures that rounddown_pow_of_two is called on valid value.
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/186615f8855a0be4ee7d3fcd09a8ecc10e783b08
- https://git.kernel.org/stable/c/1a867d0d79a4a570a33f2f433919ad2bd7a27b67
- https://git.kernel.org/stable/c/2e4d5e8d86a969318340be95470bb76e52392082
- https://git.kernel.org/stable/c/5590cd04d6845c01a6bad985a491c58af6fb5389
- https://git.kernel.org/stable/c/a11d03d116eef138a7249202bd772c8e61915aec
- https://git.kernel.org/stable/c/a133e3caf844a3f56b6eef89ddaa66115874f6bd
- https://git.kernel.org/stable/c/d0559d07afabfddaaded6a61a16154486b956764
- https://git.kernel.org/stable/c/d652ef399f131fcd5f8f34266167449ee7c9e5b3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"
This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking
when enabling/disabling SR-IOV"), which causes a deadlock by recursively
taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of
pci_stop_and_remove_bus_device(). For example with the following sequence
of commands:
$ echo > /sys/bus/pci/devices//sriov_numvfs
$ echo 1 > /sys/bus/pci/devices//remove
A trimmed trace of the deadlock on a mlx5 device is as below:
zsh/5715 is trying to acquire lock:
000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140
but task is already holding lock:
000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80
...
Call Trace:
[<00000259778c4f90>] dump_stack_lvl+0xc0/0x110
[<00000259779c844e>] print_deadlock_bug+0x31e/0x330
[<00000259779c1908>] __lock_acquire+0x16c8/0x32f0
[<00000259779bffac>] lock_acquire+0x14c/0x350
[<00000259789643a6>] __mutex_lock_common+0xe6/0x1520
[<000002597896413c>] mutex_lock_nested+0x3c/0x50
[<00000259784a07e4>] sriov_disable+0x34/0x140
[<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core]
[<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core]
[<00000259784857fc>] pci_device_remove+0x3c/0xa0
[<000002597851012e>] device_release_driver_internal+0x18e/0x280
[<000002597847ae22>] pci_stop_bus_device+0x82/0xa0
[<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80
[<00000259784972c2>] remove_store+0x72/0x90
[<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200
[<0000025977d7241c>] vfs_write+0x24c/0x300
[<0000025977d72696>] ksys_write+0x86/0x110
[<000002597895b61c>] __do_syscall+0x14c/0x400
[<000002597896e0ee>] system_call+0x6e/0x90
This alone is not a complete fix as it restores the issue the cited commit
tried to solve. A new fix will be provided as a follow on.
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/0de341b2365bad430aade0853fe09c2cbe468f59
- https://git.kernel.org/stable/c/2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a
- https://git.kernel.org/stable/c/40f67686a5002c0c322fac918406bbc8d9c2ec2f
- https://git.kernel.org/stable/c/58677783c89681871077f50a7042b0c6380c4fd8
- https://git.kernel.org/stable/c/639265296fe6ee21b6f00e00ee2bab65f3b07252
- https://git.kernel.org/stable/c/83651d37474c762920e345a3a0828f975ca4d732
- https://git.kernel.org/stable/c/d47f27e145f8bd13f3c230da5e3af29225b4a2f7
- https://git.kernel.org/stable/c/f61cdd7e9b67bb8961b0a81bf294b78343e5db05
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer.
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/011ae5dd84dc9f05eb9b8e1adff44252ac776e7b
- https://git.kernel.org/stable/c/0f85a9655445e67bb0238cfc983d7c383b54938e
- https://git.kernel.org/stable/c/36bd7d5deef936c4e1e3cd341598140e5c14c1d3
- https://git.kernel.org/stable/c/6496fb830cbb741d831225cc4e7e5601c6e42970
- https://git.kernel.org/stable/c/84b932bc9899d43e5829e6cf088b72d73a922b2b
- https://git.kernel.org/stable/c/ba8d8429e5d6c36f9a654d2b96b9e043c43d92b4
- https://git.kernel.org/stable/c/d68994e37ac3b285692559776e0279a88a3b5f8d
- https://git.kernel.org/stable/c/d8a522085d09b30aba1016daf1dddac37c0f0285
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: HID: hid-pl: handle probe errors Errors in init must be reported back or we'll follow a NULL pointer the first time FF is used.
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/04e50f45b5175bb90a06f5003113cb4ed6ba44c2
- https://git.kernel.org/stable/c/1d46d07458dba369daf61fb643d40a62c8423d8e
- https://git.kernel.org/stable/c/3756a272d2cf356d2203da8474d173257f5f8521
- https://git.kernel.org/stable/c/449004434e1f55be85604b2645f2d07c4a92fe53
- https://git.kernel.org/stable/c/78df3de826668fe842c6061a91bc1ed68f493e80
- https://git.kernel.org/stable/c/7d2f4fdf134e7398847417b25743e1e04928c7d7
- https://git.kernel.org/stable/c/8a84149337eb5e716e6d59f48ff0374dae8d8b2b
- https://git.kernel.org/stable/c/926e6715b48b575ed7754bf163a67686bb2eb111
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: enable basic endpoint checking pegasus_probe() fills URBs with hardcoded endpoint pipes without verifying the endpoint descriptors: - usb_rcvbulkpipe(dev, 1) for RX data - usb_sndbulkpipe(dev, 2) for TX data - usb_rcvintpipe(dev, 3) for status interrupts A malformed USB device can present these endpoints with transfer types that differ from what the driver assumes. Add a pegasus_usb_ep enum for endpoint numbers, replacing magic constants throughout. Add usb_check_bulk_endpoints() and usb_check_int_endpoints() calls before any resource allocation to verify endpoint types before use, rejecting devices with mismatched descriptors at probe time, and avoid triggering assertion. Similar fix to - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking") - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")
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/229dc9b9db475ac900182bafe258943e0e054c6d
- https://git.kernel.org/stable/c/26b3ec62fa1a94ac801feca47f040fc729b3c174
- https://git.kernel.org/stable/c/2705709f6574a088aab246af72fc95f2fea51484
- https://git.kernel.org/stable/c/35854ed5c40b02f95824e44398f9d2ba33727203
- https://git.kernel.org/stable/c/3d7e6ce34f4fcc7083510c28b17a7c36462a25d4
- https://git.kernel.org/stable/c/67ba6b13dbcaf45681fb6758794c5ac5fa589a6c
- https://git.kernel.org/stable/c/a3e64e950a3981a8199de9798f6d21261b959171
- https://git.kernel.org/stable/c/d2e7c898cc02dfe42443489a67a45ed616cb76e9
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/24ce71852f2cee6581e2cbebc15489ed52bf63b7
- https://git.kernel.org/stable/c/38613c01f69e1e77e6b8acab1e8ac665d01c2f15
- https://git.kernel.org/stable/c/3eefc0c2b78444b64feeb3783c017d6adc3cd3ce
- https://git.kernel.org/stable/c/43f3b18679615a93bd848afde3602ba160637a46
- https://git.kernel.org/stable/c/6a8737afbccc340e718e0b22577312826390be8b
- https://git.kernel.org/stable/c/a396b3d73d51355e50acdb403ba9c4cae4c1174e
- https://git.kernel.org/stable/c/d08976725355b9d54d8332fce223fa281cc304a5
- https://git.kernel.org/stable/c/ef42a8766ff3fdf51cf72fb36d0859c09d134478
MEDIUM4.7
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: fix GPF in write_page caused by resize race A General Protection Fault occurs in write_page() during array resize: RIP: 0010:write_page+0x22b/0x3c0 [md_mod] This is a use-after-free race between bitmap_daemon_work() and __bitmap_resize(). The daemon iterates over `bitmap->storage.filemap` without locking, while the resize path frees that storage via md_bitmap_file_unmap(). `quiesce()` does not stop the md thread, allowing concurrent access to freed pages. Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.
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/140cc839fbeb1ddb33a8da8811b716d88d3905b7
- https://git.kernel.org/stable/c/46ef85f854dfa9d5226b3c1c46493d79556c9589
- https://git.kernel.org/stable/c/5f73c8b33df9a605a591eab72d43a969600c1f8c
- https://git.kernel.org/stable/c/9a6f8cd28bb9bb6ed86a6df19331fb08016dee7f
- https://git.kernel.org/stable/c/a437e3bf30e32846079e470c1ba5ee790bccdf89
- https://git.kernel.org/stable/c/d3af62411e19752c663fe4f424dbf49d95a4cc7c
- https://git.kernel.org/stable/c/d92b8fac294b5f915c50e65ce4ae2262e53614ec
- https://git.kernel.org/stable/c/ebcacc7ca22d5e8a03a970f0621ae1d1356b9ae8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix reflink preserve cleanup issue commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error") doesn't handle all cases and the cleanup job for preserved xattr entries still has bug: - the 'last' pointer should be shifted by one unit after cleanup an array entry. - current code logic doesn't cleanup the first entry when xh_count is 1. Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.
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/02acc9f72365e50eb45a56b7dacb9114ca3b503c
- https://git.kernel.org/stable/c/2f4daccd9d9b8b2952df7878df8c2e8ba6439398
- https://git.kernel.org/stable/c/3bdc3766aafb052aef4baadef455a84c1c0a059d
- https://git.kernel.org/stable/c/5138c936c2c82c9be8883921854bc6f7e1177d8c
- https://git.kernel.org/stable/c/8ff329353134280b203cb2bce95311cb8f7cbd8a
- https://git.kernel.org/stable/c/b2952dbeac2c3c527cb0519d5ffaeb95b062466a
- https://git.kernel.org/stable/c/bb273b68c1719c2925e05557f7e7099edb066680
- https://git.kernel.org/stable/c/c44d86ca949cb1e5566ad14510cc26fa1a17e2d8
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't dump the entire memory region The current logic at cper_print_fw_err() doesn't check if the error record length is big enough to handle offset. On a bad firmware, if the ofset is above the actual record, length -= offset will underflow, making it dump the entire memory. The end result can be: - the logic taking a lot of time dumping large regions of memory; - data disclosure due to the memory dumps; - an OOPS, if it tries to dump an unmapped memory region. Fix it by checking if the section length is too small before doing a hex dump. [ rjw: Subject tweaks ]
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/02de64ab54b4bb0f1b21bb324aeff3b08612be33
- https://git.kernel.org/stable/c/0e09b522f2622841389c3b2f9ac4969e35c0809d
- https://git.kernel.org/stable/c/54e131db4cdffd946db890ff33ff2647053fd4f6
- https://git.kernel.org/stable/c/55cc6fe5716f678f06bcb95140882dfa684464ec
- https://git.kernel.org/stable/c/5a9b1dda8481b82851a655c3bcc5b44879b95334
- https://git.kernel.org/stable/c/64ae5aaa7ac93c83da456039e8ec747bfa8a7cff
- https://git.kernel.org/stable/c/7780c0bad2a3a70a8c0113a33c02f4151d901eb3
- https://git.kernel.org/stable/c/a8419f5f2c5f2d80848ddabb2b95cf0da84a5f91
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration. The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB: kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); } kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done } kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active } This triggers the WARN in usb_submit_urb(): "URB submitted while active" This is a similar class of bug fixed in rtl8150 by - commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast"). Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.
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/443a830b1dc4f85c7560da59d4494b629feee215
- https://git.kernel.org/stable/c/586318c2730433184c6f1d21183e346ddf25e81d
- https://git.kernel.org/stable/c/64868f5ecadeb359a49bc4485bfa7c497047f13a
- https://git.kernel.org/stable/c/8367c0e90126426e60581e4c07e1ec4411a0f843
- https://git.kernel.org/stable/c/9c79b839a63980c7da7ec5db895198045e154112
- https://git.kernel.org/stable/c/a2cd4b4db315a845a5603d08c9d03b11ddfc799d
- https://git.kernel.org/stable/c/ef9b10a020503888eb6c8ed85a3d901a624ede4c
- https://git.kernel.org/stable/c/fc393af769af845d9985e2845e49553d8f015a64
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix a resource leak in cx25821_dev_setup() Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources().
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/071bfc6e723aabbbf08f0d439fb913cd01eb8de2
- https://git.kernel.org/stable/c/4010e596d23cda6de65acb14f7fd4ce8289f1d49
- https://git.kernel.org/stable/c/68cd8ac994cac38a305200f638b30e13c690753b
- https://git.kernel.org/stable/c/80ce3797dc99dae4ce8b939626b891c9eb85139f
- https://git.kernel.org/stable/c/9f1c926248bde95a77ca104ab525467470607836
- https://git.kernel.org/stable/c/b7210170b10e2d17f7a4f6b9d39cc092442db860
- https://git.kernel.org/stable/c/e220ec4c4596d634685b8a08d79ad876a720b466
- https://git.kernel.org/stable/c/f7759eb6738ee9fc296f6ab1705c6809947976f3
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: rnbd-srv: Zero the rsp buffer before using it Before using the data buffer to send back the response message, zero it completely. This prevents any stray bytes to be picked up by the client side when there the message is exchanged between different protocol versions.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NСсылки
- https://git.kernel.org/stable/c/30868a6a5238849d554295aff3ce61d242d7fad8
- https://git.kernel.org/stable/c/69d26698e4fd44935510553809007151b2fe4db5
- https://git.kernel.org/stable/c/7aac0a30dcf41cdb510526740d9a2ab1520c5d98
- https://git.kernel.org/stable/c/852475278ca5e96e0c0275950e1a84203e602b33
- https://git.kernel.org/stable/c/b646e54d23b9b592d612a2036aab14e0f6c14206
- https://git.kernel.org/stable/c/c94ede3c436dfbd9cedd9cb69f604f6fc901b6a2
- https://git.kernel.org/stable/c/e2cacec7d4291300a282feb3af8eba57b93b15aa
- https://git.kernel.org/stable/c/e4272754063d52c9ad0169865add8816ba696471
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: xfs: delete attr leaf freemap entries when empty Back in commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow"), Brian Foster observed that it's possible for a small freemap at the end of the end of the xattr entries array to experience a size underflow when subtracting the space consumed by an expansion of the entries array. There are only three freemap entries, which means that it is not a complete index of all free space in the leaf block. This code can leave behind a zero-length freemap entry with a nonzero base. Subsequent setxattr operations can increase the base up to the point that it overlaps with another freemap entry. This isn't in and of itself a problem because the code in _leaf_add that finds free space ignores any freemap entry with zero size. However, there's another bug in the freemap update code in _leaf_add, which is that it fails to update a freemap entry that begins midway through the xattr entry that was just appended to the array. That can result in the freemap containing two entries with the same base but different sizes (0 for the "pushed-up" entry, nonzero for the entry that's actually tracking free space). A subsequent _leaf_add can then allocate xattr namevalue entries on top of the entries array, leading to data loss. But fixing that is for later. For now, eliminate the possibility of confusion by zeroing out the base of any freemap entry that has zero size. Because the freemap is not intended to be a complete index of free space, a subsequent failure to find any free space for a new xattr will trigger block compaction, which regenerates the freemap. It looks like this bug has been in the codebase for quite a long time.
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/479b05fc3ee272090f671b06a41f3da8aa78eece
- https://git.kernel.org/stable/c/6f13c1d2a6271c2e73226864a0e83de2770b6f34
- https://git.kernel.org/stable/c/a631899025d47ea1aa6464d76db5b4d3b6d196fd
- https://git.kernel.org/stable/c/aa9083d97e2157da3c6fb45ddb1a97af7f188f7f
- https://git.kernel.org/stable/c/e1b8c6452ee99a30e188a88f3f3f804fb1c6004a
- https://git.kernel.org/stable/c/f31a8334e1c54b126fcecf98645a49b6bc5ad399
- https://git.kernel.org/stable/c/f3c0d1fc1eadbb4adbee5ab7757d41d35f48325b
- https://git.kernel.org/stable/c/ffaf5c99d0f862db021fb1af8b813c1416b1beb2
HIGH8.2
In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_tcpmss: check remaining length before reading optlen Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).
CVSS 3.xВЫСОКАЯ 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:HСсылки
- https://git.kernel.org/stable/c/07a9b32eaae792ff7d0fcac14d8920c937c0a9c3
- https://git.kernel.org/stable/c/5e13d0a37666955b6cfddc0f73cb40ed645b8a05
- https://git.kernel.org/stable/c/735ee8582da3d239eb0c7a53adca61b79fb228b3
- https://git.kernel.org/stable/c/8b300f726640c48c3edfe9c453334dd801f4b74e
- https://git.kernel.org/stable/c/cd5beda7e0e32865e214f28034bb92c1cecff885
- https://git.kernel.org/stable/c/eaedc0bc18be46fe7f58170e967959a932c4f824
- https://git.kernel.org/stable/c/f6c412dcfd76b0516d51aa847d8f4c7b70381b09
- https://git.kernel.org/stable/c/f895191dc32c53eaf443b6443fe40945b2f92287
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved:
net: consume xmit errors of GSO frames
udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests
currently in NIPA. They fail in the same exact way, TCP GRO
test stalls occasionally and the test gets killed after 10min.
These tests use veth to simulate GRO. They attach a trivial
("return XDP_PASS;") XDP program to the veth to force TSO off
and NAPI on.
Digging into the failure mode we can see that the connection
is completely stuck after a burst of drops. The sender's snd_nxt
is at sequence number N [1], but the receiver claims to have
received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle
is that senders rtx queue is not empty (let's say the block in
the rtx queue is at sequence number N - 4 * MSS [3]).
In this state, sender sends a retransmission from the rtx queue
with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].
Receiver sees it and responds with an ACK all the way up to
N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA
because it has no recollection of ever sending data that far out [1].
And we are stuck.
The root cause is the mess of the xmit return codes. veth returns
an error when it can't xmit a frame. We end up with a loss event
like this:
-------------------------------------------------
| GSO super frame 1 | GSO super frame 2 |
|-----------------------------------------------|
| seg | seg | seg | seg | seg | seg | seg | seg |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
-------------------------------------------------
x ok ok | ok ok ok
\\
snd_nxt
"x" means packet lost by veth, and "ok" means it went thru.
Since veth has TSO disabled in this test it sees individual segments.
Segment 1 is on the retransmit queue and will be resent.
So why did the sender not advance snd_nxt even tho it clearly did
send up to seg 8? tcp_write_xmit() interprets the return code
from the core to mean that data has not been sent at all. Since
TCP deals with GSO super frames, not individual segment the crux
of the problem is that loss of a single segment can be interpreted
as loss of all. TCP only sees the last return code for the last
segment of the GSO frame (in <> brackets in the diagram above).
Of course for the problem to occur we need a setup or a device
without a Qdisc. Otherwise Qdisc layer disconnects the protocol
layer from the device errors completely.
We have multiple ways to fix this.
1) make veth not return an error when it lost a packet.
While this is what I think we did in the past, the issue keeps
reappearing and it's annoying to debug. The game of whack
a mole is not great.
2) fix the damn return codes
We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the
documentation, so maybe we should make the return code from
ndo_start_xmit() a boolean. I like that the most, but perhaps
some ancient, not-really-networking protocol would suffer.
3) make TCP ignore the errors
It is not entirely clear to me what benefit TCP gets from
interpreting the result of ip_queue_xmit()? Specifically once
the connection is established and we're pushing data - packet
loss is just packet loss?
4) this fix
Ignore the rc in the Qdisc-less+GSO case, since it's unreliable.
We already always return OK in the TCQ_F_CAN_BYPASS case.
In the Qdisc-less case let's be a bit more conservative and only
mask the GSO errors. This path is taken by non-IP-"networks"
like CAN, MCTP etc, so we could regress some ancient thing.
This is the simplest, but also maybe the hackiest fix?
Similar fix has been proposed by Eric in the past but never committed
because original reporter was working with an OOT driver and wasn't
providing feedback (see Link).
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/0c9de092ef8c50a7ee9612811566f0aa81d8d7b6
- https://git.kernel.org/stable/c/4cb163e9efcac4cd35c3043e097f25081a5c015c
- https://git.kernel.org/stable/c/56bd32c0edca34041a5c215887fcf562fae2e2db
- https://git.kernel.org/stable/c/7aa767d0d3d04e50ae94e770db7db8197f666970
- https://git.kernel.org/stable/c/9ac6aebef4b4bfc5ed408b0b65645981574bc780
- https://git.kernel.org/stable/c/ae3f627b45fbc3c776a4e484696f3cad7cbb4eca
- https://git.kernel.org/stable/c/c86901d22c89a6bf4e2f013e948aaabc60869893
- https://git.kernel.org/stable/c/ea5d7787635e26ec1194ec7eec0e8e5ae3bd10a5
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: soc: ti: pruss: Fix double free in pruss_clk_mux_setup() In the pruss_clk_mux_setup(), the devm_add_action_or_reset() indirectly calls pruss_of_free_clk_provider(), which calls of_node_put(clk_mux_np) on the error path. However, after the devm_add_action_or_reset() returns, the of_node_put(clk_mux_np) is called again, causing a double free. Fix by returning directly, to avoid the duplicate of_node_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/04dbbb18cc9c8795c9ff47d8994bc03ebfef9d68
- https://git.kernel.org/stable/c/24c40076e3bc3d73c839c886d6bda1da6c4d9b93
- https://git.kernel.org/stable/c/69aa67c1e22d13e9aad4b08c86304ad8e743dcab
- https://git.kernel.org/stable/c/80db65d4acfb9ff12d00172aed39ea8b98261aad
- https://git.kernel.org/stable/c/818cf66d91c8ef09b01664a12d5f4ea786d64396
- https://git.kernel.org/stable/c/b7db9953c2f8da37de498198623b05b46f8e2ca0
- https://git.kernel.org/stable/c/dbda01bf2dfe5af33163e1e5fca1b82b619c2803
- https://git.kernel.org/stable/c/e113339cc7d23be4948891f3a702e9dce5b47035
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fbdev: vt8500lcdfb: fix missing dma_free_coherent() fbi->fb.screen_buffer is allocated with dma_alloc_coherent() but is not freed if the error path is reached.
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/2cd2f988a8bd2da227f5c3cfa0cbf3a9a287ddc3
- https://git.kernel.org/stable/c/40c1ff25025150ff6d7ec7ad441fcfd6d070ee76
- https://git.kernel.org/stable/c/778f31be5b8c10024db23fdd8a05f68a02311008
- https://git.kernel.org/stable/c/88b3b9924337336a31cefbe99a22ed09401be74a
- https://git.kernel.org/stable/c/9a9bc60ed372aaae9784ff8ad8e5f496ff15fd31
- https://git.kernel.org/stable/c/9c3873cccb3fab54cde0605ae7093d332c99073e
- https://git.kernel.org/stable/c/e8c5d5f6cd66e032f9aefdcc21b0c34761aef78a
- https://git.kernel.org/stable/c/f47d5b9e8aa6178a0aaf225119ad1ec7d3f49876
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: atm: fore200e: fix use-after-free in tasklets during device removal When the PCA-200E or SBA-200E adapter is being detached, the fore200e is deallocated. However, the tx_tasklet or rx_tasklet may still be running or pending, leading to use-after-free bug when the already freed fore200e is accessed again in fore200e_tx_tasklet() or fore200e_rx_tasklet(). One of the race conditions can occur as follows: CPU 0 (cleanup) | CPU 1 (tasklet) fore200e_pca_remove_one() | fore200e_interrupt() fore200e_shutdown() | tasklet_schedule() kfree(fore200e) | fore200e_tx_tasklet() | fore200e-> // UAF Fix this by ensuring tx_tasklet or rx_tasklet is properly canceled before the fore200e is released. Add tasklet_kill() in fore200e_shutdown() to synchronize with any pending or running tasklets. Moreover, since fore200e_reset() could prevent further interrupts or data transfers, the tasklet_kill() should be placed after fore200e_reset() to prevent the tasklet from being rescheduled in fore200e_interrupt(). Finally, it only needs to do tasklet_kill() when the fore200e state is greater than or equal to FORE200E_STATE_IRQ, since tasklets are uninitialized in earlier states. In a word, the tasklet_kill() should be placed in the FORE200E_STATE_IRQ branch within the switch...case structure. This bug was identified through static analysis.
CVSS 3.xВЫСОКАЯ 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/5189368f10903956be05062d160b2804bf5e5016
- https://git.kernel.org/stable/c/73fbc5d1a9ccb626937500bbd67136f077d8237b
- https://git.kernel.org/stable/c/8930878101cd40063888a68af73b1b0f8b6c79bc
- https://git.kernel.org/stable/c/91f25749aaf57c47ae1e12478144e6ea8c8562f2
- https://git.kernel.org/stable/c/97900f512252a59f23d6ce4ab215cc88fed66e68
- https://git.kernel.org/stable/c/aba0b4bc09376dfc3d53c826514fe38fc8337f52
- https://git.kernel.org/stable/c/e075ec9b08f862dade8011481058f7eb5f716c57
- https://git.kernel.org/stable/c/e4ff4e3ffcf9d5aad380cdd1d8cdc008bb34f97d
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. This allows unprivileged userspace to trigger an out-of bounds kernel memory write by passing a small buffer, leading to potential privilege escalation.
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/3e04bc310d80b46eaf481f1fefcbcb37a187412d
- https://git.kernel.org/stable/c/4857c37c7ba9aa38b9a4c694e8bd8d0091c87940
- https://git.kernel.org/stable/c/4e72f419e4ed44cb3b60506752d8688c20a60a9b
- https://git.kernel.org/stable/c/75fb57efdd7863fffbc39db23e9cad7aafda26ed
- https://git.kernel.org/stable/c/8a70a26c9f34baea6c3199a9862ddaff4554a96d
- https://git.kernel.org/stable/c/b4034442cb090e4a980bdcc1540948606cbc951b
- https://git.kernel.org/stable/c/bfcd6b53e1f4feb182952f4ff9a137c36ceaf20b
- https://git.kernel.org/stable/c/de8d7a25cd2eb5875b1d8d4fbc7fe4b4138b781f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix error handling in probe function Add mtk_mdp_unregister_m2m_device() on the error handling path to prevent resource leak. Add check for the return value of vpu_get_plat_device() to prevent null pointer dereference. And vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.
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/0bc43eaf021347f8d5aba87712c36b799695eec6
- https://git.kernel.org/stable/c/12cafc15d24611bfb43c82877b1bbb7454a85d5a
- https://git.kernel.org/stable/c/2e8f53a7382943411557e370f1a4f3946624a30e
- https://git.kernel.org/stable/c/8a8a3232abac5b972058a5f2cb3e33199d2a8648
- https://git.kernel.org/stable/c/9d7962d5c81d6cf3f8dbdb5c71c57600bac5772b
- https://git.kernel.org/stable/c/9d9c67976eda502edc6b3a148a1c5b6a18b69a98
- https://git.kernel.org/stable/c/b3fc99fe5b25613dd61c57bc70b8479adff4f60d
- https://git.kernel.org/stable/c/c8737d33d4e8ffae87e5d5edac17f8a705235cc2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: minix: Add required sanity checking to minix_check_superblock() The fs/minix implementation of the minix filesystem does not currently support any other value for s_log_zone_size than 0. This is also the only value supported in util-linux; see mkfs.minix.c line 511. In addition, this patch adds some sanity checking for the other minix superblock fields, and moves the minix_blocks_needed() checks for the zmap and imap also to minix_check_super_block(). This also closes a related syzbot bug report.
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/1efc128ee4adbc23e082715425ff895449d233bc
- https://git.kernel.org/stable/c/2bb588cede1c1969e49c0a2822c8cb8b346b7682
- https://git.kernel.org/stable/c/31fefc18096cdc5549cfa54964d90e0b3229aedc
- https://git.kernel.org/stable/c/66c7c239c65341f99ae388d4d53dc9df2bcb9925
- https://git.kernel.org/stable/c/8c97a6ddc95690a938ded44b4e3202f03f15078c
- https://git.kernel.org/stable/c/a051ecf5c5b0387840dc210413ed3bc7fbdaa69c
- https://git.kernel.org/stable/c/d791c544efd6b9c944b43cf7f502e5bcb02fb941
- https://git.kernel.org/stable/c/f57ccd4657c7f082dc47e5b9e18a883bb5f9118f
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_slot_trylock() error handling Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]
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/0425aaf20b407d2f2cf3bf469808e4a35f9abb8b
- https://git.kernel.org/stable/c/8b08ea9690b212b7bf7f12414039259cf34b1aa0
- https://git.kernel.org/stable/c/9368d1ee62829b08aa31836b3ca003803caf0b72
- https://git.kernel.org/stable/c/943ed56606a7ab2fe5a99cad572dd17d484310c7
- https://git.kernel.org/stable/c/a19b61fdb958ffadbba85b43c991eb9fc70c1c1c
- https://git.kernel.org/stable/c/bd435f4b738130d732ef64e0e57e45185f77165d
- https://git.kernel.org/stable/c/ebb27b7399ab8b9eb1f792b329aa5f6250c590d4
- https://git.kernel.org/stable/c/fbe06a3058114bf95a17a4941b205f4b321c6f0a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9903: Fix potential memory leak in tw9903_probe() In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error 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/32f0493506313775d3bd448de34762b6538da6bd
- https://git.kernel.org/stable/c/92537a15780b6d0281fd8286f93fbc3652e35f48
- https://git.kernel.org/stable/c/9cb9eca33d20316ed3c7a938793b8735ac3e128b
- https://git.kernel.org/stable/c/9cea16fea47e5553f51d10957677ff735b1eff03
- https://git.kernel.org/stable/c/a114918270f0d95c607d69b03a244e6afe54813f
- https://git.kernel.org/stable/c/add02a3fb1fd71b004f0ed824cbac00f850de558
- https://git.kernel.org/stable/c/cc7aeed33e4f55c76f35f0fca73e4dfe12a63a3a
- https://git.kernel.org/stable/c/e54aa17c968c4de2c5f7b7ea390c63d33c07513b
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix URB leak in pvr2_send_request_ex When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.
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/2011929f0e4cf6a0a34dd6205911b12276904453
- https://git.kernel.org/stable/c/4ba5c7a1aade7090172cbffd4d120bf4cf5ccbde
- https://git.kernel.org/stable/c/58dd722b6c3debcddb4684fb256c90fee7f063e5
- https://git.kernel.org/stable/c/5f3ac816861c3b8a5d1a3645b17dc3a99d668d94
- https://git.kernel.org/stable/c/77a63f8efc434ddb04667ed632aade58301a2f13
- https://git.kernel.org/stable/c/a8333c8262aed2aedf608c18edd39cf5342680a7
- https://git.kernel.org/stable/c/cf459d6ffa5e150ef3744b897f936ff24b52bd15
- https://git.kernel.org/stable/c/da524c939b1e5ba17f10db4bde4bdaf569ffcda6
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net/rds: No shortcut out of RDS_CONN_ERROR RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again."
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/19e384a7d00d888303a8285977cdf1970c6cccd6
- https://git.kernel.org/stable/c/81248b1eb3c5954cc1fc7b33b7c03e34d20cb8c8
- https://git.kernel.org/stable/c/899ef00963ce76f9fc421a7d02335fe4ead6389b
- https://git.kernel.org/stable/c/9bcd7c00691a2db9745817d5ea79262a503b135c
- https://git.kernel.org/stable/c/9ff599a9be784a808c36765086e3db2144aa3b66
- https://git.kernel.org/stable/c/a179ac7be8f5a650d0068040705f4cddd6ca369c
- https://git.kernel.org/stable/c/ad22d24be635c6beab6a1fdd3f8b1f3c478d15da
- https://git.kernel.org/stable/c/f0f729bdffb08af32e0f54521b81b8a9e0321f16
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: clocksource/drivers/sh_tmu: Always leave device running after probe The TMU device can be used as both a clocksource and a clockevent provider. The driver tries to be smart and power itself on and off, as well as enabling and disabling its clock when it's not in operation. This behavior is slightly altered if the TMU is used as an early platform device in which case the device is left powered on after probe, but the clock is still enabled and disabled at runtime. This has worked for a long time, but recent improvements in PREEMPT_RT and PROVE_LOCKING have highlighted an issue. As the TMU registers itself as a clockevent provider, clockevents_register_device(), it needs to use raw spinlocks internally as this is the context of which the clockevent framework interacts with the TMU driver. However in the context of holding a raw spinlock the TMU driver can't really manage its power state or clock with calls to pm_runtime_*() and clk_*() as these calls end up in other platform drivers using regular spinlocks to control power and clocks. This mix of spinlock contexts trips a lockdep warning. ============================= [ BUG: Invalid wait context ] 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted ----------------------------- swapper/0/0 is trying to lock: ffff000008c9e180 (&dev->power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88 other info that might help us debug this: context-{5:5} 1 lock held by swapper/0/0: ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0 #0: ffff8000817ec298 ccree e6601000.crypto: ARM ccree device initialized (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8 stack backtrace: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) Call trace: show_stack+0x14/0x1c (C) dump_stack_lvl+0x6c/0x90 dump_stack+0x14/0x1c __lock_acquire+0x904/0x1584 lock_acquire+0x220/0x34c _raw_spin_lock_irqsave+0x58/0x80 __pm_runtime_resume+0x38/0x88 sh_tmu_clock_event_set_oneshot+0x84/0xd4 clockevents_switch_state+0xfc/0x13c tick_broadcast_set_event+0x30/0xa4 __tick_broadcast_oneshot_control+0x1e0/0x3a8 tick_broadcast_oneshot_control+0x30/0x40 cpuidle_enter_state+0x40c/0x680 cpuidle_enter+0x30/0x40 do_idle+0x1f4/0x280 cpu_startup_entry+0x34/0x40 kernel_init+0x0/0x130 do_one_initcall+0x0/0x230 __primary_switched+0x88/0x90 For non-PREEMPT_RT builds this is not really an issue, but for PREEMPT_RT builds where normal spinlocks can sleep this might be an issue. Be cautious and always leave the power and clock running after probe.
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/016476afef993d1201a19decc9b5b2ea1e6620f2
- https://git.kernel.org/stable/c/0e513cc6b9cea190fe342cc222b1054e7e8acfc8
- https://git.kernel.org/stable/c/6f113ab549b864c1bc57d4f89846ee335394089a
- https://git.kernel.org/stable/c/79d650695773f03de36b99228a090d33d1c18264
- https://git.kernel.org/stable/c/88c76792180dffd83f1c5b9dc8fdaeb145cb94e0
- https://git.kernel.org/stable/c/b1278972b08e480990e2789bdc6a7c918bc349be
- https://git.kernel.org/stable/c/bc59d5f3afe41fec5d673c27c703b761ae578d28
- https://git.kernel.org/stable/c/f0b31247e7d67a943b3a09d3cef7c0ae788d88e6
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: net/rds: Clear reconnect pending bit When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever.
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/14eae5564053ac3973b9369dc674638f22f4765e
- https://git.kernel.org/stable/c/391200c274e90c34071b909ba12e3390b81b767f
- https://git.kernel.org/stable/c/3cf001aff71b1db1b4732a5381b012a114720664
- https://git.kernel.org/stable/c/597c46a42930c963f448720aaf5001dd4ed98af4
- https://git.kernel.org/stable/c/60b347333ec259ac7352f62cbbc365b04c065ff8
- https://git.kernel.org/stable/c/b89fc7c2523b2b0750d91840f4e52521270d70ed
- https://git.kernel.org/stable/c/ba2e3472022f44baddf000621fed150d7a599ea3
- https://git.kernel.org/stable/c/bcf034fa5f66b6a3e787f765a917934a2045cf7a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: radio-keene: fix memory leak in error path Fix a memory leak in usb_keene_probe(). The v4l2 control handler is initialized and controls are added, but if v4l2_device_register() or video_register_device() fails afterward, the handler was never freed, leaking memory. Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure the control handler is properly freed for all error paths after it is initialized.
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/1d8558a232ecb187e8e0328d6347a125f437a0fc
- https://git.kernel.org/stable/c/242b0aabb1866024a7995a767ac330c158b39aa4
- https://git.kernel.org/stable/c/27c508f61963013fdf29097578284099ee7a85a4
- https://git.kernel.org/stable/c/2fe28a63d598235595a9601e0d8fdc7c8f4fd575
- https://git.kernel.org/stable/c/7fa9754f48cb8eefa566156be341e63d313247e5
- https://git.kernel.org/stable/c/ad85bb5623079a35bd400f51de2e2fbc2170bdb2
- https://git.kernel.org/stable/c/b8bf939d77c0cd01118e953bbf554e0fa15e9006
- https://git.kernel.org/stable/c/de204d87e7d61859937272fe30cbdd46a4cfb10a
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved:
net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets
When the FarSync T-series card is being detached, the fst_card_info is
deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task
may still be running or pending, leading to use-after-free bugs when the
already freed fst_card_info is accessed in fst_process_tx_work_q() or
fst_process_int_work_q().
A typical race condition is depicted below:
CPU 0 (cleanup) | CPU 1 (tasklet)
| fst_start_xmit()
fst_remove_one() | tasklet_schedule()
unregister_hdlc_device()|
| fst_process_tx_work_q() //handler
kfree(card) //free | do_bottom_half_tx()
| card-> //use
The following KASAN trace was captured:
==================================================================
BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00
Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32
...
Call Trace:
dump_stack_lvl+0x55/0x70
print_report+0xcb/0x5d0
? do_bottom_half_tx+0xb88/0xd00
kasan_report+0xb8/0xf0
? do_bottom_half_tx+0xb88/0xd00
do_bottom_half_tx+0xb88/0xd00
? _raw_spin_lock_irqsave+0x85/0xe0
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? __pfx___hrtimer_run_queues+0x10/0x10
fst_process_tx_work_q+0x67/0x90
tasklet_action_common+0x1fa/0x720
? hrtimer_interrupt+0x31f/0x780
handle_softirqs+0x176/0x530
__irq_exit_rcu+0xab/0xe0
sysvec_apic_timer_interrupt+0x70/0x80
...
Allocated by task 41 on cpu 3 at 72.330843s:
kasan_save_stack+0x24/0x50
kasan_save_track+0x17/0x60
__kasan_kmalloc+0x7f/0x90
fst_add_one+0x1a5/0x1cd0
local_pci_probe+0xdd/0x190
pci_device_probe+0x341/0x480
really_probe+0x1c6/0x6a0
__driver_probe_device+0x248/0x310
driver_probe_device+0x48/0x210
__device_attach_driver+0x160/0x320
bus_for_each_drv+0x101/0x190
__device_attach+0x198/0x3a0
device_initial_probe+0x78/0xa0
pci_bus_add_device+0x81/0xc0
pci_bus_add_devices+0x7e/0x190
enable_slot+0x9b9/0x1130
acpiphp_check_bridge.part.0+0x2e1/0x460
acpiphp_hotplug_notify+0x36c/0x3c0
acpi_device_hotplug+0x203/0xb10
acpi_hotplug_work_fn+0x59/0x80
...
Freed by task 41 on cpu 1 at 75.138639s:
kasan_save_stack+0x24/0x50
kasan_save_track+0x17/0x60
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x135/0x410
fst_remove_one+0x2ca/0x540
pci_device_remove+0xa6/0x1d0
device_release_driver_internal+0x364/0x530
pci_stop_bus_device+0x105/0x150
pci_stop_and_remove_bus_device+0xd/0x20
disable_slot+0x116/0x260
acpiphp_disable_and_eject_slot+0x4b/0x190
acpiphp_hotplug_notify+0x230/0x3c0
acpi_device_hotplug+0x203/0xb10
acpi_hotplug_work_fn+0x59/0x80
...
The buggy address belongs to the object at ffff88800aad1000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 28 bytes inside of
freed 1024-byte region
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x100000000000040(head|node=0|zone=1)
page_type: f5(slab)
raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000
head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88800aad1000: fa fb
---truncated---
CVSS 3.xВЫСОКАЯ 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/04edfdfdfcdefc02408ab670607261b0a0a9a02e
- https://git.kernel.org/stable/c/086131807d119238cd464e5b0845e48d938dfd79
- https://git.kernel.org/stable/c/200bdb8d367ca9b478f9c56ebe56411604d55c81
- https://git.kernel.org/stable/c/21d341fe514fd07e345ed264c9eee21cb2061ca2
- https://git.kernel.org/stable/c/337d7b4112a47984ee319171b75b73bab47e7924
- https://git.kernel.org/stable/c/ae894e47e1cd5a6bf8a0423d888c45df8b2b02dc
- https://git.kernel.org/stable/c/bae8a5d2e759da2e0cba33ab2080deee96a09373
- https://git.kernel.org/stable/c/cac048ebfbb92d91d719f74b59177cb70a7633b8
HIGH8.2
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: fix OOB read in decode_choice() In decode_choice(), the boundary check before get_len() uses the variable `len`, which is still 0 from its initialization at the top of the function: unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTE_ALIGN(bs); if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */ return H323_ERROR_BOUND; len = get_len(bs); /* OOB read */ When the bitstream is exactly consumed (bs->cur == bs->end), the check nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent get_len() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well. This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nf_conntrack_h323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer. Fix this by checking for 2 bytes (the maximum that get_len() may read) instead of the uninitialized `len`. This matches the pattern used at every other get_len() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().
CVSS 3.xВЫСОКАЯ 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:HСсылки
- https://git.kernel.org/stable/c/2a3aac4205e7d2f1aca2e3827de8cdd517d36c4a
- https://git.kernel.org/stable/c/35f1943d242e1b9f0b6e91c0c93bfb293a9f8224
- https://git.kernel.org/stable/c/53d32735d77ab56cc3fc7bd53a7d099418f19be1
- https://git.kernel.org/stable/c/7ef82863d42261817a6394c6c881bd6757a70f16
- https://git.kernel.org/stable/c/81f2fc5b0d0cf4696146f00f837596d10b92dead
- https://git.kernel.org/stable/c/baed0d9ba91d4f390da12d5039128ee897253d60
- https://git.kernel.org/stable/c/bcb50aa0b8f2b74a9fe5a1c7bee6f2657a288041
- https://git.kernel.org/stable/c/f0a83d0a4b7c127d32ac06d607a9214937716129
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0
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/549c6db503dbb85dbff4840830971853feac6625
- https://git.kernel.org/stable/c/6404898af86d986db1dbbe06177c143e40652e49
- https://git.kernel.org/stable/c/796e77c14c4c1e2cd36473760fb6cc66c695eb47
- https://git.kernel.org/stable/c/7b4d0fab3ff2c00c6d34e1952c9df5129a826aee
- https://git.kernel.org/stable/c/a205740a7231e967ac77cb731171642901c327af
- https://git.kernel.org/stable/c/ac2d898da5095d46bd1ff8585fdd753d58ad91e7
- https://git.kernel.org/stable/c/bc847787233277a337788568e90a6ee1557595eb
- https://git.kernel.org/stable/c/fd4a4d0711f48a99b25bcd45e00eef8339eff82d
HIGH7.1
In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS, This patch protects against invalid index out of bounds access to mw_sizes When invalid access print message to user that configuration is not valid.
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/0e930420945106151c6eb3d7837b4e6154e9b144
- https://git.kernel.org/stable/c/2346856b74823a2a78109002e479a3d02526a9ce
- https://git.kernel.org/stable/c/348e1ac9ad983ed7e62de14e1daf47f1695a4ce9
- https://git.kernel.org/stable/c/47ce292dd45dc689747c40603222691638919189
- https://git.kernel.org/stable/c/740945de896021b9a859e71f38f6aea72a6393cf
- https://git.kernel.org/stable/c/85c9daa1f8319bbb3dfee71dc6a2f969cd3b4c92
- https://git.kernel.org/stable/c/c8ba7ad2cc1c7b90570aa347b8ebbe279f1eface
- https://git.kernel.org/stable/c/ee02c4f980c91820845dd8e469ec7dc670ab6d9d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: soc: ti: k3-socinfo: Fix regmap leak on probe failure The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on 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/458136527fe127fd051c1c9537f4540849780d70
- https://git.kernel.org/stable/c/ab1ac24c407e4df326d7154a4deadd444e9209d9
- https://git.kernel.org/stable/c/b1006b5892ec8a95d039a89b47e6fd69cf607405
- https://git.kernel.org/stable/c/bbaa9e615608c204d384a7d4b1a434580a142d4c
- https://git.kernel.org/stable/c/c933138d45176780fabbbe7da263e04d5b3e525d
- https://git.kernel.org/stable/c/c97c21d342838b2a7787b0f1d6ad417e85c906f6
- https://git.kernel.org/stable/c/d451bf970a0c54b586f8b3161261bdf35d463c99
- https://git.kernel.org/stable/c/eaa16059f9af26d8b8a6f3e887649f58e8ca96c9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: i2c/tw9906: Fix potential memory leak in tw9906_probe() In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error 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/0c33338514d8246280533a77091e6b6ee548c606
- https://git.kernel.org/stable/c/377a7756914364d72550fc86ca0f404ef1d96141
- https://git.kernel.org/stable/c/59420d5d9c46b084e21f9ea6ce79fc79ae9e414c
- https://git.kernel.org/stable/c/9548a8bbf511a252a9848f96220c6b95c9a3b918
- https://git.kernel.org/stable/c/cad237b6c875fbee5d353a2b289e98d240d17ec8
- https://git.kernel.org/stable/c/ccb92def042a3636ed47f25a30bd553788e5191e
- https://git.kernel.org/stable/c/e9a490937942f18205dac7b6b192975ef1369ae1
- https://git.kernel.org/stable/c/fb09d8b80046216646f1a344410cfa9cfa6c6c7c
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: HID: prodikeys: Check presence of pm->input_ep82 Fake USB devices can send their own report descriptors for which the input_mapping() hook does not get called. In this case, pm->input_ep82 stays NULL, which leads to a crash later. This does not happen with the real device, but can be provoked by imposing as one.
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/3f1b21cc67a15d7d081378a9b8747dd000a017b8
- https://git.kernel.org/stable/c/cee8337e1bad168136aecfe6416ecd7d3aa7529a
- https://git.kernel.org/stable/c/d08f35f843881ec504d7537a9bb728a073db3366
- https://git.kernel.org/stable/c/d5512ce892f774d37c53082adadfcad04f21b50e
- https://git.kernel.org/stable/c/e7ac1cd823cd2e9fcbd5cb0b261d6d35dbb79341
- https://git.kernel.org/stable/c/edccbf7d6dc05d692bde3a89de5a4001f72a0fa4
- https://git.kernel.org/stable/c/ee572578f09f0e743e9383393a75c3a7a0f9b4c2
- https://git.kernel.org/stable/c/f580c79683356632f12f2c2029f2fe936d953aa1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix WARNING in usb_tx_block The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse.
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/2902a9b4415a6bafc9b1e5dd360f065d757a0bb7
- https://git.kernel.org/stable/c/3308c7504e093b22e91a4468470309cee2e26b83
- https://git.kernel.org/stable/c/498525d8358d6d20918787e59736d5b6a021e9fd
- https://git.kernel.org/stable/c/5bfb25495e391a1be0db94b15715174fa06b93a1
- https://git.kernel.org/stable/c/948a39c95d0f8d73722910f8cdb7b6e3e9206232
- https://git.kernel.org/stable/c/b82073564373e68c6ae3a96039fae14cd002a496
- https://git.kernel.org/stable/c/d66676e6ca96bf8680f869a9bd6573b26c634622
- https://git.kernel.org/stable/c/fc188b44547dea4e7350833171982a6312befde9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: cx88: Add missing unmap in snd_cx88_hw_params() In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map().
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/10ab64f8efc2f479293dce929fde326c285fc96f
- https://git.kernel.org/stable/c/1ce8c2a8f050a23240553c8bae628ac623f9dbc1
- https://git.kernel.org/stable/c/24f3dabeb97bd0bec8c1c926c97e3eb6a8129225
- https://git.kernel.org/stable/c/3baefeeb7b85e1e34eebef399ffa312be7179e30
- https://git.kernel.org/stable/c/dbc527d980f7ba8559de38f8c1e4158c71a78915
- https://git.kernel.org/stable/c/dc911fccc6e08ef46a66b2a42a764252b001ee3c
- https://git.kernel.org/stable/c/e3fb15aadfc8643203bbdf97ace0396e4586fa64
- https://git.kernel.org/stable/c/f0d7f735eba963742009b0706e19dd0bed91537a
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: arm64: Add support for TSV110 Spectre-BHB mitigation The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation.
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/598c11dd4f4a9de31d854fcb9702f54c1c70f0d0
- https://git.kernel.org/stable/c/5dbe1f14359735fa50ba0dd4a496125b5bc7f422
- https://git.kernel.org/stable/c/a8d0ad5d990b050a6db74218a34b5529085e16b8
- https://git.kernel.org/stable/c/ad0c356cae164ed5dbd1f4cfd438e46faa5292cb
- https://git.kernel.org/stable/c/cccf96c49f61e47d9332d6a4d1c7fe9a2df44440
- https://git.kernel.org/stable/c/e3baa5d4b361276efeb87b20d8beced451a7dbd5
- https://git.kernel.org/stable/c/fd51d47fcacec3ca027eb65d8c44853d3b6cea95
- https://git.kernel.org/stable/c/fd7e360845d331f542854d552469544182e61134
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fbdev: of: display_timing: fix refcount leak in of_get_display_timings() of_parse_phandle() returns a device_node with refcount incremented, which is stored in 'entry' and then copied to 'native_mode'. When the error paths at lines 184 or 192 jump to 'entryfail', native_mode's refcount is not decremented, causing a refcount leak. Fix this by changing the goto target from 'entryfail' to 'timingfail', which properly calls of_node_put(native_mode) before cleanup.
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/20881ad42e651c69d89eb38a2042838187900fd6
- https://git.kernel.org/stable/c/2b22e4fe1273c24f405ed7903349c4bbd82b6368
- https://git.kernel.org/stable/c/3ed019654234edb8625c05d05e15d40f74e64f70
- https://git.kernel.org/stable/c/69290f2d3999c5fa1a7f5d5593cfc5461fa3ee64
- https://git.kernel.org/stable/c/b5bdcc5afbff845834d04d651773cb6b47db5dd3
- https://git.kernel.org/stable/c/c5734f9030a8b1e13868d1641b5163d8e659306e
- https://git.kernel.org/stable/c/d6f34bbff07476c6abb8672c89d217824871c5ed
- https://git.kernel.org/stable/c/eacf9840ae1285a1ef47eb0ce16d786e542bd4d7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: EFI/CPER: don't go past the ARM processor CPER record buffer There's a logic inside GHES/CPER to detect if the section_length is too small, but it doesn't detect if it is too big. Currently, if the firmware receives an ARM processor CPER record stating that a section length is big, kernel will blindly trust section_length, producing a very long dump. For instance, a 67 bytes record with ERR_INFO_NUM set 46198 and section length set to 854918320 would dump a lot of data going a way past the firmware memory-mapped area. Fix it by adding a logic to prevent it to go past the buffer if ERR_INFO_NUM is too big, making it report instead: [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 [Hardware Error]: event severity: recoverable [Hardware Error]: Error 0, type: recoverable [Hardware Error]: section_type: ARM processor error [Hardware Error]: MIDR: 0xff304b2f8476870a [Hardware Error]: section length: 854918320, CPER size: 67 [Hardware Error]: section length is too big [Hardware Error]: firmware-generated error record is incorrect [Hardware Error]: ERR_INFO_NUM is 46198 [ rjw: Subject and changelog tweaks ]
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/25b290624b0e3d2f0f90238709ee0b6009b9fde8
- https://git.kernel.org/stable/c/45766863baf899059e75595dd3cb1116467f2095
- https://git.kernel.org/stable/c/64eb63f573f497553e1a0c388bbcdd639e0f0704
- https://git.kernel.org/stable/c/a68d22902a6916e10ee235fee609239004e129d0
- https://git.kernel.org/stable/c/be10c1bdf64a39832998f54900aa309b3917abcf
- https://git.kernel.org/stable/c/c80113dcfc807308f5ab33847fae77e07531aeb8
- https://git.kernel.org/stable/c/ca2aad8771aa9091bc9e42e7d546bd40b72ddcd4
- https://git.kernel.org/stable/c/eae21beecb95a3b69ee5c38a659f774e171d730e
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hfsplus: pretend special inodes as regular files Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for special inodes.
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/67407d6abc9520a8a4661285b3ed294eb73ff6e7
- https://git.kernel.org/stable/c/676bc99d0b3e356cdfec5d8204518e1aac14ec84
- https://git.kernel.org/stable/c/799c492a619a10322543d13e6d2a6d27335c868c
- https://git.kernel.org/stable/c/9353d4ee26dc33f6ada1646e84660f4c59189763
- https://git.kernel.org/stable/c/d209ebaee93fc5089101d34d1b38a91d7abb03fd
- https://git.kernel.org/stable/c/dcac5582f90b55a267d89769073c5651990b2ec5
- https://git.kernel.org/stable/c/de9affb698d5034888314880736925c39d6d048e
- https://git.kernel.org/stable/c/ed8889ca21b6ab37bc1435c4009ce37a79acb9e6
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callback After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54
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/082271e364a3205598c2e4e6233a9f49ce7941cf
- https://git.kernel.org/stable/c/25e832a7830740e72103eb0b527680a4b64bbcb3
- https://git.kernel.org/stable/c/3e64e78f4a70e3f6ac8fe5a7071f08ffd25a2489
- https://git.kernel.org/stable/c/5718d98976ad6b9700e5a6afec67fc47a8a92580
- https://git.kernel.org/stable/c/57fa3487acfa3467405f8506b94682abd96e7393
- https://git.kernel.org/stable/c/6d4e91ab97fda64e8cf9c8881cc3b4da026bd849
- https://git.kernel.org/stable/c/ec40702029b08ee8d5f5b03303d64a10e74a957b
- https://git.kernel.org/stable/c/f12352471061df83a36edf54bbb16284793284e4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak.
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/2d93758f42a57f3485534eab858b308e41653de4
- https://git.kernel.org/stable/c/403b7c757ac9f6b2ffb7d00ff4795a245f5e8911
- https://git.kernel.org/stable/c/4f2a51433a3a65d16975d1e32052d80656da077d
- https://git.kernel.org/stable/c/564fd3a63efc3ebbdb5d0a8fc7c0d3f753fbbd5d
- https://git.kernel.org/stable/c/a62ba5aa9ee95fd953583e95e519badf0b76ecf3
- https://git.kernel.org/stable/c/c44beed2e5caf2cbbe651432baa3a129f18b0169
- https://git.kernel.org/stable/c/dd530e29bd514d7187b3e2df8eb2107419c7988f
- https://git.kernel.org/stable/c/f128bab57b8018e526b7eda854ca20069863af47
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ceph: supply snapshot context in ceph_zero_partial_object() The ceph_zero_partial_object function was missing proper snapshot context for its OSD write operations, which could lead to data inconsistencies in snapshots. Reproducer: ../src/vstart.sh --new -x --localhost --bluestore ./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1 mkdir /mnt/mycephfs/.snap/snap1 md5sum /mnt/mycephfs/.snap/snap1/foo fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo echo 3 > /proc/sys/vm/drop/caches md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!!
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/36673344b41c31fb502dd0d0113cec1aa96f581e
- https://git.kernel.org/stable/c/4097e70fc543cca72982854108a32f6ae924e727
- https://git.kernel.org/stable/c/531a76c5a2e44264cee8a70121e63eb28c1ba728
- https://git.kernel.org/stable/c/5788b742007f53406049bef917833a71ddd43f60
- https://git.kernel.org/stable/c/69e59a87bab0ea31ab2a584fc65e12dafacf8953
- https://git.kernel.org/stable/c/757873abfc8ea38592582180aed0f57f0f0cb07a
- https://git.kernel.org/stable/c/9efa154609cdb658f51c7d76b30a09f7e6485250
- https://git.kernel.org/stable/c/f16bd3fa74a2084ee7e16a8a2be7e7399b970907
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: APEI/GHES: ensure that won't go past CPER allocated record The logic at ghes_new() prevents allocating too large records, by checking if they're bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB). Yet, the allocation is done with the actual number of pages from the CPER bios table location, which can be smaller. Yet, a bad firmware could send data with a different size, which might be bigger than the allocated memory, causing an OOPS: Unable to handle kernel paging request at virtual address fff00000f9b40000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000 [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022 Workqueue: kacpi_notify acpi_os_execute_deferred pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : hex_dump_to_buffer+0x30c/0x4a0 lr : hex_dump_to_buffer+0x328/0x4a0 sp : ffff800080e13880 x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083 x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004 x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083 x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010 x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020 x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008 x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020 x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000 x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008 Call trace: hex_dump_to_buffer+0x30c/0x4a0 (P) print_hex_dump+0xac/0x170 cper_estatus_print_section+0x90c/0x968 cper_estatus_print+0xf0/0x158 __ghes_print_estatus+0xa0/0x148 ghes_proc+0x1bc/0x220 ghes_notify_hed+0x5c/0xb8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x80 acpi_hed_notify+0x28/0x40 acpi_ev_notify_dispatch+0x50/0x80 acpi_os_execute_deferred+0x24/0x48 process_one_work+0x15c/0x3b0 worker_thread+0x2d0/0x400 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44) ---[ end trace 0000000000000000 ]--- Prevent that by taking the actual allocated are into account when checking for CPER length. [ rjw: Subject tweaks ]
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/616c120dcdf1ce96edcd818e38bce49667f80689
- https://git.kernel.org/stable/c/6f5d41984ad896736c23e2fff7c80e15c1319132
- https://git.kernel.org/stable/c/92ba79074c58e65a6e32713758c5a9aecd33c2ea
- https://git.kernel.org/stable/c/98bd9b28d4d11e6739ad86524b4be4ada9025e60
- https://git.kernel.org/stable/c/b6be51a12441136fdf8c49b2525689fbea1856e1
- https://git.kernel.org/stable/c/e0ec99115e135dbb58e11a0df007c7d4771d4a17
- https://git.kernel.org/stable/c/f3740a1562445f36f08afab8af59e37117b3acdc
- https://git.kernel.org/stable/c/fa2408a24f8f0db14d9cfc613ef162dc267d7ad4
HIGH8.8
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle dma_free_coherent() in error path takes priv->rx_buf.alloc_len as the dma handle. This would lead to improper unmapping of the buffer. Change the dma handle to priv->rx_buf.alloc_phys.
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/0f589ee54fd6d76d3f75e745f7f12c64cbd749e5
- https://git.kernel.org/stable/c/1b1371cd4032ae859838ebc74215f569987bb197
- https://git.kernel.org/stable/c/1b1d3c5d58a80a19d017a409aa2308162bab5bbf
- https://git.kernel.org/stable/c/1e300c33ef3cc544c2b9c693778fe9490cfe9184
- https://git.kernel.org/stable/c/7e54ff938bebb173822b4c38b33fc164c1cabf92
- https://git.kernel.org/stable/c/8320727be7ff704e07c87624efc2a4a75f54b3ce
- https://git.kernel.org/stable/c/accd0599bc8e73b962247c6c6c70ca7aa1f8e8d0
- https://git.kernel.org/stable/c/ffe68c3766997d82e9ccaf1cdbd47eba269c4aa2
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: drm: Account property blob allocations to memcg DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.
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/26b4309a3ab82a0697751cde52eb336c29c19035
- https://git.kernel.org/stable/c/405fd652d8fedff219a8f48daf8f20e881e303ab
- https://git.kernel.org/stable/c/815fa29cab3c67bebb9d0b5f41145cdd3a14d04d
- https://git.kernel.org/stable/c/866e0c1a9e7244d58ed74853cb22b81e1900cfdd
- https://git.kernel.org/stable/c/8e1664b9ee43608eb973d357ae5d858d30cbc9ca
- https://git.kernel.org/stable/c/b6117210ed349356f8e6027ff020b4d620bca42b
- https://git.kernel.org/stable/c/bbfaa5761f589a81031b493cb01275a990d6fb25
- https://git.kernel.org/stable/c/cb8b9a1755fe9f38e4fb7f287486d7e7fab3dba4
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
kexec: derive purgatory entry from symbol
kexec_load_purgatory() derives image->start by locating e_entry inside an
SHF_EXECINSTR section. If the purgatory object contains multiple
executable sections with overlapping sh_addr, the entrypoint check can
match more than once and trigger a WARN.
Derive the entry section from the purgatory_start symbol when present and
compute image->start from its final placement. Keep the existing e_entry
fallback for purgatories that do not expose the symbol.
WARNING: kernel/kexec_file.c:1009 at kexec_load_purgatory+0x395/0x3c0, CPU#10: kexec/1784
Call Trace:
bzImage64_load+0x133/0xa00
__do_sys_kexec_file_load+0x2b3/0x5c0
do_syscall_64+0x81/0x610
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[me@linux.beauty: move helper to avoid forward declaration, per Baoquan]
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/027797595a108726f4a0a45d225f603b0ffbd22b
- https://git.kernel.org/stable/c/1737d37ae1d2814e6cf0a1af87af3d41f0812b95
- https://git.kernel.org/stable/c/36eb314184a0ae74dd42914b47d2b9fc43be8034
- https://git.kernel.org/stable/c/480e1d5c64bb14441f79f2eb9421d5e26f91ea3d
- https://git.kernel.org/stable/c/5226570bd252cea2e805a161cb0f75c204c3108a
- https://git.kernel.org/stable/c/875355152b33436907c2a6d2ffad1431fa86c62b
- https://git.kernel.org/stable/c/cfccd3b8c51bc57a8a6fcb2fd30453afae5bc0d2
- https://git.kernel.org/stable/c/f736032c638a33a243e9126e617788f763d648f9
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: rapidio: replace rio_free_net() with kfree() in rio_scan_alloc_net() When idtab allocation fails, net is not registered with rio_add_net() yet, so kfree(net) is sufficient to release the memory. Set mport->net to NULL to avoid dangling pointer.
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/34a4f233df5eef5f1f113b2196142c0568b387f8
- https://git.kernel.org/stable/c/649c2e853608cad0b0cba545555d168e67f094b3
- https://git.kernel.org/stable/c/666183dcdd9ad3b8156a1df7f204f728f720380f
- https://git.kernel.org/stable/c/78812c4fb7ed242d5961bf1337a49070d6487c94
- https://git.kernel.org/stable/c/83e579c2f7f6b1706323d744833b26470049dcc2
- https://git.kernel.org/stable/c/87272e3e70ec4b666885bd520ff77463c11444ef
- https://git.kernel.org/stable/c/e5a732bfe29451e16abf9c6f07ce5948b22f3d59
- https://git.kernel.org/stable/c/fecf292c6691970897396190855aa38826b7104e
HIGH7.5
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Workaround SQM/PSE stalls by disabling sticky NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.
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/36cc5a5e0178d5fb79e04173b8aa623b0108819a
- https://git.kernel.org/stable/c/70e9a5760abfb6338d63994d4de6b0778ec795d6
- https://git.kernel.org/stable/c/8052d0587fb14b85539c3a14a226586c0c3d6b4c
- https://git.kernel.org/stable/c/9a3fd301329474f449e75f86d8a4f6b9c603fd6c
- https://git.kernel.org/stable/c/b7eba260a34e854e2487b8363c11976f082df00d
- https://git.kernel.org/stable/c/cec2ceb35ce7bc874c43812bb39200d6cf691b87
- https://git.kernel.org/stable/c/d0b3c8a80336029d9356f429151eb27922d80a3c
- https://git.kernel.org/stable/c/d9b549b6951ba178ec14339a031cae65f4e43fe1
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
dm: remove fake timeout to avoid leak request
Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of
blk_mq_complete_request"), drivers are responsible for calling
blk_should_fake_timeout() at appropriate code paths and opportunities.
However, the dm driver does not implement its own timeout handler and
relies on the timeout handling of its slave devices.
If an io-timeout-fail error is injected to a dm device, the request
will be leaked and never completed, causing tasks to hang indefinitely.
Reproduce:
1. prepare dm which has iscsi slave device
2. inject io-timeout-fail to dm
echo 1 >/sys/class/block/dm-0/io-timeout-fail
echo 100 >/sys/kernel/debug/fail_io_timeout/probability
echo 10 >/sys/kernel/debug/fail_io_timeout/times
3. read/write dm
4. iscsiadm -m node -u
Result: hang task like below
[ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds.
[ 862.244133] Tainted: G E 6.19.0-rc1+ #51
[ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000
[ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi]
[ 862.245264] Call Trace:
[ 862.245587]
[ 862.245814] __schedule+0x810/0x15c0
[ 862.246557] schedule+0x69/0x180
[ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120
[ 862.247688] elevator_change+0x16d/0x460
[ 862.247893] elevator_set_none+0x87/0xf0
[ 862.248798] blk_unregister_queue+0x12e/0x2a0
[ 862.248995] __del_gendisk+0x231/0x7e0
[ 862.250143] del_gendisk+0x12f/0x1d0
[ 862.250339] sd_remove+0x85/0x130 [sd_mod]
[ 862.250650] device_release_driver_internal+0x36d/0x530
[ 862.250849] bus_remove_device+0x1dd/0x3f0
[ 862.251042] device_del+0x38a/0x930
[ 862.252095] __scsi_remove_device+0x293/0x360
[ 862.252291] scsi_remove_target+0x486/0x760
[ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi]
[ 862.252886] process_one_work+0x633/0xe50
[ 862.253101] worker_thread+0x6df/0xf10
[ 862.253647] kthread+0x36d/0x720
[ 862.254533] ret_from_fork+0x2a6/0x470
[ 862.255852] ret_from_fork_asm+0x1a/0x30
[ 862.256037]
Remove the blk_should_fake_timeout() check from dm, as dm has no
native timeout handling and should not attempt to fake timeouts.
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/4f9e7ca933a9fbf9912a384b061a00c77332cbf0
- https://git.kernel.org/stable/c/6cdb21e0c9fdee484feba14fc9e72e9d07daf9f3
- https://git.kernel.org/stable/c/8200fca818c1e2f65bc6cb16d934ff6049302197
- https://git.kernel.org/stable/c/b307b6307f6459841312432bd4bc9519cbac97f5
- https://git.kernel.org/stable/c/c8a23d4c995ef4227bd4de64cd3910637ee6162e
- https://git.kernel.org/stable/c/cf2d06c9fd4b6521ea5b7f73c99c64c2c6f5e224
- https://git.kernel.org/stable/c/ece6720de9403260088209b0b92d45e0b49ff856
- https://git.kernel.org/stable/c/f3a9c95a15d2f4466acad5c68faeff79ca5e9f47
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: media: solo6x10: Check for out of bounds chip_id Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. [hverkuil: fix checkpatch warning for is_tw286x]
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/0b3dadada2417782a63ce32dae05bafe1c949e3f
- https://git.kernel.org/stable/c/0fdf6323c35a134f206dcad5babb4ff488552076
- https://git.kernel.org/stable/c/33af366211ee78e3b074ff44a16121e537e86826
- https://git.kernel.org/stable/c/4d6db0c6bbbfd8d7bbdbf7ab6a9c003752abf116
- https://git.kernel.org/stable/c/5849ae68d7b8b6ad55cc1bf0d227dd2ae6362528
- https://git.kernel.org/stable/c/603e3859393ee2ce91393b7d05e6e56e4b66e5cd
- https://git.kernel.org/stable/c/c327192ca26670cf6e588c1eeda66cd2fa97630e
- https://git.kernel.org/stable/c/d29f33b2cf98e4901cd5457d1ee34062e808df73
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_ext_shift_extents() In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak. Fix this by jumping to the out label to ensure the path is properly 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/12615ab4bfb69678e5d961b28bb70040299e51b1
- https://git.kernel.org/stable/c/1bce219ee5512cf179ba40cf114945a14a16e21f
- https://git.kernel.org/stable/c/2f4b1052246ca646bb17bfe0f53df2fdf9729b58
- https://git.kernel.org/stable/c/4a79fde8db7eba7f1128d971ceba4e3c9ac84aec
- https://git.kernel.org/stable/c/7e807cb8603b7664fa630a696cd891d9a03c248d
- https://git.kernel.org/stable/c/afc5e61e1a07b2b833bd72cbee36ecce9cd901e2
- https://git.kernel.org/stable/c/bd7b52557e4a3ccd7595fdb3a585f1257de57935
- https://git.kernel.org/stable/c/ca81109d4a8f192dc1cbad4a1ee25246363c2833
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe() In au1200fb_drv_probe(), when platform_get_irq fails(), it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.
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/071d8fb757a8318f72c8e02898c2cf7e14e21fb6
- https://git.kernel.org/stable/c/3d4202ee6494c0d576cdc104b12e0834ca8136a8
- https://git.kernel.org/stable/c/3e5349e54113e2dce1a659c57935e18032742e56
- https://git.kernel.org/stable/c/762a26818934241b8b0172a229d2cf5d87260e40
- https://git.kernel.org/stable/c/81831d56b723bc1090ce3158feddaca88e85f939
- https://git.kernel.org/stable/c/b024a8efee0f55d330a1cdd3eac8f79ac5acd3be
- https://git.kernel.org/stable/c/bd1ad63e11b2a568e98de536f319054d2de29f56
- https://git.kernel.org/stable/c/ce4e25198a6aaaaf36248edf8daf3d744ec8e309
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: hfsplus: return error when node already exists in hfs_bnode_create When hfs_bnode_create() finds that a node is already hashed (which should not happen in normal operation), it currently returns the existing node without incrementing its reference count. This causes a reference count inconsistency that leads to a kernel panic when the node is later freed in hfs_bnode_put(): kernel BUG at fs/hfsplus/bnode.c:676! BUG_ON(!atomic_read(&node->refcnt)) This scenario can occur when hfs_bmap_alloc() attempts to allocate a node that is already in use (e.g., when node 0's bitmap bit is incorrectly unset), or due to filesystem corruption. Returning an existing node from a create path is not normal operation. Fix this by returning ERR_PTR(-EEXIST) instead of the node when it's already hashed. This properly signals the error condition to callers, which already check for IS_ERR() return values.
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/1ca428769cb4737a25bd32fb4d1573cc09eeaeef
- https://git.kernel.org/stable/c/2e6ff6a6fc69cc17ed10c9cb6242935d52acd52d
- https://git.kernel.org/stable/c/2e9185a42e0e237c74435fd092b7c34537c62156
- https://git.kernel.org/stable/c/507a1de58c21c95ad7c44afccaf1222d1c42246b
- https://git.kernel.org/stable/c/51838112d9c22502333c3085ca0c0d691e7093c6
- https://git.kernel.org/stable/c/7b57ada854b32310f224abd61bcfec2d5790ff0a
- https://git.kernel.org/stable/c/986455135b95f32c1f142068e451098fc751749e
- https://git.kernel.org/stable/c/d8a73cc46c8462a969a7516131feb3096f4c49d3
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gss_auth kref leak in gss_alloc_msg error path Commit 5940d1cf9f42 ("SUNRPC: Rebalance a kref in auth_gss.c") added a kref_get(&gss_auth->kref) call to balance the gss_put_auth() done in gss_release_msg(), but forgot to add a corresponding kref_put() on the error path when kstrdup_const() fails. If service_name is non-NULL and kstrdup_const() fails, the function jumps to err_put_pipe_version which calls put_pipe_version() and kfree(gss_msg), but never releases the gss_auth reference. This leads to a kref leak where the gss_auth structure is never freed. Add a forward declaration for gss_free_callback() and call kref_put() in the err_put_pipe_version error path to properly release the reference taken earlier.
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/3b2b6c42070ce4204936288253baf101e995c2d3
- https://git.kernel.org/stable/c/655c9ba9915f05266998dbbf4b76b3c79b8a70aa
- https://git.kernel.org/stable/c/a1bc9561b617ec7e2d09e6c134d1db8fcf9ca4a6
- https://git.kernel.org/stable/c/a2d4e9a76de0b2178001214ba5de5bf94a7354aa
- https://git.kernel.org/stable/c/b559be2ec6cdb2e9c2c36c23fbbd4690d8a5c3f7
- https://git.kernel.org/stable/c/c20f925214249bb4fc04f7e197bea142a6438af6
- https://git.kernel.org/stable/c/dd2fdc3504592d85e549c523b054898a036a6afe
- https://git.kernel.org/stable/c/e464e26b2457005c87e158570498274b9f3b90c7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix invalid deref of rawdata when export_binary is unset
If the export_binary parameter is disabled on runtime, profiles that
were loaded before that will still have their rawdata stored in
apparmorfs, with a symbolic link to the rawdata on the policy
directory. When one of those profiles are replaced, the rawdata is set
to NULL, but when trying to resolve the symbolic links to rawdata for
that profile, it will try to dereference profile->rawdata->name when
profile->rawdata is now NULL causing an oops. Fix it by checking if
rawdata is set.
[ 168.653080] BUG: kernel NULL pointer dereference, address: 0000000000000088
[ 168.657420] #PF: supervisor read access in kernel mode
[ 168.660619] #PF: error_code(0x0000) - not-present page
[ 168.663613] PGD 0 P4D 0
[ 168.665450] Oops: Oops: 0000 [#1] SMP NOPTI
[ 168.667836] CPU: 1 UID: 0 PID: 1729 Comm: ls Not tainted 6.19.0-rc7+ #3 PREEMPT(voluntary)
[ 168.672308] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 168.679327] RIP: 0010:rawdata_get_link_base.isra.0+0x23/0x330
[ 168.682768] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 48 89 55 d0 48 85 ff 0f 84 e3 01 00 00 <48> 83 3c 25 88 00 00 00 00 0f 84 d4 01 00 00 49 89 f6 49 89 cc e8
[ 168.689818] RSP: 0018:ffffcdcb8200fb80 EFLAGS: 00010282
[ 168.690871] RAX: ffffffffaee74ec0 RBX: 0000000000000000 RCX: ffffffffb0120158
[ 168.692251] RDX: ffffcdcb8200fbe0 RSI: ffff88c187c9fa80 RDI: ffff88c186c98a80
[ 168.693593] RBP: ffffcdcb8200fbc0 R08: 0000000000000000 R09: 0000000000000000
[ 168.694941] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c186c98a80
[ 168.696289] R13: 00007fff005aaa20 R14: 0000000000000080 R15: ffff88c188f4fce0
[ 168.697637] FS: 0000790e81c58280(0000) GS:ffff88c20a957000(0000) knlGS:0000000000000000
[ 168.699227] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 168.700349] CR2: 0000000000000088 CR3: 000000012fd3e000 CR4: 0000000000350ef0
[ 168.701696] Call Trace:
[ 168.702325]
[ 168.702995] rawdata_get_link_data+0x1c/0x30
[ 168.704145] vfs_readlink+0xd4/0x160
[ 168.705152] do_readlinkat+0x114/0x180
[ 168.706214] __x64_sys_readlink+0x1e/0x30
[ 168.708653] x64_sys_call+0x1d77/0x26b0
[ 168.709525] do_syscall_64+0x81/0x500
[ 168.710348] ? do_statx+0x72/0xb0
[ 168.711109] ? putname+0x3e/0x80
[ 168.711845] ? __x64_sys_statx+0xb7/0x100
[ 168.712711] ? x64_sys_call+0x10fc/0x26b0
[ 168.713577] ? do_syscall_64+0xbf/0x500
[ 168.714412] ? do_user_addr_fault+0x1d2/0x8d0
[ 168.715404] ? irqentry_exit+0xb2/0x740
[ 168.716359] ? exc_page_fault+0x90/0x1b0
[ 168.717307] entry_SYSCALL_64_after_hwframe+0x76/0x7e
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/1432ab0774cba43e8111be39989ff226531a9bac
- https://git.kernel.org/stable/c/19f2e4055626a58842ddec3282ad4465a80c6625
- https://git.kernel.org/stable/c/1d2b2b58fde9059a488bc25399e6c3d74e9b5548
- https://git.kernel.org/stable/c/3c36b87fc2a4cf88eadea8cf13923bd2b4f9a3fa
- https://git.kernel.org/stable/c/6d8c180c825cbc73eeffaa79591f8e142dacae70
- https://git.kernel.org/stable/c/b25298e89a297c42eb4c4d6f081d60375b820abb
- https://git.kernel.org/stable/c/df9ac55abd18628bd8cff687ea043660532a3654
- https://git.kernel.org/stable/c/e6b2fc7e34d4e7ca6b8598c33a3d45d59e455d8d
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: cpuidle: Skip governor when only one idle state is available On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash. [ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668 Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.
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/4da2b897283c39980d6ae09dc1560fcd937879e5
- https://git.kernel.org/stable/c/5c577ac939bca486cb02069505cfe47a5312ce02
- https://git.kernel.org/stable/c/5d103a38e2ae96eca57fd17161bcd29bd4622d1c
- https://git.kernel.org/stable/c/63ae78336f40bcd9a44952a7c6bafb9c88a8effd
- https://git.kernel.org/stable/c/8f6833d919bae915ead6c599a53e81e19b32da52
- https://git.kernel.org/stable/c/a0724e40a58a0e323c59707edeae5b71d15800dc
- https://git.kernel.org/stable/c/a0f7e804edc82e513d1ccb7c95ed8b351522ec81
- https://git.kernel.org/stable/c/e5c9ffc6ae1bcdb1062527d611043681ac301aca
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved:
bonding: alb: fix UAF in rlb_arp_recv during bond up/down
The ALB RX path may access rx_hashtbl concurrently with bond
teardown. During rapid bond up/down cycles, rlb_deinitialize()
frees rx_hashtbl while RX handlers are still running, leading
to a null pointer dereference detected by KASAN.
However, the root cause is that rlb_arp_recv() can still be accessed
after setting recv_probe to NULL, which is actually a use-after-free
(UAF) issue. That is the reason for using the referenced commit in the
Fixes tag.
[ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI
[ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]
[ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary)
[ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022
[ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding]
[ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6
04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00
[ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206
[ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e
[ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8
[ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8
[ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119
[ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810
[ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000
[ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0
[ 214.310347] Call Trace:
[ 214.313070]
[ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding]
[ 214.320975] bond_handle_frame+0x166/0xb60 [bonding]
[ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding]
[ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710
[ 214.339199] ? __pfx_arp_process+0x10/0x10
[ 214.343775] ? sched_balance_find_src_group+0x98/0x630
[ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10
[ 214.356513] ? arp_rcv+0x307/0x690
[ 214.360311] ? __pfx_arp_rcv+0x10/0x10
[ 214.364499] ? __lock_acquire+0x58c/0xbd0
[ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0
[ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10
[ 214.380743] ? lock_acquire+0x10b/0x140
[ 214.385026] process_backlog+0x3f1/0x13a0
[ 214.389502] ? process_backlog+0x3aa/0x13a0
[ 214.394174] __napi_poll.constprop.0+0x9f/0x370
[ 214.399233] net_rx_action+0x8c1/0xe60
[ 214.403423] ? __pfx_net_rx_action+0x10/0x10
[ 214.408193] ? lock_acquire.part.0+0xbd/0x260
[ 214.413058] ? sched_clock_cpu+0x6c/0x540
[ 214.417540] ? mark_held_locks+0x40/0x70
[ 214.421920] handle_softirqs+0x1fd/0x860
[ 214.426302] ? __pfx_handle_softirqs+0x10/0x10
[ 214.431264] ? __neigh_event_send+0x2d6/0xf50
[ 214.436131] do_softirq+0xb1/0xf0
[ 214.439830]
The issue is reproducible by repeatedly running
ip link set bond0 up/down while receiving ARP messages, where
rlb_arp_recv() can race with rlb_deinitialize() and dereference
a freed rx_hashtbl entry.
Fix this by setting recv_probe to NULL and then calling
synchronize_net() to wait for any concurrent RX processing to finish.
This ensures that no RX handler can access rx_hashtbl after it is freed
in bond_alb_deinitialize().
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/c65cdf46ce340c9c00fbbaf84599d2daff43626e
- https://git.kernel.org/stable/c/d31065526f160ee0244a719230aa069daca2bf4d
- https://git.kernel.org/stable/c/db5435b5342e3aaa4521d0f3ccfe94316b253ca1
- https://git.kernel.org/stable/c/de7c097800f07f3c108185c7a38b53a530ba30ff
- https://git.kernel.org/stable/c/e6834a4c474697df23ab9948fd3577b26bf48656
- https://git.kernel.org/stable/c/f94a0de7b9f32745a14a1621c63087a092823587
- https://git.kernel.org/stable/c/fd54ddc929be1d6c3b3b7b35d6d4642a5d9e803c
- https://git.kernel.org/stable/c/fef13c403be3fb685cb06419e6b3623106aab5ba
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found If btrfs_search_slot_for_read() returns 1, it means we did not find any key greater than or equals to the key we asked for, meaning we have reached the end of the tree and therefore the path is not valid. If this happens we need to break out of the loop and stop, instead of continuing and accessing an invalid 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/023545e272f369d487e6a986c1e321c6e04be1da
- https://git.kernel.org/stable/c/0761447f6f51e1c7997960d8e6559337deed6729
- https://git.kernel.org/stable/c/1ee1d006c9fe4d6be5527ab1c84216b80cccbe40
- https://git.kernel.org/stable/c/b2bd557b75b760e4b9d209112bda19314bd64558
- https://git.kernel.org/stable/c/b5b8ade9da452086e78f5d519b90d3769e354853
- https://git.kernel.org/stable/c/d7cf2314dd5e8661c05d076cd627eea9a7f76616
- https://git.kernel.org/stable/c/ecb7c2484cfc83a93658907580035a8adf1e0a92
- https://git.kernel.org/stable/c/fd4913a53e3b54ad7e161847291439fe445d6356
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: staging: greybus: lights: avoid NULL deref gb_lights_light_config() stores channel_count before allocating the channels array. If kcalloc() fails, gb_lights_release() iterates the non-zero count and dereferences light->channels, which is NULL. Allocate channels first and only then publish channels_count so the cleanup path can't walk a NULL pointer.
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/01b91cb3e748032fd96bbe0043812b426a52f091
- https://git.kernel.org/stable/c/06162d85f830582da6e9e5fcf9c9504d6da9ae0b
- https://git.kernel.org/stable/c/3cbe694d235d96f628ec7dc6ae4d8bdddb768699
- https://git.kernel.org/stable/c/65f2c608096d766540953d9b170d216aa3b5eb95
- https://git.kernel.org/stable/c/a118724d7641b832fa14323e2733e28ae4834552
- https://git.kernel.org/stable/c/ba5022162da63059bae36c4fd84d7031f582c71f
- https://git.kernel.org/stable/c/da46264a7016034a5bbbad034c012ef218b7d0af
- https://git.kernel.org/stable/c/efcffd9a6ad8d190651498d5eda53bfc7cf683a7
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: nfsd: never defer requests during idmap lookup During v4 request compound arg decoding, some ops (e.g. SETATTR) can trigger idmap lookup upcalls. When those upcall responses get delayed beyond the allowed time limit, cache_check() will mark the request for deferral and cause it to be dropped. This prevents nfs4svc_encode_compoundres from being executed, and thus the session slot flag NFSD4_SLOT_INUSE never gets cleared. Subsequent client requests will fail with NFSERR_JUKEBOX, given that the slot will be marked as in-use, making the SEQUENCE op fail. Fix this by making sure that the RQ_USEDEFERRAL flag is always clear during nfs4svc_decode_compoundargs(), since no v4 request should ever be deferred.
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/063a6f22478ef929625000a2caf54667725c1dfd
- https://git.kernel.org/stable/c/243f71ed873ff3feeb6f9b5cb145d63f7188b4c4
- https://git.kernel.org/stable/c/3a72c7dedc99b321e0f267e4e999e5baf07c4593
- https://git.kernel.org/stable/c/8dff54fe88c0dcd4c55bff9fc2fa6ca968290826
- https://git.kernel.org/stable/c/99e17b20fddac19a228d213e00f6b9e1c10daff9
- https://git.kernel.org/stable/c/b9abb760db20504240a7147f27934d900cd80b23
- https://git.kernel.org/stable/c/d75ec4504a4340b033b15cad0303988b3089dd93
- https://git.kernel.org/stable/c/f9c206cdc4266caad6a9a7f46341420a10f03ccb
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
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/1403989d1b502f4a2c0d0b42ccf1c25748442eff
- https://git.kernel.org/stable/c/1cae1bafdf9caa9b462b19af06b1a06902e4e142
- https://git.kernel.org/stable/c/6d76febba07c40bcf358f63216d36ea68cf1c215
- https://git.kernel.org/stable/c/764c3c84b5683e608f43735c803a5f415046686c
- https://git.kernel.org/stable/c/815ddd27c0c7171a99fe802fdb19098ddef8b19d
- https://git.kernel.org/stable/c/87d4954b5c59735a99ea98cb208d47130f6dce7d
- https://git.kernel.org/stable/c/d87268326b277af3665237ac76a73dd9fa8e21b4
- https://git.kernel.org/stable/c/faddeb848305e79db89ee0479bb0e33380656321
MEDIUM5.5
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Fix PF driver crash with kexec kernel booting During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware. The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash. Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.
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/1370736836a18b5e0cd74bcc9cffe11d21f1fe79
- https://git.kernel.org/stable/c/2d2d574309e3ae84ee794869a5da8b4c38753a94
- https://git.kernel.org/stable/c/57821d1436ba1c6a6973aa32d54166fdec35558c
- https://git.kernel.org/stable/c/7d56ba306e93d04696718963fb4cda2883ee7585
- https://git.kernel.org/stable/c/8b5ed7c5417b7013d35b6f2507dab739013ba1a9
- https://git.kernel.org/stable/c/9769a09afda20a006b528b9e723effcae45965b2
- https://git.kernel.org/stable/c/9c3398e5b3a914b74276d44ab54c49123b89c61a
- https://git.kernel.org/stable/c/b7605b9301abc18fbbf2b0e23fdd281fc768955d
HIGH7.3
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Work around LLVM bug when gp is used as global register variable
On MIPS, __current_thread_info is defined as global register variable
locating in $gp, and is simply assigned with new address during kernel
relocation.
This however is broken with LLVM, which always restores $gp if it finds
$gp is clobbered in any form, including when intentionally through a
global register variable. This is against GCC's documentation[1], which
requires a callee-saved register used as global register variable not to
be restored if it's clobbered.
As a result, $gp will continue to point to the unrelocated kernel after
the epilog of relocate_kernel(), leading to an early crash in init_idle,
[ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90
[ 0.000000] Oops[#1]:
[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY
[ 0.000000] Tainted: [W]=WARN
[ 0.000000] Hardware name: loongson,loongson64v-4core-virtio
[ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000
[ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240
[ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001
[ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002
[ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80
[ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80
[ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90
[ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90
[ 0.000000] Hi : 0000000000000000
[ 0.000000] Lo : 0000000000000000
[ 0.000000] epc : ffffffff81afada8 init_idle+0x130/0x270
[ 0.000000] ra : ffffffff81afad90 init_idle+0x118/0x270
[ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL
[ 0.000000] Cause : 00000008 (ExcCode 02)
[ 0.000000] BadVA : 0000000000000000
[ 0.000000] PrId : 00006305 (ICT Loongson-3)
[ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)
[ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000
[ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528
[ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000
[ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258
[ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98
[ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000
[ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000
[ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002
[ 0.000000] ...
[ 0.000000] Call Trace:
[ 0.000000] [] init_idle+0x130/0x270
[ 0.000000] [] sched_init+0x5c8/0x6c0
[ 0.000000] [] start_kernel+0x27c/0x7a8
This bug has been reported to LLVM[2] and affects version from (at
least) 18 to 21. Let's work around this by using inline assembly to
assign $gp before a fix is widely available.
CVSS 3.xВЫСОКАЯ 7.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:HСсылки
- https://git.kernel.org/stable/c/05bff9b0ae095b2420cfebb4a96759a09334bec6
- https://git.kernel.org/stable/c/1fe3b402b1e97a1718df3be0a1d3eee20133e735
- https://git.kernel.org/stable/c/30bfc2d6a1132a89a5f1c3b96c59cf3e4d076ea3
- https://git.kernel.org/stable/c/4dc65b40fb80c2020efbf139b9a38d30f9a37b92
- https://git.kernel.org/stable/c/561834f6d6f52b8a1791331e94b2aac753491d2a
- https://git.kernel.org/stable/c/9bc3b0ae5203aba650297fdf3e1e774125e423f2
- https://git.kernel.org/stable/c/c0155dee51b9f5f48aaf5c71cae005eb0e36521f
- https://git.kernel.org/stable/c/e3a6498a63394218561065a9a7a597a204f52f6a
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: fix buffer overflow in persistent_ram_save_old() persistent_ram_save_old() can be called multiple times for the same persistent_ram_zone (e.g., via ramoops_pstore_read -> ramoops_get_next_prz for PSTORE_TYPE_DMESG records). Currently, the function only allocates prz->old_log when it is NULL, but it unconditionally updates prz->old_log_size to the current buffer size and then performs memcpy_fromio() using this new size. If the buffer size has grown since the first allocation (which can happen across different kernel boot cycles), this leads to: 1. A heap buffer overflow (OOB write) in the memcpy_fromio() calls 2. A subsequent OOB read when ramoops_pstore_read() accesses the buffer using the incorrect (larger) old_log_size The KASAN splat would look similar to: BUG: KASAN: slab-out-of-bounds in ramoops_pstore_read+0x... Read of size N at addr ... by task ... The conditions are likely extremely hard to hit: 0. Crash with a ramoops write of less-than-record-max-size bytes. 1. Reboot: ramoops registers, pstore_get_records(0) reads old crash, allocates old_log with size X 2. Crash handler registered, timer started (if pstore_update_ms >= 0) 3. Oops happens (non-fatal, system continues) 4. pstore_dump() writes oops via ramoops_pstore_write() size Y (>X) 5. pstore_new_entry = 1, pstore_timer_kick() called 6. System continues running (not a panic oops) 7. Timer fires after pstore_update_ms milliseconds 8. pstore_timefunc() → schedule_work() → pstore_dowork() → pstore_get_records(1) 9. ramoops_get_next_prz() → persistent_ram_save_old() 10. buffer_size() returns Y, but old_log is X bytes 11. Y > X: memcpy_fromio() overflows heap Requirements: - a prior crash record exists that did not fill the record size (almost impossible since the crash handler writes as much as it can possibly fit into the record, capped by max record size and the kmsg buffer almost always exceeds the max record size) - pstore_update_ms >= 0 (disabled by default) - Non-fatal oops (system survives) Free and reallocate the buffer when the new size differs from the previously allocated size. This ensures old_log always has sufficient space for the data being copied.
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/06d2c8bd108cea503f6f6e13e47495ed1085275f
- https://git.kernel.org/stable/c/2fa9a047c6a50ec80c3890dd623b85e237f0d1fd
- https://git.kernel.org/stable/c/4f73486ca822305c1cf5b8ebc0b53a6ab3801a81
- https://git.kernel.org/stable/c/5669645c052f235726a85f443769b6fc02f66762
- https://git.kernel.org/stable/c/58bda5a1d1ee98254383ef34f76b2c35140513ea
- https://git.kernel.org/stable/c/7cfe964e61c0ab667abd5f5b68e0acbf783efa4f
- https://git.kernel.org/stable/c/9a6fc69a570c0780834246d52c856cc3dbc2605f
- https://git.kernel.org/stable/c/cff0ef043e16feb5a02307c8f9d0117a96c5587c
HIGH7.8
In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent.
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/0e64bd46a04a4fd61279aca9f53a664e9e5f7e7e
- https://git.kernel.org/stable/c/1c8dc5b5517546c68ffae40b948336122bb61306
- https://git.kernel.org/stable/c/4f9ae386861e280b7631ca252f798d25575627ee
- https://git.kernel.org/stable/c/73ec7c96601d61d52310c659145bb06d933a0fa6
- https://git.kernel.org/stable/c/76149d53502cf17ef3ae454ff384551236fba867
- https://git.kernel.org/stable/c/c93a33f28f915d446eea6fb3f0e1def0b3af1982
- https://git.kernel.org/stable/c/dd8b13cb4ff1a4545a214ed897fdf2bc341155b6
- https://git.kernel.org/stable/c/fefa0fcd78be465b7ad4c497fa6ec90d64194c04
HIGH8.4
In the Linux kernel, the following vulnerability has been resolved: power: supply: rt9455: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.
CVSS 3.xВЫСОКАЯ 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HСсылки
- https://git.kernel.org/stable/c/2178dc65d45e2f7bcaa8af8d80d100419bdab251
- https://git.kernel.org/stable/c/62d753b916bd500bb269b7078cdab73198ab4718
- https://git.kernel.org/stable/c/64e15155095f39f4dec9b4659da1238ef8fc54d4
- https://git.kernel.org/stable/c/721449a15170fc5f028a7576d7f65b9f60d53482
- https://git.kernel.org/stable/c/a39f8f06216f73ef40e71e2fe4ad071964c1fd36
- https://git.kernel.org/stable/c/af261f218a7606f93d2c786353d60bb4feb56ef0
- https://git.kernel.org/stable/c/d4e2e3c3caa26b93aa9f36d0a6824b584e2a8dfc
- https://git.kernel.org/stable/c/e2febe375e5ea5afed92f4cd9711bde8f24ee6d2