Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix oops due to invalid pointer for kfree() in parse_longname()<br /> <br /> This fixes a kernel oops when reading ceph snapshot directories (.snap),<br /> for example by simply running `ls /mnt/my_ceph/.snap`.<br /> <br /> The variable str is guarded by __free(kfree), but advanced by one for<br /> skipping the initial &amp;#39;_&amp;#39; in snapshot names. Thus, kfree() is called<br /> with an invalid pointer. This patch removes the need for advancing the<br /> pointer so kfree() is called with correct memory pointer.<br /> <br /> Steps to reproduce:<br /> <br /> 1. Create snapshots on a cephfs volume (I&amp;#39;ve 63 snaps in my testcase)<br /> <br /> 2. Add cephfs mount to fstab<br /> $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,_netdev 0 0" &gt;&gt; /etc/fstab<br /> <br /> 3. Reboot the system<br /> $ systemctl reboot<br /> <br /> 4. Check if it&amp;#39;s really mounted<br /> $ mount | grep stuff<br /> <br /> 5. List snapshots (expected 63 snapshots on my system)<br /> $ ls /mnt/test/stuff/.snap<br /> <br /> Now ls hangs forever and the kernel log shows the oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF<br /> <br /> syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6<br /> route. [0]<br /> <br /> Commit f72514b3c569 ("ipv6: clear RA flags when adding a static<br /> route") introduced logic to clear RTF_ADDRCONF from existing routes<br /> when a static route with the same nexthop is added. However, this<br /> causes a problem when the existing route has a gateway.<br /> <br /> When RTF_ADDRCONF is cleared from a route that has a gateway, that<br /> route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns<br /> true. The issue is that this route was never added to the<br /> fib6_siblings list.<br /> <br /> This leads to a mismatch between the following counts:<br /> <br /> - The sibling count computed by iterating fib6_next chain, which<br /> includes the newly ECMP-eligible route<br /> <br /> - The actual siblings in fib6_siblings list, which does not include<br /> that route<br /> <br /> When a subsequent ECMP route is added, fib6_add_rt2node() hits<br /> BUG_ON(sibling-&gt;fib6_nsiblings != rt-&gt;fib6_nsiblings) because the<br /> counts don&amp;#39;t match.<br /> <br /> Fix this by only clearing RTF_ADDRCONF when the existing route does<br /> not have a gateway. Routes without a gateway cannot qualify for ECMP<br /> anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing<br /> RTF_ADDRCONF on them is safe and matches the original intent of the<br /> commit.<br /> <br /> [0]:<br /> kernel BUG at net/ipv6/ip6_fib.c:1217!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217<br /> [...]<br /> Call Trace:<br /> <br /> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532<br /> __ip6_ins_rt net/ipv6/route.c:1351 [inline]<br /> ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946<br /> ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571<br /> inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577<br /> sock_do_ioctl+0xdc/0x300 net/socket.c:1245<br /> sock_ioctl+0x576/0x790 net/socket.c:1366<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> procfs: avoid fetching build ID while holding VMA lock<br /> <br /> Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock<br /> or per-VMA lock, whichever was used to lock VMA under question, to avoid<br /> deadlock reported by syzbot:<br /> <br /> -&gt; #1 (&amp;mm-&gt;mmap_lock){++++}-{4:4}:<br /> __might_fault+0xed/0x170<br /> _copy_to_iter+0x118/0x1720<br /> copy_page_to_iter+0x12d/0x1e0<br /> filemap_read+0x720/0x10a0<br /> blkdev_read_iter+0x2b5/0x4e0<br /> vfs_read+0x7f4/0xae0<br /> ksys_read+0x12a/0x250<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&gt; #0 (&amp;sb-&gt;s_type-&gt;i_mutex_key#8){++++}-{4:4}:<br /> __lock_acquire+0x1509/0x26d0<br /> lock_acquire+0x185/0x340<br /> down_read+0x98/0x490<br /> blkdev_read_iter+0x2a7/0x4e0<br /> __kernel_read+0x39a/0xa90<br /> freader_fetch+0x1d5/0xa80<br /> __build_id_parse.isra.0+0xea/0x6a0<br /> do_procmap_query+0xd75/0x1050<br /> procfs_procmap_ioctl+0x7a/0xb0<br /> __x64_sys_ioctl+0x18e/0x210<br /> do_syscall_64+0xcb/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> rlock(&amp;mm-&gt;mmap_lock);<br /> lock(&amp;sb-&gt;s_type-&gt;i_mutex_key#8);<br /> lock(&amp;mm-&gt;mmap_lock);<br /> rlock(&amp;sb-&gt;s_type-&gt;i_mutex_key#8);<br /> <br /> *** DEADLOCK ***<br /> <br /> This seems to be exacerbated (as we haven&amp;#39;t seen these syzbot reports<br /> before that) by the recent:<br /> <br /> 777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")<br /> <br /> To make this safe, we need to grab file refcount while VMA is still locked, but<br /> other than that everything is pretty straightforward. Internal build_id_parse()<br /> API assumes VMA is passed, but it only needs the underlying file reference, so<br /> just add another variant build_id_parse_file() that expects file passed<br /> directly.<br /> <br /> [akpm@linux-foundation.org: fix up kerneldoc]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: imx: preserve error state in block data length handler<br /> <br /> When a block read returns an invalid length, zero or &gt;I2C_SMBUS_BLOCK_MAX,<br /> the length handler sets the state to IMX_I2C_STATE_FAILED. However,<br /> i2c_imx_master_isr() unconditionally overwrites this with<br /> IMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns<br /> buffers and crashes the system.<br /> <br /> Guard the state transition to preserve error states set by the length<br /> handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: Intel-thc-hid: Intel-thc: Add safety check for reading DMA buffer<br /> <br /> Add DMA buffer readiness check before reading DMA buffer to avoid<br /> unexpected NULL pointer accessing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: correctly handle FDA objects of length zero<br /> <br /> Fix a bug where an empty FDA (fd array) object with 0 fds would cause an<br /> out-of-bounds error. The previous implementation used `skip == 0` to<br /> mean "this is a pointer fixup", but 0 is also the correct skip length<br /> for an empty FDA. If the FDA is at the end of the buffer, then this<br /> results in an attempt to write 8-bytes out of bounds. This is caught and<br /> results in an EINVAL error being returned to userspace.<br /> <br /> The pattern of using `skip == 0` as a special value originates from the<br /> C-implementation of Binder. As part of fixing this bug, this pattern is<br /> replaced with a Rust enum.<br /> <br /> I considered the alternate option of not pushing a fixup when the length<br /> is zero, but I think it&amp;#39;s cleaner to just get rid of the zero-is-special<br /> stuff.<br /> <br /> The root cause of this bug was diagnosed by Gemini CLI on first try. I<br /> used the following prompt:<br /> <br /> &gt; There appears to be a bug in @drivers/android/binder/thread.rs where<br /> &gt; the Fixups oob bug is triggered with 316 304 316 324. This implies<br /> &gt; that we somehow ended up with a fixup where buffer A has a pointer to<br /> &gt; buffer B, but the pointer is located at an index in buffer A that is<br /> &gt; out of bounds. Please investigate the code to find the bug. You may<br /> &gt; compare with @drivers/android/binder.c that implements this correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF in binder_netlink_report()<br /> <br /> Oneway transactions sent to frozen targets via binder_proc_transaction()<br /> return a BR_TRANSACTION_PENDING_FROZEN error but they are still treated<br /> as successful since the target is expected to thaw at some point. It is<br /> then not safe to access &amp;#39;t&amp;#39; after BR_TRANSACTION_PENDING_FROZEN errors<br /> as the transaction could have been consumed by the now thawed target.<br /> <br /> This is the case for binder_netlink_report() which derreferences &amp;#39;t&amp;#39;<br /> after a pending frozen error, as pointed out by the following KASAN<br /> report:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in binder_netlink_report.isra.0+0x694/0x6c8<br /> Read of size 8 at addr ffff00000f98ba38 by task binder-util/522<br /> <br /> CPU: 4 UID: 0 PID: 522 Comm: binder-util Not tainted 6.19.0-rc6-00015-gc03e9c42ae8f #1 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> binder_netlink_report.isra.0+0x694/0x6c8<br /> binder_transaction+0x66e4/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Allocated by task 522:<br /> __kmalloc_cache_noprof+0x17c/0x50c<br /> binder_transaction+0x584/0x79b8<br /> binder_thread_write+0xab4/0x4440<br /> binder_ioctl+0x1fd4/0x2940<br /> [...]<br /> <br /> Freed by task 488:<br /> kfree+0x1d0/0x420<br /> binder_free_transaction+0x150/0x234<br /> binder_thread_read+0x2d08/0x3ce4<br /> binder_ioctl+0x488/0x2940<br /> [...]<br /> ==================================================================<br /> <br /> Instead, make a transaction copy so the data can be safely accessed by<br /> binder_netlink_report() after a pending frozen error. While here, add a<br /> comment about not using t-&gt;buffer in binder_netlink_report().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: cancel mlo_scan_start_wk<br /> <br /> mlo_scan_start_wk is not canceled on disconnection. In fact, it is not<br /> canceled anywhere except in the restart cleanup, where we don&amp;#39;t really<br /> have to.<br /> <br /> This can cause an init-after-queue issue: if, for example, the work was<br /> queued and then drv_change_interface got executed.<br /> <br /> This can also cause use-after-free: if the work is executed after the<br /> vif is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: aloop: Fix racy access at PCM trigger<br /> <br /> The PCM trigger callback of aloop driver tries to check the PCM state<br /> and stop the stream of the tied substream in the corresponding cable.<br /> Since both check and stop operations are performed outside the cable<br /> lock, this may result in UAF when a program attempts to trigger<br /> frequently while opening/closing the tied stream, as spotted by<br /> fuzzers.<br /> <br /> For addressing the UAF, this patch changes two things:<br /> - It covers the most of code in loopback_check_format() with<br /> cable-&gt;lock spinlock, and add the proper NULL checks. This avoids<br /> already some racy accesses.<br /> - In addition, now we try to check the state of the capture PCM stream<br /> that may be stopped in this function, which was the major pain point<br /> leading to UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()<br /> <br /> The acpi_power_meter driver&amp;#39;s .notify() callback function,<br /> acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock<br /> that is also acquired by callbacks in sysfs attributes of the device<br /> being unregistered which is prone to deadlocks between sysfs access and<br /> device removal.<br /> <br /> Address this by moving the hwmon device removal in<br /> acpi_power_meter_notify() outside the lock in question, but notice<br /> that doing it alone is not sufficient because two concurrent<br /> METER_NOTIFY_CONFIG notifications may be attempting to remove the<br /> same device at the same time. To prevent that from happening, add a<br /> new lock serializing the execution of the switch () statement in<br /> acpi_power_meter_notify(). For simplicity, it is a static mutex<br /> which should not be a problem from the performance perspective.<br /> <br /> The new lock also allows the hwmon_device_register_with_info()<br /> in acpi_power_meter_notify() to be called outside the inner lock<br /> because it prevents the other notifications handled by that function<br /> from manipulating the "resource" object while the hwmon device based<br /> on it is being registered. The sending of ACPI netlink messages from<br /> acpi_power_meter_notify() is serialized by the new lock too which<br /> generally helps to ensure that the order of handling firmware<br /> notifications is the same as the order of sending netlink messages<br /> related to them.<br /> <br /> In addition, notice that hwmon_device_register_with_info() may fail<br /> in which case resource-&gt;hwmon_dev will become an error pointer,<br /> so add checks to avoid attempting to unregister the hwmon device<br /> pointer to by it in that case to acpi_power_meter_notify() and<br /> acpi_power_meter_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: fix memory leak in acp3x pdm dma ops

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix NULL pointer dereference in ceph_mds_auth_match()<br /> <br /> The CephFS kernel client has regression starting from 6.18-rc1.<br /> We have issue in ceph_mds_auth_match() if fs_name == NULL:<br /> <br /> const char fs_name = mdsc-&gt;fsc-&gt;mount_options-&gt;mds_namespace;<br /> ...<br /> if (auth-&gt;match.fs_name &amp;&amp; strcmp(auth-&gt;match.fs_name, fs_name)) {<br /> / fsname mismatch, try next one */<br /> return 0;<br /> }<br /> <br /> Patrick Donnelly suggested that: In summary, we should definitely start<br /> decoding `fs_name` from the MDSMap and do strict authorizations checks<br /> against it. Note that the `-o mds_namespace=foo` should only be used for<br /> selecting the file system to mount and nothing else. It&amp;#39;s possible<br /> no mds_namespace is specified but the kernel will mount the only<br /> file system that exists which may have name "foo".<br /> <br /> This patch reworks ceph_mdsmap_decode() and namespace_equals() with<br /> the goal of supporting the suggested concept. Now struct ceph_mdsmap<br /> contains m_fs_name field that receives copy of extracted FS name<br /> by ceph_extract_encoded_string(). For the case of "old" CephFS file<br /> systems, it is used "cephfs" name.<br /> <br /> [ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(),<br /> get rid of a series of strlen() calls in ceph_namespace_match(),<br /> drop changes to namespace_equals() body to avoid treating empty<br /> mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap()<br /> as namespace_equals() isn&amp;#39;t an equivalent substitution there ]