linux vulnerabilities · Page 4

Bluetooth: ISO: Reject concurrent BIS listener setup

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Reject concurrent BIS listener setup iso_sock_listen() drops the socket lock before calling iso_listen_bis() to preserve the hdev->lock ordering. Two concurrent listen() calls on the same broadcast socket can therefore both observe BT_BOUND. Caller A can attach connA and release the locks, then caller B can acquire them and attach connB before A publishes BT_LISTEN. __iso_chan_add() checks whether connB already has a socket, but not whether the socket already has a connection. The second attachment overwrites iso_pi(sk)->conn, leaking the connA reference an

• Update to 6.12.113-1

Bluetooth: ISO: Serialize concurrent connect calls

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Serialize concurrent connect calls iso_sock_connect() checks the socket state before taking the socket lock and drops the lock again before setting up a connection. Two callers can both pass the admission check while the socket is open or bound. Caller A can copy its destination for route selection, then caller B can replace the socket destination before A binds or connects the CIS. A then uses B's destination with the route selected for its own request. B can also proceed after A attaches a connection and sets BT_CONNECT. For deferred BIS setup, B can bind

• Update to 6.12.113-1

Bluetooth: RFCOMM: free the skb when the DLC has no owner

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: free the skb when the DLC has no owner rfcomm_recv_data() hands the skb to d->data_ready() and returns 0 without freeing it, so the callback owns the skb from that point on. The tty implementation frees it when the DLC has been detached from its device: static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) { struct rfcomm_dev *dev = dlc->owner; if (!dev) { kfree_skb(skb); return; } The socket implementation returns without

• Update to 6.12.113-1

Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex An RFCOMM connect() issued while a BR/EDR link is being authenticated makes lockdep report a circular dependency, and the reported cycle is a real AB/BA between rfcomm_mutex and hdev->lock. rfcomm_security_cfm() is called from the HCI event path, which already holds hdev->lock: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock] hci_encrypt_cfm() [hci_cb_list_lock] rfcomm_security_cfm() [rfcomm_mutex] while an RFCOMM connect() from userspace

Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown syzbot hit a NULL pointer dereference in rfcomm_dev_shutdown() when an RFCOMM tty is closed. rfcomm_dev_add() puts the new device on rfcomm_dev_list first and only then registers the tty device and saves it in dev->tty_dev. If that registration fails, dev->tty_dev is never set at all. The device can be looked up in the meantime, so an open() of /dev/rfcommN gets through rfcomm_tty_install() and attaches to it. When that tty is closed again, rfcomm_dev_shutdown() uses dev->tty_dev without checking it:

• Update to 6.12.113-1

drm/fb-helper: defer setup when fbdev_probe() fails, not just on -EAGAIN

In the Linux kernel, the following vulnerability has been resolved: drm/fb-helper: defer setup when fbdev_probe() fails, not just on -EAGAIN __drm_fb_helper_initial_config_and_unlock() calls drm_client_modeset_probe() first, which already fills in each mode_set->mode/num_connectors for every connected output, and only afterwards calls drm_fb_helper_single_fb_probe() to create fb_helper->fb and wire it into those mode_sets via drm_setup_crtcs_fb(). If drm_fb_helper_single_fb_probe() fails with anything other than -EAGAIN (e.g. dev->driver->fbdev_probe() itself fails), the function bails out before drm_setup_crtcs_fb() runs and before settin

• Update to 6.12.113-1

drm/i915/gem: Prevent overstepping exec array boundary

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Prevent overstepping exec array boundary It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow(): 1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under "out" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array. To amend this problem, ensure that

• Update to 6.12.113-1

drm/i915/gt: Unmask interrupts only when ACTIVE is true

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Unmask interrupts only when ACTIVE is true There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() callback

• Update to 6.12.113-1

drm/imagination: Size page table preallocation by device address

In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Size page table preallocation by device address Commit 0a8224058a58 ("drm/imagination: Fix page count for page table for map() interface") passed the device address to pvr_mmu_op_context_create(), but the preallocation is still sized from device_addr + sgt_offset with an exclusive end. The offset into the object's pages has no place in a device-virtual range, and the exclusive end allocates one table too many when the range ends on a table boundary. Count the tables from device_addr and the inclusive end of the range. The new calculation does not take pag

• Update to 6.12.113-1

drm/panthor: validate userspace queue count against initialized firmware slot count

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: validate userspace queue count against initialized firmware slot count In panthor_drv.c:panthor_ioctl_group_create(), the queue count is validated against the hardcoded maximum: if (!args->queues.count || args->queues.count > MAX_CS_PER_CSG) return -EINVAL; However, if the firmware reports fewer slots than MAX_CS_PER_CSG, panthor_fw_init_ifaces() will only initialize that smaller number of stream interfaces. If unprivileged userspace requests more queues than the firmware reported (but no more than MAX_CS_PER_CSG), cs_slot_prog_locked() fetches an uniniti

