Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/kasan: Limit KASAN thread size increase to 32KB<br /> <br /> KASAN is seen to increase stack usage, to the point that it was reported<br /> to lead to stack overflow on some 32-bit machines (see link).<br /> <br /> To avoid overflows the stack size was doubled for KASAN builds in<br /> commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with<br /> KASAN").<br /> <br /> However with a 32KB stack size to begin with, the doubling leads to a<br /> 64KB stack, which causes build errors:<br /> arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff)<br /> <br /> Although the asm could be reworked, in practice a 32KB stack seems<br /> sufficient even for KASAN builds - the additional usage seems to be in<br /> the 2-3KB range for a 64-bit KASAN build.<br /> <br /> So only increase the stack for KASAN if the stack size is

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential bug in end_buffer_async_write<br /> <br /> According to a syzbot report, end_buffer_async_write(), which handles the<br /> completion of block device writes, may detect abnormal condition of the<br /> buffer async_write flag and cause a BUG_ON failure when using nilfs2.<br /> <br /> Nilfs2 itself does not use end_buffer_async_write(). But, the async_write<br /> flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue<br /> with race condition of competition between segments for dirty blocks") as<br /> a means of resolving double list insertion of dirty blocks in<br /> nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the<br /> resulting crash.<br /> <br /> This modification is safe as long as it is used for file data and b-tree<br /> node blocks where the page caches are independent. However, it was<br /> irrelevant and redundant to also introduce async_write for segment summary<br /> and super root blocks that share buffers with the backing device. This<br /> led to the possibility that the BUG_ON check in end_buffer_async_write<br /> would fail as described above, if independent writebacks of the backing<br /> device occurred in parallel.<br /> <br /> The use of async_write for segment summary buffers has already been<br /> removed in a previous change.<br /> <br /> Fix this issue by removing the manipulation of the async_write flag for<br /> the remaining super root block buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/events: close evtchn after mapping cleanup<br /> <br /> shutdown_pirq and startup_pirq are not taking the<br /> irq_mapping_update_lock because they can&amp;#39;t due to lock inversion. Both<br /> are called with the irq_desc-&gt;lock being taking. The lock order,<br /> however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.<br /> <br /> This opens multiple races:<br /> - shutdown_pirq can be interrupted by a function that allocates an event<br /> channel:<br /> <br /> CPU0 CPU1<br /> shutdown_pirq {<br /> xen_evtchn_close(e)<br /> __startup_pirq {<br /> EVTCHNOP_bind_pirq<br /> -&gt; returns just freed evtchn e<br /> set_evtchn_to_irq(e, irq)<br /> }<br /> xen_irq_info_cleanup() {<br /> set_evtchn_to_irq(e, -1)<br /> }<br /> }<br /> <br /> Assume here event channel e refers here to the same event channel<br /> number.<br /> After this race the evtchn_to_irq mapping for e is invalid (-1).<br /> <br /> - __startup_pirq races with __unbind_from_irq in a similar way. Because<br /> __startup_pirq doesn&amp;#39;t take irq_mapping_update_lock it can grab the<br /> evtchn that __unbind_from_irq is currently freeing and cleaning up. In<br /> this case even though the event channel is allocated, its mapping can<br /> be unset in evtchn_to_irq.<br /> <br /> The fix is to first cleanup the mappings and then close the event<br /> channel. In this way, when an event channel gets allocated it&amp;#39;s<br /> potential previous evtchn_to_irq mappings are guaranteed to be unset already.<br /> This is also the reverse order of the allocation where first the event<br /> channel is allocated and then the mappings are setup.<br /> <br /> On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal<br /> [un]bind interfaces"), we hit a BUG like the following during probing of NVMe<br /> devices. The issue is that during nvme_setup_io_queues, pci_free_irq<br /> is called for every device which results in a call to shutdown_pirq.<br /> With many nvme devices it&amp;#39;s therefore likely to hit this race during<br /> boot because there will be multiple calls to shutdown_pirq and<br /> startup_pirq are running potentially in parallel.<br /> <br /> ------------[ cut here ]------------<br /> blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled<br /> kernel BUG at drivers/xen/events/events_base.c:499!<br /> invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1<br /> Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006<br /> Workqueue: nvme-reset-wq nvme_reset_work<br /> RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0<br /> Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00<br /> RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006<br /> RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff<br /> RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed<br /> R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002<br /> FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? show_trace_log_lvl+0x1c1/0x2d9<br /> ? show_trace_log_lvl+0x1c1/0x2d9<br /> ? set_affinity_irq+0xdc/0x1c0<br /> ? __die_body.cold+0x8/0xd<br /> ? die+0x2b/0x50<br /> ? do_trap+0x90/0x110<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? do_error_trap+0x65/0x80<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? exc_invalid_op+0x4e/0x70<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? bind_evtchn_to_cpu+0xdf/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super<br /> <br /> When configuring a hugetlb filesystem via the fsconfig() syscall, there is<br /> a possible NULL dereference in hugetlbfs_fill_super() caused by assigning<br /> NULL to ctx-&gt;hstate in hugetlbfs_parse_param() when the requested pagesize<br /> is non valid.<br /> <br /> E.g: Taking the following steps:<br /> <br /> fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);<br /> fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);<br /> fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);<br /> <br /> Given that the requested "pagesize" is invalid, ctxt-&gt;hstate will be replaced<br /> with NULL, losing its previous value, and we will print an error:<br /> <br /> ...<br /> ...<br /> case Opt_pagesize:<br /> ps = memparse(param-&gt;string, &amp;rest);<br /> ctx-&gt;hstate = h;<br /> if (!ctx-&gt;hstate) {<br /> pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);<br /> return -EINVAL;<br /> }<br /> return 0;<br /> ...<br /> ...<br /> <br /> This is a problem because later on, we will dereference ctxt-&gt;hstate in<br /> hugetlbfs_fill_super()<br /> <br /> ...<br /> ...<br /> sb-&gt;s_blocksize = huge_page_size(ctx-&gt;hstate);<br /> ...<br /> ...<br /> <br /> Causing below Oops.<br /> <br /> Fix this by replacing cxt-&gt;hstate value only when then pagesize is known<br /> to be valid.<br /> <br /> kernel: hugetlbfs: Unsupported page size 0 MB<br /> kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> kernel: #PF: supervisor read access in kernel mode<br /> kernel: #PF: error_code(0x0000) - not-present page<br /> kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0<br /> kernel: Oops: 0000 [#1] PREEMPT SMP PTI<br /> kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f<br /> kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017<br /> kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0<br /> kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28<br /> kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246<br /> kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004<br /> kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000<br /> kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004<br /> kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000<br /> kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400<br /> kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000<br /> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: ? __die_body+0x1a/0x60<br /> kernel: ? page_fault_oops+0x16f/0x4a0<br /> kernel: ? search_bpf_extables+0x65/0x70<br /> kernel: ? fixup_exception+0x22/0x310<br /> kernel: ? exc_page_fault+0x69/0x150<br /> kernel: ? asm_exc_page_fault+0x22/0x30<br /> kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10<br /> kernel: ? hugetlbfs_fill_super+0xb4/0x1a0<br /> kernel: ? hugetlbfs_fill_super+0x28/0x1a0<br /> kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10<br /> kernel: vfs_get_super+0x40/0xa0<br /> kernel: ? __pfx_bpf_lsm_capable+0x10/0x10<br /> kernel: vfs_get_tree+0x25/0xd0<br /> kernel: vfs_cmd_create+0x64/0xe0<br /> kernel: __x64_sys_fsconfig+0x395/0x410<br /> kernel: do_syscall_64+0x80/0x160<br /> kernel: ? syscall_exit_to_user_mode+0x82/0x240<br /> kernel: ? do_syscall_64+0x8d/0x160<br /> kernel: ? syscall_exit_to_user_mode+0x82/0x240<br /> kernel: ? do_syscall_64+0x8d/0x160<br /> kernel: ? exc_page_fault+0x69/0x150<br /> kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> kernel: RIP: 0033:0x7ffbc0cb87c9<br /> kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48<br /> kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af<br /> kernel: RAX: fffffffffff<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: prevent use-after-free in encode_cap_msg()<br /> <br /> In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was<br /> caught by KASAN at this line - &amp;#39;ceph_buffer_get(arg-&gt;xattr_buf);&amp;#39;. This<br /> implies before the refcount could be increment here, it was freed.<br /> <br /> In same file, in "handle_cap_grant()" refcount is decremented by this<br /> line - &amp;#39;ceph_buffer_put(ci-&gt;i_xattrs.blob);&amp;#39;. It appears that a race<br /> occurred and resource was freed by the latter line before the former<br /> line could increment it.<br /> <br /> encode_cap_msg() is called by __send_cap() and __send_cap() is called by<br /> ceph_check_caps() after calling __prep_cap(). __prep_cap() is where<br /> arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where<br /> the refcount must be increased to prevent "use after free" error.