Vulnerabilities

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 ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: r8152: fix resume reset deadlock<br /> <br /> rtl8152 can trigger device reset during reset which<br /> potentially can result in a deadlock:<br /> <br /> **** DPM device timeout after 10 seconds; 15 seconds until panic ****<br /> Call Trace:<br /> <br /> schedule+0x483/0x1370<br /> schedule_preempt_disabled+0x15/0x30<br /> __mutex_lock_common+0x1fd/0x470<br /> __rtl8152_set_mac_address+0x80/0x1f0<br /> dev_set_mac_address+0x7f/0x150<br /> rtl8152_post_reset+0x72/0x150<br /> usb_reset_device+0x1d0/0x220<br /> rtl8152_resume+0x99/0xc0<br /> usb_resume_interface+0x3e/0xc0<br /> usb_resume_both+0x104/0x150<br /> usb_resume+0x22/0x110<br /> <br /> The problem is that rtl8152 resume calls reset under<br /> tp-&gt;control mutex while reset basically re-enters rtl8152<br /> and attempts to acquire the same tp-&gt;control lock once<br /> again.<br /> <br /> Reset INACCESSIBLE device outside of tp-&gt;control mutex<br /> scope to avoid recursive mutex_lock() deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc-&gt;domains<br /> <br /> Fix out-of-range access of bc-&gt;domains in imx8m_blk_ctrl_remove().