Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: really cope with fastopen race<br /> <br /> Fastopen and PM-trigger subflow shutdown can race, as reported by<br /> syzkaller.<br /> <br /> In my first attempt to close such race, I missed the fact that<br /> the subflow status can change again before the subflow_state_change<br /> callback is invoked.<br /> <br /> Address the issue additionally copying with all the states directly<br /> reachable from TCP_FIN_WAIT1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/iommu: Fix the missing iommu_group_put() during platform domain attach<br /> <br /> The function spapr_tce_platform_iommu_attach_dev() is missing to call<br /> iommu_group_put() when the domain is already set. This refcount leak<br /> shows up with BUG_ON() during DLPAR remove operation as:<br /> <br /> KernelBug: Kernel bug in state &amp;#39;None&amp;#39;: kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries<br /> <br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries<br /> NIP: c0000000000ff4d4 LR: c0000000000ff4cc CTR: 0000000000000000<br /> REGS: c0000013aed5f840 TRAP: 0700 Tainted: G I (6.8.0-rc3-autotest-g99bd3cb0d12e)<br /> MSR: 8000000000029033 CR: 44002402 XER: 20040000<br /> CFAR: c000000000a0d170 IRQMASK: 0<br /> ...<br /> NIP iommu_reconfig_notifier+0x94/0x200<br /> LR iommu_reconfig_notifier+0x8c/0x200<br /> Call Trace:<br /> iommu_reconfig_notifier+0x8c/0x200 (unreliable)<br /> notifier_call_chain+0xb8/0x19c<br /> blocking_notifier_call_chain+0x64/0x98<br /> of_reconfig_notify+0x44/0xdc<br /> of_detach_node+0x78/0xb0<br /> ofdt_write.part.0+0x86c/0xbb8<br /> proc_reg_write+0xf4/0x150<br /> vfs_write+0xf8/0x488<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x138/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> The patch adds the missing iommu_group_put() call.

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.

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

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 /> 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/

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.