Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix mb_cache_entry&amp;#39;s e_refcnt leak in ext4_xattr_block_cache_find()<br /> <br /> Syzbot reports a warning as follows:<br /> <br /> ============================================<br /> WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290<br /> Modules linked in:<br /> CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7<br /> RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419<br /> Call Trace:<br /> <br /> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375<br /> generic_shutdown_super+0x136/0x2d0 fs/super.c:641<br /> kill_block_super+0x44/0x90 fs/super.c:1675<br /> ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327<br /> [...]<br /> ============================================<br /> <br /> This is because when finding an entry in ext4_xattr_block_cache_find(), if<br /> ext4_sb_bread() returns -ENOMEM, the ce&amp;#39;s e_refcnt, which has already grown<br /> in the __entry_find(), won&amp;#39;t be put away, and eventually trigger the above<br /> issue in mb_cache_destroy() due to reference count leakage.<br /> <br /> So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "xsk: Support redirect to any socket bound to the same umem"<br /> <br /> This reverts commit 2863d665ea41282379f108e4da6c8a2366ba66db.<br /> <br /> This patch introduced a potential kernel crash when multiple napi instances<br /> redirect to the same AF_XDP socket. By removing the queue_index check, it is<br /> possible for multiple napi instances to access the Rx ring at the same time,<br /> which will result in a corrupted ring state which can lead to a crash when<br /> flushing the rings in __xsk_flush(). This can happen when the linked list of<br /> sockets to flush gets corrupted by concurrent accesses. A quick and small fix<br /> is not possible, so let us revert this for now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix crash on racing fsync and size-extending write into prealloc<br /> <br /> We have been seeing crashes on duplicate keys in<br /> btrfs_set_item_key_safe():<br /> <br /> BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/ctree.c:2620!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]<br /> <br /> With the following stack trace:<br /> <br /> #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)<br /> #1 btrfs_drop_extents (fs/btrfs/file.c:411:4)<br /> #2 log_one_extent (fs/btrfs/tree-log.c:4732:9)<br /> #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)<br /> #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)<br /> #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)<br /> #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)<br /> #7 btrfs_sync_file (fs/btrfs/file.c:1933:8)<br /> #8 vfs_fsync_range (fs/sync.c:188:9)<br /> #9 vfs_fsync (fs/sync.c:202:9)<br /> #10 do_fsync (fs/sync.c:212:9)<br /> #11 __do_sys_fdatasync (fs/sync.c:225:9)<br /> #12 __se_sys_fdatasync (fs/sync.c:223:1)<br /> #13 __x64_sys_fdatasync (fs/sync.c:223:1)<br /> #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)<br /> #15 do_syscall_64 (arch/x86/entry/common.c:83:7)<br /> #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)<br /> <br /> So we&amp;#39;re logging a changed extent from fsync, which is splitting an<br /> extent in the log tree. But this split part already exists in the tree,<br /> triggering the BUG().<br /> <br /> This is the state of the log tree at the time of the crash, dumped with<br /> drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)<br /> to get more details than btrfs_print_leaf() gives us:<br /> <br /> &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])<br /> leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610<br /> leaf 33439744 flags 0x100000000000000<br /> fs uuid e5bd3946-400c-4223-8923-190ef1f18677<br /> chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da<br /> item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> generation 7 transid 9 size 8192 nbytes 8473563889606862198<br /> block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0<br /> sequence 204 flags 0x10(PREALLOC)<br /> atime 1716417703.220000000 (2024-05-22 15:41:43)<br /> ctime 1716417704.983333333 (2024-05-22 15:41:44)<br /> mtime 1716417704.983333333 (2024-05-22 15:41:44)<br /> otime 17592186044416.000000000 (559444-03-08 01:40:16)<br /> item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13<br /> index 195 namelen 3 name: 193<br /> item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37<br /> location key (0 UNKNOWN.0 0) type XATTR<br /> transid 7 data_len 1 name_len 6<br /> name: user.a<br /> data a<br /> item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53<br /> generation 9 type 1 (regular)<br /> extent data disk byte 303144960 nr 12288<br /> extent data offset 0 nr 4096 ram 12288<br /> extent compression 0 (none)<br /> item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53<br /> generation 9 type 2 (prealloc)<br /> prealloc data disk byte 303144960 nr 12288<br /> prealloc data offset 4096 nr 8192<br /> item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53<br /> generation 9 type 2 (prealloc)<br /> prealloc data disk byte 303144960 nr 12288<br /> prealloc data offset 8192 nr 4096<br /> ...<br /> <br /> So the real problem happened earlier: notice that items 4 (4k-12k) and 5<br /> (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and<br /> item 5 starts at i_size.<br /> <br /> Here is the state of <br /> ---truncated---

VMware ESXi contains an authentication bypass vulnerability. A malicious actor with sufficient Active Directory (AD) permissions can gain full access to an ESXi host that was previously configured to use AD for user management https://blogs.vmware.com/vsphere/2012/09/joining-vsphere-hosts-to-active-directory.html by re-creating the configured AD group (&amp;#39;ESXi Admins&amp;#39; by default) after it was deleted from AD.

