Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad4130: zero-initialize clock init data<br /> <br /> The clk_init_data struct does not have all its members<br /> initialized, causing issues when trying to expose the internal<br /> clock on the CLK pin.<br /> <br /> Fix this by zero-initializing the clk_init_data struct.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: qcom: sc8180x: Mark CO0 BCM keepalive<br /> <br /> The CO0 BCM needs to be up at all times, otherwise some hardware (like<br /> the UFS controller) loses its connection to the rest of the SoC,<br /> resulting in a hang of the platform, accompanied by a spectacular<br /> logspam.<br /> <br /> Mark it as keepalive to prevent such cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend<br /> <br /> In current scenario if Plug-out and Plug-In performed continuously<br /> there could be a chance while checking for dwc-&gt;gadget_driver in<br /> dwc3_gadget_suspend, a NULL pointer dereference may occur.<br /> <br /> Call Stack:<br /> <br /> CPU1: CPU2:<br /> gadget_unbind_driver dwc3_suspend_common<br /> dwc3_gadget_stop dwc3_gadget_suspend<br /> dwc3_disconnect_gadget<br /> <br /> CPU1 basically clears the variable and CPU2 checks the variable.<br /> Consider CPU1 is running and right before gadget_driver is cleared<br /> and in parallel CPU2 executes dwc3_gadget_suspend where it finds<br /> dwc-&gt;gadget_driver which is not NULL and resumes execution and then<br /> CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where<br /> it checks dwc-&gt;gadget_driver is already NULL because of which the<br /> NULL pointer deference occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: core: Prevent null pointer dereference in update_port_device_state<br /> <br /> Currently, the function update_port_device_state gets the usb_hub from<br /> udev-&gt;parent by calling usb_hub_to_struct_hub.<br /> However, in case the actconfig or the maxchild is 0, the usb_hub would<br /> be NULL and upon further accessing to get port_dev would result in null<br /> pointer dereference.<br /> <br /> Fix this by introducing an if check after the usb_hub is populated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: i2c-hid-of: fix NULL-deref on failed power up<br /> <br /> A while back the I2C HID implementation was split in an ACPI and OF<br /> part, but the new OF driver never initialises the client pointer which<br /> is dereferenced on power-up failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau: offload fence uevents work to workqueue<br /> <br /> This should break the deadlock between the fctx lock and the irq lock.<br /> <br /> This offloads the processing off the work from the irq into a workqueue.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix double-free of blocks due to wrong extents moved_len<br /> <br /> In ext4_move_extents(), moved_len is only updated when all moves are<br /> successfully executed, and only discards orig_inode and donor_inode<br /> preallocations when moved_len is not zero. When the loop fails to exit<br /> after successfully moving some extents, moved_len is not updated and<br /> remains at 0, so it does not discard the preallocations.<br /> <br /> If the moved extents overlap with the preallocated extents, the<br /> overlapped extents are freed twice in ext4_mb_release_inode_pa() and<br /> ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:<br /> Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is<br /> incremented twice. Hence when trim is executed, a zero-division bug is<br /> triggered in mb_update_avg_fragment_size() because bb_free is not zero<br /> and bb_fragments is zero.<br /> <br /> Therefore, update move_len after each extent move to avoid the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix random data corruption from exception handler<br /> <br /> The current exception handler implementation, which assists when accessing<br /> user space memory, may exhibit random data corruption if the compiler decides<br /> to use a different register than the specified register %r29 (defined in<br /> ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another<br /> register, the fault handler will nevertheless store -EFAULT into %r29 and thus<br /> trash whatever this register is used for.<br /> Looking at the assembly I found that this happens sometimes in emulate_ldd().<br /> <br /> To solve the issue, the easiest solution would be if it somehow is<br /> possible to tell the fault handler which register is used to hold the error<br /> code. Using %0 or %1 in the inline assembly is not posssible as it will show<br /> up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not<br /> convert to an integer.<br /> <br /> This patch takes another, better and more flexible approach:<br /> We extend the __ex_table (which is out of the execution path) by one 32-word.<br /> In this word we tell the compiler to insert the assembler instruction<br /> "or %r0,%r0,%reg", where %reg references the register which the compiler<br /> choosed for the error return code.<br /> In case of an access failure, the fault handler finds the __ex_table entry and<br /> can examine the opcode. The used register is encoded in the lowest 5 bits, and<br /> the fault handler can then store -EFAULT into this register.<br /> <br /> Since we extend the __ex_table to 3 words we can&amp;#39;t use the BUILDTIME_TABLE_SORT<br /> config option any longer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kasan: Fix addr error caused by page alignment<br /> <br /> In kasan_init_region, when k_start is not page aligned, at the begin of<br /> for loop, k_cur = k_start &amp; PAGE_MASK is less than k_start, and then<br /> `va = block + k_cur - k_start` is less than block, the addr va is invalid,<br /> because the memory address space from va to block is not alloced by<br /> memblock_alloc, which will not be reserved by memblock_reserve later, it<br /> will be used by other places.<br /> <br /> As a result, memory overwriting occurs.<br /> <br /> for example:<br /> int __init __weak kasan_init_region(void *start, size_t size)<br /> {<br /> [...]<br /> /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */<br /> block = memblock_alloc(k_end - k_start, PAGE_SIZE);<br /> [...]<br /> for (k_cur = k_start &amp; PAGE_MASK; k_cur

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-crypt, dm-verity: disable tasklets<br /> <br /> Tasklets have an inherent problem with memory corruption. The function<br /> tasklet_action_common calls tasklet_trylock, then it calls the tasklet<br /> callback and then it calls tasklet_unlock. If the tasklet callback frees<br /> the structure that contains the tasklet or if it calls some code that may<br /> free it, tasklet_unlock will write into free memory.<br /> <br /> The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but<br /> it is not a sufficient fix and the data corruption can still happen [1].<br /> There is no fix for dm-verity and dm-verity will write into free memory<br /> with every tasklet-processed bio.<br /> <br /> There will be atomic workqueues implemented in the kernel 6.9 [2]. They<br /> will have better interface and they will not suffer from the memory<br /> corruption problem.<br /> <br /> But we need something that stops the memory corruption now and that can be<br /> backported to the stable kernels. So, I&amp;#39;m proposing this commit that<br /> disables tasklets in both dm-crypt and dm-verity. This commit doesn&amp;#39;t<br /> remove the tasklet support, because the tasklet code will be reused when<br /> atomic workqueues will be implemented.<br /> <br /> [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/<br /> [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/