Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs()<br /> <br /> sqe-&gt;len is __u32 but gets stored into sr-&gt;len which is int. When<br /> userspace passes sqe-&gt;len values exceeding INT_MAX (e.g. 0xFFFFFFFF),<br /> sr-&gt;len overflows to a negative value. This negative value propagates<br /> through the bundle recv/send path:<br /> <br /> 1. io_recv(): sel.val = sr-&gt;len (ssize_t gets -1)<br /> 2. io_recv_buf_select(): arg.max_len = sel-&gt;val (size_t gets<br /> 0xFFFFFFFFFFFFFFFF)<br /> 3. io_ring_buffers_peek(): buf-&gt;len is not clamped because max_len<br /> is astronomically large<br /> 4. iov[].iov_len = 0xFFFFFFFF flows into io_bundle_nbufs()<br /> 5. io_bundle_nbufs(): min_t(int, 0xFFFFFFFF, ret) yields -1,<br /> causing ret to increase instead of decrease, creating an<br /> infinite loop that reads past the allocated iov[] array<br /> <br /> This results in a slab-out-of-bounds read in io_bundle_nbufs() from<br /> the kmalloc-64 slab, as nbufs increments past the allocated iovec<br /> entries.<br /> <br /> BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs+0x128/0x160<br /> Read of size 8 at addr ffff888100ae05c8 by task exp/145<br /> Call Trace:<br /> io_bundle_nbufs+0x128/0x160<br /> io_recv_finish+0x117/0xe20<br /> io_recv+0x2db/0x1160<br /> <br /> Fix this by rejecting negative sr-&gt;len values early in both<br /> io_sendmsg_prep() and io_recvmsg_prep(). Since sqe-&gt;len is __u32,<br /> any value &gt; INT_MAX indicates overflow and is not a valid length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpib: fix use-after-free in IO ioctl handlers<br /> <br /> The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor<br /> pointer after board-&gt;big_gpib_mutex has been released. A concurrent<br /> IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during<br /> this window, causing a use-after-free.<br /> <br /> The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly<br /> release big_gpib_mutex before calling their handler. wait_ioctl() is<br /> called with big_gpib_mutex held, but ibwait() releases it internally<br /> when wait_mask is non-zero. In all four cases, the descriptor pointer<br /> obtained from handle_to_descriptor() becomes unprotected.<br /> <br /> Fix this by introducing a kernel-only descriptor_busy reference count<br /> in struct gpib_descriptor. Each handler atomically increments<br /> descriptor_busy under file_priv-&gt;descriptors_mutex before releasing the<br /> lock, and decrements it when done. close_dev_ioctl() checks<br /> descriptor_busy under the same lock and rejects the close with -EBUSY<br /> if the count is non-zero.<br /> <br /> A reference count rather than a simple flag is necessary because<br /> multiple handlers can operate on the same descriptor concurrently<br /> (e.g. IBRD and IBWAIT on the same handle from different threads).<br /> <br /> A separate counter is needed because io_in_progress can be cleared from<br /> unprivileged userspace via the IBWAIT ioctl (through general_ibstatus()<br /> with set_mask containing CMPL), which would allow an attacker to bypass<br /> a check based solely on io_in_progress. The new descriptor_busy<br /> counter is only modified by the kernel IO paths.<br /> <br /> The lock ordering is consistent (big_gpib_mutex -&gt; descriptors_mutex)<br /> and the handlers only hold descriptors_mutex briefly during the lookup,<br /> so there is no deadlock risk and no impact on IO throughput.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (occ) Fix division by zero in occ_show_power_1()<br /> <br /> In occ_show_power_1() case 1, the accumulator is divided by<br /> update_tag without checking for zero. If no samples have been<br /> collected yet (e.g. during early boot when the sensor block is<br /> included but hasn&amp;#39;t been updated), update_tag is zero, causing<br /> a kernel divide-by-zero crash.<br /> <br /> The 2019 fix in commit 211186cae14d ("hwmon: (occ) Fix division by<br /> zero issue") only addressed occ_get_powr_avg() used by<br /> occ_show_power_2() and occ_show_power_a0(). This separate code<br /> path in occ_show_power_1() was missed.<br /> <br /> Fix this by reusing the existing occ_get_powr_avg() helper, which<br /> already handles the zero-sample case and uses mul_u64_u32_div()<br /> to multiply before dividing for better precision. Move the helper<br /> above occ_show_power_1() so it is visible at the call site.<br /> <br /> [groeck: Fix alignment problems reported by checkpatch]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: move wake reason storage into validated event handlers<br /> <br /> hci_store_wake_reason() is called from hci_event_packet() immediately<br /> after stripping the HCI event header but before hci_event_func()<br /> enforces the per-event minimum payload length from hci_ev_table.<br /> This means a short HCI event frame can reach bacpy() before any bounds<br /> check runs.<br /> <br /> Rather than duplicating skb parsing and per-event length checks inside<br /> hci_store_wake_reason(), move wake-address storage into the individual<br /> event handlers after their existing event-length validation has<br /> succeeded. Convert hci_store_wake_reason() into a small helper that only<br /> stores an already-validated bdaddr while the caller holds hci_dev_lock().<br /> Use the same helper after hci_event_func() with a NULL address to<br /> preserve the existing unexpected-wake fallback semantics when no<br /> validated event handler records a wake address.<br /> <br /> Annotate the helper with __must_hold(&amp;hdev-&gt;lock) and add<br /> lockdep_assert_held(&amp;hdev-&gt;lock) so future call paths keep the lock<br /> contract explicit.<br /> <br /> Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(),<br /> hci_sync_conn_complete_evt(), le_conn_complete_evt(),<br /> hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(),<br /> hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and<br /> hci_le_past_received_evt().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SMP: derive legacy responder STK authentication from MITM state<br /> <br /> The legacy responder path in smp_random() currently labels the stored<br /> STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH.<br /> That reflects what the local service requested, not what the pairing<br /> flow actually achieved.<br /> <br /> For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear<br /> and the resulting STK should remain unauthenticated even if the local<br /> side requested HIGH security. Use the established MITM state when<br /> storing the responder STK so the key metadata matches the pairing result.<br /> <br /> This also keeps the legacy path aligned with the Secure Connections code,<br /> which already treats JUST_WORKS/JUST_CFM as unauthenticated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync<br /> <br /> hci_le_big_create_sync() uses DEFINE_FLEX to allocate a<br /> struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17)<br /> BIS entries. However, conn-&gt;num_bis can hold up to HCI_MAX_ISO_BIS (31)<br /> entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller<br /> hci_conn_big_create_sync(). When conn-&gt;num_bis is between 18 and 31,<br /> the memcpy that copies conn-&gt;bis into cp-&gt;bis writes up to 14 bytes<br /> past the stack buffer, corrupting adjacent stack memory.<br /> <br /> This is trivially reproducible: binding an ISO socket with<br /> bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will<br /> eventually trigger hci_le_big_create_sync() from the HCI command<br /> sync worker, causing a KASAN-detectable stack-out-of-bounds write:<br /> <br /> BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0<br /> Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71<br /> <br /> Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to<br /> HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that<br /> conn-&gt;bis can actually carry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: st_lsm6dsx: Set buffer sampling frequency for accelerometer only<br /> <br /> The st_lsm6dsx_hwfifo_odr_store() function, which is called when userspace<br /> writes the buffer sampling frequency sysfs attribute, calls<br /> st_lsm6dsx_check_odr(), which accesses the odr_table array at index<br /> `sensor-&gt;id`; since this array is only 2 entries long, an access for any<br /> sensor type other than accelerometer or gyroscope is an out-of-bounds<br /> access.<br /> <br /> The motivation for being able to set a buffer frequency different from the<br /> sensor sampling frequency is to support use cases that need accurate event<br /> detection (which requires a high sampling frequency) while retrieving<br /> sensor data at low frequency. Since all the supported event types are<br /> generated from acceleration data only, do not create the buffer sampling<br /> frequency attribute for sensor types other than the accelerometer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050: Fix incorrect free_irq() variable<br /> <br /> The handler for the IRQ part of this driver is mpu3050-&gt;trig but,<br /> in the teardown free_irq() is called with handler mpu3050.<br /> <br /> Use correct IRQ handler when calling free_irq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050: Fix irq resource leak<br /> <br /> The interrupt handler is setup but only a few lines down if<br /> iio_trigger_register() fails the function returns without properly<br /> releasing the handler.<br /> <br /> Add cleanup goto to resolve resource leak.<br /> <br /> Detected by Smatch:<br /> drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn:<br /> &amp;#39;irq&amp;#39; from request_threaded_irq() not released on lines: 1124.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050: Move iio_device_register() to correct location<br /> <br /> iio_device_register() should be at the end of the probe function to<br /> prevent race conditions.<br /> <br /> Place iio_device_register() at the end of the probe function and place<br /> iio_device_unregister() accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpib: lpvo_usb: fix memory leak on disconnect<br /> <br /> The driver iterates over the registered USB interfaces during GPIB<br /> attach and takes a reference to their USB devices until a match is<br /> found. These references are never released which leads to a memory leak<br /> when devices are disconnected.<br /> <br /> Fix the leak by dropping the unnecessary references.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Change AMDGPU_VA_RESERVED_TRAP_SIZE to 64KB<br /> <br /> Currently, AMDGPU_VA_RESERVED_TRAP_SIZE is hardcoded to 8KB, while<br /> KFD_CWSR_TBA_TMA_SIZE is defined as 2 * PAGE_SIZE. On systems with<br /> 4K pages, both values match (8KB), so allocation and reserved space<br /> are consistent.<br /> <br /> However, on 64K page-size systems, KFD_CWSR_TBA_TMA_SIZE becomes 128KB,<br /> while the reserved trap area remains 8KB. This mismatch causes the<br /> kernel to crash when running rocminfo or rccl unit tests.<br /> <br /> Kernel attempted to read user page (2) - exploit attempt? (uid: 1001)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000002<br /> Faulting instruction address: 0xc0000000002c8a64<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> CPU: 34 UID: 1001 PID: 9379 Comm: rocminfo Tainted: G E<br /> 6.19.0-rc4-amdgpu-00320-gf23176405700 #56 VOLUNTARY<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: IBM,9105-42A POWER10 (architected) 0x800200 0xf000006<br /> of:IBM,FW1060.30 (ML1060_896) hv:phyp pSeries<br /> NIP: c0000000002c8a64 LR: c00000000125dbc8 CTR: c00000000125e730<br /> REGS: c0000001e0957580 TRAP: 0300 Tainted: G E<br /> MSR: 8000000000009033 CR: 24008268<br /> XER: 00000036<br /> CFAR: c00000000125dbc4 DAR: 0000000000000002 DSISR: 40000000<br /> IRQMASK: 1<br /> GPR00: c00000000125d908 c0000001e0957820 c0000000016e8100<br /> c00000013d814540<br /> GPR04: 0000000000000002 c00000013d814550 0000000000000045<br /> 0000000000000000<br /> GPR08: c00000013444d000 c00000013d814538 c00000013d814538<br /> 0000000084002268<br /> GPR12: c00000000125e730 c000007e2ffd5f00 ffffffffffffffff<br /> 0000000000020000<br /> GPR16: 0000000000000000 0000000000000002 c00000015f653000<br /> 0000000000000000<br /> GPR20: c000000138662400 c00000013d814540 0000000000000000<br /> c00000013d814500<br /> GPR24: 0000000000000000 0000000000000002 c0000001e0957888<br /> c0000001e0957878<br /> GPR28: c00000013d814548 0000000000000000 c00000013d814540<br /> c0000001e0957888<br /> NIP [c0000000002c8a64] __mutex_add_waiter+0x24/0xc0<br /> LR [c00000000125dbc8] __mutex_lock.constprop.0+0x318/0xd00<br /> Call Trace:<br /> 0xc0000001e0957890 (unreliable)<br /> __mutex_lock.constprop.0+0x58/0xd00<br /> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x6fc/0xb60 [amdgpu]<br /> kfd_process_alloc_gpuvm+0x54/0x1f0 [amdgpu]<br /> kfd_process_device_init_cwsr_dgpu+0xa4/0x1a0 [amdgpu]<br /> kfd_process_device_init_vm+0xd8/0x2e0 [amdgpu]<br /> kfd_ioctl_acquire_vm+0xd0/0x130 [amdgpu]<br /> kfd_ioctl+0x514/0x670 [amdgpu]<br /> sys_ioctl+0x134/0x180<br /> system_call_exception+0x114/0x300<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> This patch changes AMDGPU_VA_RESERVED_TRAP_SIZE to 64 KB and<br /> KFD_CWSR_TBA_TMA_SIZE to the AMD GPU page size. This means we reserve<br /> 64 KB for the trap in the address space, but only allocate 8 KB within<br /> it. With this approach, the allocation size never exceeds the reserved<br /> area.<br /> <br /> (cherry picked from commit 31b8de5e55666f26ea7ece5f412b83eab3f56dbb)