VMware ESXi contains an out-of-bounds read vulnerability. A<br /> malicious actor with local administrative privileges on a virtual <br /> machine with an existing snapshot may trigger an out-of-bounds read <br /> leading to a denial-of-service condition of the host.

The vCenter Server contains a denial-of-service vulnerability. A malicious actor with network access to vCenter Server may create a denial-of-service condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential kernel bug due to lack of writeback flag waiting<br /> <br /> Destructive writes to a block device on which nilfs2 is mounted can cause<br /> a kernel bug in the folio/page writeback start routine or writeback end<br /> routine (__folio_start_writeback in the log below):<br /> <br /> kernel BUG at mm/page-writeback.c:3070!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> ...<br /> RIP: 0010:__folio_start_writeback+0xbaa/0x10e0<br /> Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff<br /> e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <br /> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00<br /> ...<br /> Call Trace:<br /> <br /> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]<br /> nilfs_segctor_construct+0x181/0x6b0 [nilfs2]<br /> nilfs_segctor_thread+0x548/0x11c0 [nilfs2]<br /> kthread+0x2f0/0x390<br /> ret_from_fork+0x4b/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> This is because when the log writer starts a writeback for segment summary<br /> blocks or a super root block that use the backing device&amp;#39;s page cache, it<br /> does not wait for the ongoing folio/page writeback, resulting in an<br /> inconsistent writeback state.<br /> <br /> Fix this issue by waiting for ongoing writebacks when putting<br /> folios/pages on the backing device into writeback state.

HCL Connections contains a broken access control vulnerability that may allow unauthorized user to update data in certain scenarios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/xen: Drop USERGS_SYSRET64 paravirt call<br /> <br /> commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.<br /> <br /> USERGS_SYSRET64 is used to return from a syscall via SYSRET, but<br /> a Xen PV guest will nevertheless use the IRET hypercall, as there<br /> is no sysret PV hypercall defined.<br /> <br /> So instead of testing all the prerequisites for doing a sysret and<br /> then mangling the stack for Xen PV again for doing an iret just use<br /> the iret exit from the beginning.<br /> <br /> This can easily be done via an ALTERNATIVE like it is done for the<br /> sysenter compat case already.<br /> <br /> It should be noted that this drops the optimization in Xen for not<br /> restoring a few registers when returning to user mode, but it seems<br /> as if the saved instructions in the kernel more than compensate for<br /> this drop (a kernel build in a Xen PV guest was slightly faster with<br /> this patch applied).<br /> <br /> While at it remove the stale sysret32 remnants.<br /> <br /> [ pawan: Brad Spengler and Salvatore Bonaccorso <br /> reported a problem with the 5.10 backport commit edc702b4a820<br /> ("x86/entry_64: Add VERW just before userspace transition").<br /> <br /> When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in<br /> syscall_return_via_sysret path as USERGS_SYSRET64 is runtime<br /> patched to:<br /> <br /> .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,<br /> 0x48, 0x0f, 0x07 }, // swapgs; sysretq<br /> <br /> which is missing CLEAR_CPU_BUFFERS. It turns out dropping<br /> USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS<br /> to be explicitly added to syscall_return_via_sysret path. Below<br /> is with CONFIG_PARAVIRT_XXL=y and this patch applied:<br /> <br /> syscall_return_via_sysret:<br /> ...<br /> : swapgs<br /> : xchg %ax,%ax<br /> : verw -0x1a2(%rip)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: lgdt3306a: Add a check against null-pointer-def<br /> <br /> The driver should check whether the client provides the platform_data.<br /> <br /> The following log reveals it:<br /> <br /> [ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40<br /> [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414<br /> [ 29.612820] Call Trace:<br /> [ 29.613030] <br /> [ 29.613201] dump_stack_lvl+0x56/0x6f<br /> [ 29.613496] ? kmemdup+0x30/0x40<br /> [ 29.613754] print_report.cold+0x494/0x6b7<br /> [ 29.614082] ? kmemdup+0x30/0x40<br /> [ 29.614340] kasan_report+0x8a/0x190<br /> [ 29.614628] ? kmemdup+0x30/0x40<br /> [ 29.614888] kasan_check_range+0x14d/0x1d0<br /> [ 29.615213] memcpy+0x20/0x60<br /> [ 29.615454] kmemdup+0x30/0x40<br /> [ 29.615700] lgdt3306a_probe+0x52/0x310<br /> [ 29.616339] i2c_device_probe+0x951/0xa90

A buffer overflow in PX4-Autopilot v1.12.3 allows attackers to cause a Denial of Service (DoS) via a crafted MavLink message.

PX4-Autopilot v1.14.3 was discovered to contain a buffer overflow via the topic_name parameter at /logger/logged_topics.cpp.