Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ice1712: check snd_ctl_new1() return value<br /> <br /> snd_ctl_new1() can return NULL when memory allocation fails. The<br /> ice1712 driver calls snd_ctl_new1() without checking the return value<br /> before dereferencing the pointer in multiple places (ice1712.c,<br /> ice1724.c, aureon.c), which can lead to NULL pointer dereferences.<br /> <br /> Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: gus: check snd_ctl_new1() return value<br /> <br /> snd_ctl_new1() can return NULL when memory allocation fails.<br /> snd_gf1_pcm_volume_control() does not check the return value before<br /> dereferencing kctl-&gt;id.index, which can lead to a NULL pointer<br /> dereference.<br /> <br /> Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire: isight: bound the sample count to the packet payload<br /> <br /> isight_packet() takes the frame count from the device iso packet and<br /> checks it only against the device claimed iso length.<br /> <br /> count = be32_to_cpu(payload-&gt;sample_count);<br /> if (likely(count samples, count);<br /> <br /> length is the iso header data_length. It can be up to 0xffff. So the<br /> gate allows a count up to about 16379. isight_samples() then copies<br /> count frames out of payload-&gt;samples into the PCM DMA buffer.<br /> <br /> payload-&gt;samples holds only 2 * MAX_FRAMES_PER_PACKET values. The<br /> device multiplexes two samples per frame. A count past<br /> MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer<br /> size writes past runtime-&gt;dma_area. The smallest PCM buffer is larger<br /> than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET<br /> keeps both the read and the write in range.<br /> <br /> A malicious or faulty Apple iSight on the FireWire bus reaches this<br /> during a normal capture.<br /> <br /> Add the MAX_FRAMES_PER_PACKET bound to the gate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/cs35l41: Fix firmware load work teardown<br /> <br /> cs35l41_hda creates ALSA controls whose private data points at the<br /> cs35l41_hda object. The firmware load control can also queue<br /> fw_load_work.<br /> <br /> Those controls are not removed on component unbind, and device remove<br /> only cancels fw_load_work through cs35l41_remove_dsp(). That helper is<br /> skipped when halo_initialized is false. With firmware_autostart<br /> disabled, a firmware load can be requested before the DSP has been<br /> initialized. If the component or device is removed before the queued<br /> work runs, the worker can run after teardown and dereference driver<br /> state that is no longer valid.<br /> <br /> Track the created controls and remove them on unbind so no new control<br /> callback can reach the driver data or queue more work. Then cancel<br /> fw_load_work to drain any request that was already queued. Also cancel<br /> the work unconditionally during device remove before runtime PM teardown.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: fix use-after-free on marvell probe failure<br /> <br /> Make sure to stop any TX URBs submitted during Marvell OOB wakeup<br /> configuration on later probe failures to avoid use-after-free in the<br /> completion callback.<br /> <br /> This issue was reported by Sashiko while reviewing a fix for a wakeup<br /> source leak in the btusb probe errors paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: fix use-after-free on registration failure<br /> <br /> Make sure to release the sibling interfaces in case controller<br /> registration fails to avoid use-after-free and double-free when they are<br /> eventually disconnected.<br /> <br /> This issue was reported by Sashiko while reviewing a fix for a wakeup<br /> source leak in the btusb probe errors paths.

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.