Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/mlx5: Fix racy bitfields and tighten struct layout<br /> <br /> Bitfield operations are not atomic, they use a read-modify-write<br /> pattern, therefore we should be careful not to pack bitfields that<br /> can be concurrently updated into the same storage unit.<br /> <br /> This split takes a binary approach: flags that are only modified<br /> pre/post open/close remain bitfields, flags modified from user<br /> action, including actions that reach across to another device (ex.<br /> reset) use dedicated storage units.<br /> <br /> Note mlx5_vhca_page_tracker.status is relocated to fill the alignment<br /> hole this split exposes.<br /> <br /> Bitfield justifications:<br /> <br /> migrate_cap: written only in mlx5vf_cmd_set_migratable() at probe<br /> chunk_mode: written only in mlx5vf_cmd_set_migratable() at probe<br /> mig_state_cap: written only in mlx5vf_cmd_set_migratable() at probe<br /> <br /> Dedicated storage units:<br /> <br /> mdev_detach: written in the VF attach/detach event notifier<br /> mlx5fv_vf_event() at runtime<br /> log_active: written in mlx5vf_start_page_tracker()/<br /> mlx5vf_stop_page_tracker() during runtime dirty tracking<br /> deferred_reset: written in mlx5vf_state_mutex_unlock()/<br /> mlx5vf_pci_aer_reset_done() during runtime reset handling<br /> is_err: set by tracker error handling and dirty-log polling at runtime<br /> object_changed: set by tracker event handling and cleared by dirty-log<br /> polling at runtime

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio: Remove device debugfs before releasing devres<br /> <br /> VFIO device debugfs files created with debugfs_create_devm_seqfile()<br /> store a devres allocated debugfs_devm_entry as inode private data.<br /> vfio_unregister_group_dev() currently calls vfio_device_del() before<br /> vfio_device_debugfs_exit(), but device_del() releases devres. This can<br /> leave debugfs entries visible with stale inode private data while<br /> unregister waits for userspace references to drain.<br /> <br /> Remove the per-device debugfs tree before vfio_device_del(). The debugfs<br /> view is diagnostic only, so losing it at the start of unregister is<br /> preferable to preserving entries whose backing storage may already have<br /> been released.<br /> <br /> Complete the teardown by clearing the per-device debugfs root after<br /> removal. This matches the global debugfs root cleanup and prevents<br /> future users from mistaking a removed dentry for a live debugfs tree<br /> during the remainder of unregister.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc<br /> <br /> vfio_mig_get_next_state() walks vfio_from_fsm_table[] one step at a time,<br /> looping to skip optional states the device does not support until<br /> *next_fsm is supported. A blocked transition is encoded as<br /> VFIO_DEVICE_STATE_ERROR, which the trailing return reports as -EINVAL.<br /> <br /> The skip loop does not account for the ERROR sentinel.<br /> state_flags_table[ERROR] is ~0U and vfio_from_fsm_table[ERROR][*] is<br /> ERROR, so once *next_fsm becomes ERROR the loop condition stays true and<br /> *next_fsm never changes. The blocked arcs STOP_COPY -&gt; PRE_COPY and<br /> STOP_COPY -&gt; PRE_COPY_P2P map to ERROR yet pass the support check on a<br /> precopy-capable device, causing the loop to spin forever while holding<br /> the driver state mutex. This can result in a soft lockup, and a panic<br /> with softlockup_panic set.<br /> <br /> Terminate the skip loop on the ERROR sentinel so a blocked transition<br /> falls through to the existing return and reports -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: use a u64 stride when cleaning up the offsets array<br /> <br /> Allocation&amp;#39;s Drop walks the offsets array (binder_size_t = u64 entries),<br /> cleaning up the objects, but it used usize instead of u64 for both the<br /> stride and the per-entry read.<br /> <br /> On 64-bit kernels (usize == u64) this is harmless, but on 32-bit kernels<br /> it walks the 8-byte entries in 4-byte steps, iterating an N-entry array<br /> 2N times, and reads the always-zero high word as offset 0, cleaning up<br /> the object at offset 0 N extra times. As a result the referenced node or<br /> handle ends up with a lower reference count than it actually has (a<br /> refcount over-decrement), and binder&amp;#39;s reference accounting is corrupted;<br /> for example, the owner can be notified of a strong reference release<br /> (BR_RELEASE) even though references still remain.<br /> <br /> Change the stride to u64, and read each entry as a u64, narrowing it to<br /> usize with try_into().<br /> <br /> On 32-bit ARM, when this over-decrement would drive a count below zero,<br /> the driver&amp;#39;s existing refcount guard refuses it and fires:<br /> <br /> rust_binder: Failure: refcount underflow!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF in binder_free_transaction()<br /> <br /> In binder_free_transaction(), the t-&gt;to_proc is read under the t-&gt;lock.<br /> However, once the t-&gt;lock is dropped, the to_proc can die in parallel.<br /> This leads to a use-after-free error when we attempt to acquire its<br /> inner lock right afterwards:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0<br /> Write of size 4 at addr ffff00001125da70 by task B/672<br /> <br /> CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> _raw_spin_lock+0xe4/0x1a0<br /> binder_free_transaction+0x8c/0x320<br /> binder_send_failed_reply+0x21c/0x2f8<br /> binder_thread_release+0x488/0x7e0<br /> binder_ioctl+0x12c0/0x29a0<br /> [...]<br /> <br /> Allocated by task 675:<br /> __kmalloc_cache_noprof+0x174/0x444<br /> binder_open+0x118/0xb70<br /> do_dentry_open+0x374/0x1040<br /> vfs_open+0x58/0x3bc<br /> [...]<br /> <br /> Freed by task 212:<br /> __kasan_slab_free+0x58/0x80<br /> kfree+0x1a0/0x4a4<br /> binder_proc_dec_tmpref+0x32c/0x5e0<br /> binder_deferred_func+0xc48/0x104c<br /> process_one_work+0x53c/0xbc0<br /> [...]<br /> ==================================================================<br /> <br /> To prevent this, pin the target thread (t-&gt;to_thread) to guarantee the<br /> target process remains alive. Undelivered transactions without a target<br /> thread are already safe, as the target process can only be the current<br /> context in those paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF in binder_thread_release()<br /> <br /> When a thread exits, binder_thread_release() walks its transaction stack<br /> to clear the t-&gt;from and t-&gt;to_proc that correspond with the exiting<br /> thread. However, a process dying in parallel might attempt to kfree some<br /> of these transactions. And if one of them has no associated t-&gt;to_proc,<br /> the t-&gt;to_proc-&gt;inner_lock will not be acquired.<br /> <br /> This means that transaction accesses in binder_thread_release() after<br /> t-&gt;to_proc has been cleared might race with binder_free_transaction()<br /> and cause a use-after-free error as reported by KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798<br /> Write of size 8 at addr ffff000016627500 by task X/715<br /> <br /> CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> binder_thread_release+0x5d0/0x798<br /> binder_ioctl+0x12c0/0x299c<br /> [...]<br /> <br /> Allocated by task 717 on cpu 18 at 67.267803s:<br /> __kasan_kmalloc+0xa0/0xbc<br /> __kmalloc_cache_noprof+0x174/0x444<br /> binder_transaction+0x554/0x8150<br /> binder_thread_write+0xa30/0x4354<br /> binder_ioctl+0x20f0/0x299c<br /> [...]<br /> <br /> Freed by task 202 on cpu 18 at 90.416221s:<br /> __kasan_slab_free+0x58/0x80<br /> kfree+0x1a0/0x4a4<br /> binder_free_transaction+0x150/0x294<br /> binder_send_failed_reply+0x398/0x6d8<br /> binder_release_work+0x3e4/0x4ec<br /> binder_deferred_func+0xbd8/0x104c<br /> [...]<br /> ==================================================================<br /> <br /> In order to avoid this, make sure that binder_free_transaction() reads<br /> the t-&gt;to_proc under the transaction lock. This will serialize the<br /> transaction release with the accesses in binder_thread_release(). Plus,<br /> it matches the documented locking rules for @to_proc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Release the VGA arbiter client on register_device() failure<br /> <br /> The re-order in the Fixes commit below displaced vfio_pci_vga_init() as<br /> the last failure point of what is now vfio_pci_core_register_device()<br /> without introducing an unwind for the VGA arbiter registration.<br /> <br /> In current kernels this is mostly benign because vfio_pci_set_decode()<br /> only uses pci_dev state, but the original failure path could leave a<br /> callback with a freed vdev cookie. The stale registration also becomes<br /> unsafe again once the callback follows drvdata to the vfio device.<br /> <br /> Add the required VGA unwind callout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mediatek: Fix IRQ domain leak when port fails to enable<br /> <br /> When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port<br /> from pcie-&gt;ports and frees the port structure. However, the IRQ domains set<br /> up earlier by mtk_pcie_init_irq_domain() are never freed.<br /> <br /> Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper,<br /> mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when<br /> mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in<br /> the probe error path (during resume, child devices may have active MSI<br /> mappings and the NOIRQ context prohibits sleeping locks),<br /> mtk_pcie_enable_port() is changed to return an error code so callers can<br /> distinguish the two paths and act accordingly.<br /> <br /> This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC<br /> support series.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: altera: Fix resource leaks on probe failure<br /> <br /> The chained IRQ handler is set during probe, but is only removed during the<br /> driver remove(). If pci_host_probe() fails, the handler and INTx IRQ<br /> domain remain set even though the devm-managed host bridge storage<br /> containing struct altera_pcie will be released, leaving the handler with<br /> a stale data pointer.<br /> <br /> Interrupts are also enabled before pci_host_probe() is called. If probe<br /> fails after that point, the controller interrupt source should be disabled<br /> before the chained handler and INTx domain are removed.<br /> <br /> So set the chained handler only after the INTx domain has been created.<br /> Disable controller interrupts during IRQ teardown, and tear the IRQ setup<br /> down if pci_host_probe() fails.<br /> <br /> [mani: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: sideband: fix ring sg table pages leak<br /> <br /> xhci_ring_to_sgtable() allocates a temporary pages array and<br /> uses it to build the returned sg_table with<br /> sg_alloc_table_from_pages().<br /> <br /> The error paths free the pages array, but the success path<br /> returns the sg_table without freeing it. This leaks the temporary<br /> array every time a sideband client gets an endpoint or event ring<br /> buffer.<br /> <br /> Free the pages array after sg_alloc_table_from_pages() succeeds.<br /> The returned sg_table has its own scatterlist entries and does not<br /> depend on the temporary array after construction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix sleep in atomic context in xhci_free_streams()<br /> <br /> When a USB device with active stream endpoints is disconnected,<br /> xhci_free_streams() is called from the hub_event workqueue to<br /> free the stream resources. It calls xhci_free_stream_info()<br /> while holding xhci-&gt;lock with irqs disabled.<br /> <br /> xhci_free_stream_info() invokes xhci_free_stream_ctx(), which<br /> calls dma_free_coherent() for large stream context arrays.<br /> <br /> dma_free_coherent() can sleep (e.g. via vunmap), triggering<br /> a BUG when called from atomic context.<br /> <br /> Call trace:<br /> dma_free_attrs+0x174/0x220<br /> xhci_free_stream_info+0xd0/0x11c<br /> xhci_free_streams+0x278/0x37c<br /> usb_free_streams+0x98/0xc0<br /> usb_unbind_interface+0x1b8/0x2f8<br /> device_release_driver_internal+0x1d4/0x2cc<br /> device_release_driver+0x18/0x28<br /> bus_remove_device+0x160/0x1a4<br /> device_del+0x1ec/0x350<br /> usb_disable_device+0x98/0x214<br /> usb_disconnect+0xf0/0x35c<br /> hub_event+0xab4/0x19ec<br /> process_one_work+0x278/0x63c<br /> <br /> Fix this by saving the stream_info pointers and clearing the<br /> ep references under the lock, then calling xhci_free_stream_info()<br /> outside the lock where sleeping is allowed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: clear freeze listener on node removal<br /> <br /> Generally userspace is supposed to explicitly clear freeze listeners<br /> before they drop the refcount on the node ref to zero, but there&amp;#39;s<br /> nothing forcing that. Currently, in this scenario the freeze listener<br /> remains in the freeze_listeners rbtree and in the remote node&amp;#39;s freeze<br /> listener list, even though the ref for which the listener is registered<br /> is gone. This could potentially lead to a memory leak due to a refcount<br /> cycle. Thus, remove the freeze listener in this scenario.