Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: protect updates of 64-bit statistics counters<br /> <br /> As explained by a comment in , write side of struct<br /> u64_stats_sync must ensure mutual exclusion, or one seqcount update could<br /> be lost on 32-bit platforms, thus blocking readers forever. Such lockups<br /> have been observed in real world after stmmac_xmit() on one CPU raced with<br /> stmmac_napi_poll_tx() on another CPU.<br /> <br /> To fix the issue without introducing a new lock, split the statics into<br /> three parts:<br /> <br /> 1. fields updated only under the tx queue lock,<br /> 2. fields updated only during NAPI poll,<br /> 3. fields updated only from interrupt context,<br /> <br /> Updates to fields in the first two groups are already serialized through<br /> other locks. It is sufficient to split the existing struct u64_stats_sync<br /> so that each group has its own.<br /> <br /> Note that tx_set_ic_bit is updated from both contexts. Split this counter<br /> so that each context gets its own, and calculate their sum to get the total<br /> value in stmmac_get_ethtool_stats().<br /> <br /> For the third group, multiple interrupts may be processed by different CPUs<br /> at the same time, but interrupts on the same CPU will not nest. Move fields<br /> from this group to a newly created per-cpu struct stmmac_pcpu_stats.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix circular locking dependency<br /> <br /> The rule inside kvm enforces that the vcpu-&gt;mutex is taken *inside*<br /> kvm-&gt;lock. The rule is violated by the pkvm_create_hyp_vm() which acquires<br /> the kvm-&gt;lock while already holding the vcpu-&gt;mutex lock from<br /> kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by<br /> protecting the hyp vm handle with the config_lock, much like we already<br /> do for other forms of VM-scoped data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Fix regression in writes when non-standard maximum write size negotiated<br /> <br /> The conversion to netfs in the 6.3 kernel caused a regression when<br /> maximum write size is set by the server to an unexpected value which is<br /> not a multiple of 4096 (similarly if the user overrides the maximum<br /> write size by setting mount parm "wsize", but sets it to a value that<br /> is not a multiple of 4096). When negotiated write size is not a<br /> multiple of 4096 the netfs code can skip the end of the final<br /> page when doing large sequential writes, causing data corruption.<br /> <br /> This section of code is being rewritten/removed due to a large<br /> netfs change, but until that point (ie for the 6.3 kernel until now)<br /> we can not support non-standard maximum write sizes.<br /> <br /> Add a warning if a user specifies a wsize on mount that is not<br /> a multiple of 4096 (and round down), also add a change where we<br /> round down the maximum write size if the server negotiates a value<br /> that is not a multiple of 4096 (we also have to check to make sure that<br /> we do not round it down to zero).