• Update to 6.12.113-1

drm/vmwgfx: validate pitch coming from userspace

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate pitch coming from userspace Validate the pitch, alongside the box dimensions before trying to copy data from the underlying surface. Fixes possible out of bounds reads with cursor snooping.

drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpin xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is

fs: don't silently unmount busy mounts

In the Linux kernel, the following vulnerability has been resolved: fs: don't silently unmount busy mounts The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell. It skips a copy that has child mounts except for the case of a single child mount covering the copy's root. That algorithm used to be exact. It isn't anymore. Originally only childless copies were unmounted during propagation. And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.

namespace: don't inherit MNT_UMOUNT in clone_mnt()

In the Linux kernel, the following vulnerability has been resolved: namespace: don't inherit MNT_UMOUNT in clone_mnt() MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has taken out of its namespace. It's never cleared. __detach_mounts() unhooks a mount that carries it instead of unmounting it. disconnect_mount() lets an unmounted child stay attached only if its parent carries it. propagate_umount() takes it as the sign that a mount is going to be unmounted when it decides what else can be unmounted, where a chain of locked mounts ends and where a for reparenting an overmount. clone_mnt() copies the flags of the source

namespace: don't copy an unmounted mount tree

In the Linux kernel, the following vulnerability has been resolved: namespace: don't copy an unmounted mount tree may_copy_tree() accepts a mount whose root is an nsfs or pidfs file before it checks whether that mount is mounted. This exception exists for nsfs and pidfs mounts. They are part of no mount namespace so neither check_mnt() nor is_mounted() would let them through and bind-mounting a nsfsfd or a pidfd wouldn't work. Problem is that exception also admits a bind mount of such a file when it was lazily unmounted and is only kept alive by a file descriptor: mount --bind /proc/self/ns/net /tmp/x exec 3< /tmp/x umount -l /tmp/x

• Update to 6.12.113-1

namespace: check a submount for references right before unmounting it

In the Linux kernel, the following vulnerability has been resolved: namespace: check a submount for references right before unmounting it shrink_submounts() and mark_mounts_for_expiry() first collect all the mounts they are allowed to unmount and then unmount them. Whether a mount is busy is decided by propagate_mount_busy() on the tree. But unmounting the first mount changes the tree that the second one propagates into. propagate_umount() moves a surviving overmount off a copy it unmounts and mounts it where the copy was mounted. If that's where the propagated copy of the second victim is looked up the overmount becomes a candidate of the

• Update to 6.12.113-1

namespace: check a recursive bind mount for mount namespace loops

In the Linux kernel, the following vulnerability has been resolved: namespace: check a recursive bind mount for mount namespace loops do_loopback() refuses to bind mount the file of a mount namespace that is as old as the caller's or older because a mount namespace that holds a mount of its own file, or of an ancestor's, would cause a cycle. But it only checks the dentry the bind mount starts from. With MS_REC everything below it is copied and do_loopback() passes CL_COPY_MNT_NS_FILE so mount namespace files below the source are copied. That's fine for a source in the caller's own mount namespace. Every mount namespace file in there passed

namespace: check the mounts before reading their parents in pivot_root()

In the Linux kernel, the following vulnerability has been resolved: namespace: check the mounts before reading their parents in pivot_root() path_pivot_root() reads the parents of new_root and of the caller's root and checks whether they are shared before it checks that either mount is in the caller's mount namespace. Only namespace_sem is held. That's fine for a mount that is in the caller's mount namespace. But new_root can be a file descriptor to a mount that has been unmounted and that only the file descriptor keeps alive. If that mount stayed attached to its parent when it was unmounted nothing pins the parent for it. The final mntput

dcache: don't put a mountpoint on a dentry that's being removed

In the Linux kernel, the following vulnerability has been resolved: dcache: don't put a mountpoint on a dentry that's being removed rmdir(), unlink() and rename() call dont_mount() on the victim and then detach_mounts() with the victim's inode locked. do_lock_mount() takes the inode lock of the mountpoint and checks cant_mount() so a mount can't show up after detach_mounts(). But attach_recursive_mnt() makes a second mountpoint for the root of the source mount so that the mounts already located at the destination can be put on top of it. No inode is locked for that one and d_set_mounted() only refuses a dentry that is unlinked. Between det

• Update to 6.12.113-1

unshare: don't drop active namespace references that were never taken

In the Linux kernel, the following vulnerability has been resolved: unshare: don't drop active namespace references that were never taken Active references on the namespaces of an nsproxy are taken when the nsproxy is installed into a task in switch_task_namespaces() and copy_namespaces() and dropped again by put_nsproxy() through deactivate_nsproxy(). But ksys_unshare() calls put_nsproxy() on an nsproxy that was never installed when set_cred_ucounts() fails. The new namespaces of that nsproxy go from zero to minus one and the namespaces shared with the caller lose a reference that belongs to the nsproxy the caller keeps using: WARNING: