Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo<br /> <br /> Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case<br /> pattern_len is equal to zero and the device FIFO is not empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: mtk-pmic-keys - fix possible null pointer dereference<br /> <br /> In mtk_pmic_keys_probe, the regs parameter is only set if the button is<br /> parsed in the device tree. However, on hardware where the button is left<br /> floating, that node will most likely be removed not to enable that<br /> input. In that case the code will try to dereference a null pointer.<br /> <br /> Let&amp;#39;s use the regs struct instead as it is defined for all supported<br /> platforms. Note that it is ok setting the key reg even if that latter is<br /> disabled as the interrupt won&amp;#39;t be enabled anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL<br /> <br /> When userspace does PR_SET_TAGGED_ADDR_CTRL, but Supm extension is not<br /> available, the kernel crashes:<br /> <br /> Oops - illegal instruction [#1]<br /> [snip]<br /> epc : set_tagged_addr_ctrl+0x112/0x15a<br /> ra : set_tagged_addr_ctrl+0x74/0x15a<br /> epc : ffffffff80011ace ra : ffffffff80011a30 sp : ffffffc60039be10<br /> [snip]<br /> status: 0000000200000120 badaddr: 0000000010a79073 cause: 0000000000000002<br /> set_tagged_addr_ctrl+0x112/0x15a<br /> __riscv_sys_prctl+0x352/0x73c<br /> do_trap_ecall_u+0x17c/0x20c<br /> andle_exception+0x150/0x15c<br /> <br /> Fix it by checking if Supm is available.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix invalid context error in dml helper<br /> <br /> [Why]<br /> "BUG: sleeping function called from invalid context" error.<br /> after:<br /> "drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()"<br /> <br /> The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag<br /> for memory allocation, which shouldn&amp;#39;t be used in atomic contexts.<br /> <br /> The allocation is needed only for using another helper function<br /> get_scaler_data_for_plane().<br /> <br /> [How]<br /> Modify helpers to pass a pointer to scaler_data within existing context,<br /> eliminating the need for dynamic memory allocation/deallocation<br /> and copying.<br /> <br /> (cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259)

Password guessing limits could be bypassed when using LDAP authentication.

Failed login response could be different depending on whether the username was local or central.

OpenFlow discovery protocol can exhaust resources because it is not rate limited

Improper limitation of pathname in Circuit Provisioning and File Import applications allows modification and uploading of files

An authenticated user can modify application state data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memblock: Accept allocated memory before use in memblock_double_array()<br /> <br /> When increasing the array size in memblock_double_array() and the slab<br /> is not yet available, a call to memblock_find_in_range() is used to<br /> reserve/allocate memory. However, the range returned may not have been<br /> accepted, which can result in a crash when booting an SNP guest:<br /> <br /> RIP: 0010:memcpy_orig+0x68/0x130<br /> Code: ...<br /> RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006<br /> RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000<br /> RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00<br /> RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000<br /> R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78<br /> R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00<br /> memblock_double_array+0xff/0x310<br /> memblock_add_range+0x1fb/0x2f0<br /> memblock_reserve+0x4f/0xa0<br /> memblock_alloc_range_nid+0xac/0x130<br /> memblock_alloc_internal+0x53/0xc0<br /> memblock_alloc_try_nid+0x3d/0xa0<br /> swiotlb_init_remap+0x149/0x2f0<br /> mem_init+0xb/0xb0<br /> mm_core_init+0x8f/0x350<br /> start_kernel+0x17e/0x5d0<br /> x86_64_start_reservations+0x14/0x30<br /> x86_64_start_kernel+0x92/0xa0<br /> secondary_startup_64_no_verify+0x194/0x19b<br /> <br /> Mitigate this by calling accept_memory() on the memory range returned<br /> before the slab is available.<br /> <br /> Prior to v6.12, the accept_memory() interface used a &amp;#39;start&amp;#39; and &amp;#39;end&amp;#39;<br /> parameter instead of &amp;#39;start&amp;#39; and &amp;#39;size&amp;#39;, therefore the accept_memory()<br /> call must be adjusted to specify &amp;#39;start + size&amp;#39; for &amp;#39;end&amp;#39; when applying<br /> to kernels prior to v6.12.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix memory leak in parse_lease_state()<br /> <br /> The previous patch that added bounds check for create lease context<br /> introduced a memory leak. When the bounds check fails, the function<br /> returns NULL without freeing the previously allocated lease_ctx_info<br /> structure.<br /> <br /> This patch fixes the issue by adding kfree(lreq) before returning NULL<br /> in both boundary check cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users<br /> <br /> Support for eBPF programs loaded by unprivileged users is typically<br /> disabled. This means only cBPF programs need to be mitigated for BHB.<br /> <br /> In addition, only mitigate cBPF programs that were loaded by an<br /> unprivileged user. Privileged users can also load the same program<br /> via eBPF, making the mitigation pointless.