Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix potential null-ptr-deref in decode_choose_args()<br /> <br /> A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself<br /> contains a CRUSH map. When decoding this CRUSH map in crush_decode(), an<br /> array of max_buckets CRUSH buckets is decoded, where some indices may<br /> not refer to actual buckets and are therefore set to NULL. The received<br /> CRUSH map may optionally contain choose_args that get decoded in<br /> decode_choose_args(). When decoding a crush_choose_arg_map, a series of<br /> choose_args for different buckets is decoded, with the bucket_index<br /> being read from the incoming message. It is only checked that the bucket<br /> index does not exceed max_buckets, but not that it doesn&amp;#39;t point to an<br /> index with a NULL bucket. If a (potentially corrupted) message contains<br /> a crush_choose_arg_map including such a bucket_index, a null pointer<br /> dereference may occur in the subsequent processing when attempting to<br /> access the bucket with the given index.<br /> <br /> This patch fixes the issue by extending the affected check. Now, it is<br /> only attempted to access the bucket if it is not NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix potential out-of-bounds access in __ceph_x_decrypt()<br /> <br /> In __ceph_x_decrypt(), a part of the buffer p is interpreted as a<br /> ceph_x_encrypt_header, and the magic field of this struct is accessed.<br /> This happens without any guarantee that the buffer is large enough to<br /> hold this struct. The function parameter ciphertext_len represents the<br /> length of the ciphertext to decrypt and is guaranteed to be at most the<br /> remaining size of the allocated buffer p. However, this value is not<br /> necessarily greater than sizeof(ceph_x_encrypt_header). E.g., a message<br /> frame of type FRAME_TAG_AUTH_REPLY_MORE, that is just as long to hold<br /> the ciphertext at its end with a ciphertext_len of 8 or less, can<br /> trigger an out-of-bounds memory access when accessing hdr-&gt;magic.<br /> <br /> This patch fixes the issue by adding a check to ensure that the<br /> decrypted plaintext in the buffer is large enough to represent at least<br /> the ceph_x_encrypt_header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: handle rbtree insertion error in decode_choose_args()<br /> <br /> A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself<br /> contains a CRUSH map. The received CRUSH map may optionally contain<br /> choose_args that get decoded in decode_choose_args(). In this function,<br /> num_choose_arg_maps is read from the message, and a corresponding number<br /> of crush_choose_arg_maps gets decoded afterwards. Each<br /> crush_choose_arg_map has a choose_args_index, which serves as the key<br /> when inserting it into the choose_args rbtree of the decoded crush_map.<br /> If a (potentially corrupted) message contains two crush_choose_arg_maps<br /> with the same index, the assertion in insert_choose_arg_map() triggers a<br /> kernel BUG when trying to insert the second crush_choose_arg_map.<br /> <br /> This patch fixes the issue by switching to the non-asserting rbtree<br /> insertion function and rejecting the message if the insertion fails.<br /> <br /> [ idryomov: changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix oops due to out of scope access<br /> <br /> Below oops triggers when kill QEMU process:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI<br /> Call Trace:<br /> <br /> do_raw_spin_lock+0xaa/0xc0<br /> _raw_spin_lock_irqsave+0x21/0x40<br /> domain_remove_dev_pasid+0x52/0x160<br /> intel_nested_set_dev_pasid+0x1b9/0x1e0<br /> __iommu_set_group_pasid+0x56/0x120<br /> pci_dev_reset_iommu_done+0xe3/0x180<br /> pcie_flr+0x65/0x160<br /> __pci_reset_function_locked+0x5b/0x120<br /> vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core]<br /> vfio_df_close+0x4f/0xa0<br /> vfio_df_unbind_iommufd+0x2d/0x60<br /> vfio_device_fops_release+0x3e/0x40<br /> __fput+0xe5/0x2c0<br /> task_work_run+0x58/0xa0<br /> do_exit+0x2c8/0x600<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0x863/0x8c0<br /> arch_do_signal_or_restart+0x24/0x100<br /> exit_to_user_mode_loop+0x87/0x380<br /> do_syscall_64+0x2ff/0x11e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The global static blocked domain is a dummy domain without corresponding<br /> dmar_domain structure, accessing beyond iommu_domain structure triggers<br /> oops easily. Fix it by return early in domain_remove_dev_pasid() like<br /> identity domain.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure<br /> <br /> Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout()<br /> infinite LRU walk on swapout failure") to the ttm_bo_shrink() path.<br /> <br /> Move del_bulk_move from before the backup to after success only,<br /> using ttm_resource_del_bulk_move_unevictable() since the resource<br /> is now unevictable once fully backed up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/dma-buf: handle empty bo and UAF races<br /> <br /> There look to be some nasty races here when triggering the<br /> invalidate_mappings hook:<br /> <br /> 1) We do xe_bo_alloc() followed by the attach, before the actual full bo<br /> init step in xe_dma_buf_init_obj(). However the bo is visible on the<br /> attachments list after the attach. This is bad since exporter driver,<br /> say amdgpu, can at any time call back into our invalidate_mappings hook,<br /> with an empty/bogus bo, leading to potential bugs/crashes.<br /> <br /> 2) Similar to 1) but here we get a UAF, when the invalidate_mappings<br /> hook is triggered. For example, we get as far as xe_bo_init_locked()<br /> but this fails in some way. But here the bo will be freed on error, but<br /> we still have it attached from dma-buf pov, so if the<br /> invalidate_mappings is now triggered then the bo we access is gone and<br /> we trigger UAF and more bugs/crashes.<br /> <br /> To fix this, move the attach step until after we actually have a fully<br /> set up buffer object. Note that the bo is not published to userspace<br /> until later, so not sure what the comment "Don&amp;#39;t publish the bo<br /> until we have a valid attachment", is referring to.<br /> <br /> We have at least two different customers reporting hitting a NULL ptr<br /> deref in evict_flags when importing something from amdgpu, followed by<br /> triggering the evict flow. Hit rate is also pretty low, which would<br /> hint at some kind of race, so something like 1) or 2) might explain<br /> this.<br /> <br /> v2:<br /> - Shuffle the order of the ops slightly (no functional change)<br /> - Improve the comment to better explain the ordering (Matt B)<br /> <br /> (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset<br /> <br /> In __iommu_group_set_domain_internal(), concurrent domain attachments are<br /> rejected when any device in the group is recovering. This is necessary to<br /> fence concurrent attachments to a multi-device group where devices might<br /> share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in<br /> __iommu_group_set_domain_nofail().<br /> <br /> Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such<br /> as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should<br /> not be rejected, as the domain would be freed anyway in these nofail paths<br /> while group-&gt;domain is still pointing to it. So pci_dev_reset_iommu_done()<br /> could trigger a UAF when re-attaching group-&gt;domain.<br /> <br /> Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through<br /> the group-&gt;recovery_cnt fence, so as to update the group-&gt;domain pointer.<br /> Instead add a gdev-&gt;blocked check in the device iteration loop, to prevent<br /> any concurrent per-device detachment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Fix potential out-of-bounds access in crush_decode()<br /> <br /> A message of type CEPH_MSG_OSD_MAP containing a crush map with at least<br /> one bucket has two fields holding the bucket algorithm. If the values<br /> in these two fields differ, an out-of-bounds access can occur. This is<br /> the case because the first algorithm field (alg) is used to allocate<br /> the correct amount of memory for a bucket of this type, while the second<br /> algorithm field inside the bucket (b-&gt;alg) is used in the subsequent<br /> processing.<br /> <br /> This patch fixes the issue by adding a check that compares alg and<br /> b-&gt;alg and aborts the processing in case they differ. Furthermore,<br /> b-&gt;alg is set to 0 in this case, because the destruction of the crush<br /> map also uses this field to determine the bucket type, which can again<br /> result in an out-of-bounds access when trying to free the memory pointed<br /> to by the fields of the bucket. To correctly free the memory allocated<br /> for the bucket in such a case, the corresponding call to kfree is moved<br /> from the algorithm-specific crush_destroy_bucket functions to the<br /> generic crush_destroy_bucket().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/dma-buf: fix UAF with retry loop<br /> <br /> Retry doesn&amp;#39;t work here, since bo will be freed on error, leading to<br /> UAF. However, now that we do the alloc &amp; init before the attach, we can<br /> now combine this as one unit and have the init do the alloc for us. This<br /> should make the retry safe.<br /> <br /> Reported by Sashiko.<br /> <br /> v2: Fix up the error unwind (CI)<br /> <br /> (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl<br /> <br /> While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong<br /> timeout value` warning was observed, accompanied by SMBus controller<br /> state machine corruption.<br /> <br /> The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of<br /> 10 ms. The user argument is checked against INT_MAX, but it is<br /> subsequently multiplied by 10 before being passed to msecs_to_jiffies().<br /> <br /> A malicious user can pass a large value (e.g., 429496729) that passes<br /> the `arg &gt; INT_MAX` check but overflows when multiplied by 10. This<br /> results in a truncated 32-bit unsigned value that bypasses the<br /> internal `(int)m adapter-&gt;timeout`<br /> (a signed 32-bit int), which is reinterpreted as a negative number.<br /> When passed to wait_for_completion_timeout(), this negative value<br /> undergoes sign extension to a 64-bit unsigned long, triggering the<br /> `schedule_timeout` warning and causing premature returns. This leaves<br /> the SMBus state machine in an unrecoverable state, constituting a<br /> local Denial of Service (DoS).<br /> <br /> Fix this by bounding the user argument to `INT_MAX / 10`.<br /> <br /> [wsa: move the comment as well]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove<br /> <br /> In qrtr_port_remove(), the socket reference count is decremented via<br /> __sock_put() before the port is removed from the qrtr_ports XArray and<br /> before the RCU grace period elapses.<br /> <br /> This breaks the fundamental RCU update paradigm. It exposes a race<br /> window where a concurrent RCU reader (such as qrtr_reset_ports() or<br /> qrtr_port_lookup()) can obtain a pointer to the socket from the XArray,<br /> and attempt to call sock_hold() on a socket whose reference count has<br /> already dropped to zero.<br /> <br /> This exact race condition was hit during syzkaller fuzzing, leading to<br /> the following refcount saturation warning and a potential Use-After-Free:<br /> <br /> refcount_t: saturated; leaking memory.<br /> WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0<br /> Modules linked in: qrtr(+) bochs drm_shmem_helper ...<br /> Call Trace:<br /> <br /> qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr]<br /> __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr]<br /> qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr]<br /> kernel_bind+0xe4/0x120 net/socket.c:3592<br /> qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr]<br /> qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr]<br /> do_one_initcall+0xf5/0x5e0 init/main.c:1283<br /> ...<br /> <br /> <br /> Fix this by deferring the reference count decrement until after the<br /> xa_erase() and the synchronize_rcu() complete.<br /> <br /> (Note: The v1 of this patch incorrectly replaced __sock_put() with<br /> sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove()<br /> still hold a reference to the socket, so freeing the socket memory here<br /> would lead to a subsequent UAF in the caller. Thus, the __sock_put() is<br /> kept, but only repositioned to close the RCU race.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling<br /> <br /> A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in<br /> send_sigio() and send_sigurg() when a process group receives a signal.<br /> <br /> When FASYNC is configured for a process group (PIDTYPE_PGID), both<br /> functions use read_lock(&amp;tasklist_lock) to traverse the task list.<br /> However, they are frequently called from softirq context:<br /> - send_sigio() via input_inject_event -&gt; kill_fasync<br /> - send_sigurg() via tcp_check_urg -&gt; sk_send_sigurg (NET_RX_SOFTIRQ)<br /> <br /> The deadlock is caused by the rwlock writer fairness mechanism:<br /> 1. CPU 0 (process context) holds read_lock(&amp;tasklist_lock) in do_wait().<br /> 2. CPU 1 (process context) attempts write_lock(&amp;tasklist_lock) in<br /> fork() or exit() and spins, which blocks all new readers.<br /> 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).<br /> 4. The softirq calls send_sigurg() and attempts to acquire<br /> read_lock(&amp;tasklist_lock), deadlocking because CPU 1 is waiting.<br /> <br /> Since PID hashing and do_each_pid_task() traversals are already<br /> RCU-protected, the read_lock on tasklist_lock is no longer strictly<br /> required for safe traversal. Fix this by replacing tasklist_lock with<br /> rcu_read_lock(), aligning the process group signaling path with the<br /> single-PID path. This also mitigates a potential remote denial of<br /> service vector via TCP URG packets.<br /> <br /> Lockdep splat:<br /> =====================================================<br /> WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected<br /> [...]<br /> Chain exists of:<br /> &amp;dev-&gt;event_lock --&gt; &amp;f_owner-&gt;lock --&gt; tasklist_lock<br /> <br /> Possible interrupt unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(tasklist_lock);<br /> local_irq_disable();<br /> lock(&amp;dev-&gt;event_lock);<br /> lock(&amp;f_owner-&gt;lock);<br /> <br /> lock(&amp;dev-&gt;event_lock);<br /> <br /> *** DEADLOCK ***