Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: fix potential UAF in SSP passkey handlers<br /> <br /> hci_conn lookup and field access must be covered by hdev lock in<br /> hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise<br /> the connection can be freed concurrently.<br /> <br /> Extend the hci_dev_lock critical section to cover all conn usage in both<br /> handlers.<br /> <br /> Keep the existing keypress notification behavior unchanged by routing<br /> the early exits through a common unlock path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: fix overlayfs mmap() and mprotect() access checks<br /> <br /> The existing SELinux security model for overlayfs is to allow access if<br /> the current task is able to access the top level file (the "user" file)<br /> and the mounter&amp;#39;s credentials are sufficient to access the lower<br /> level file (the "backing" file). Unfortunately, the current code does<br /> not properly enforce these access controls for both mmap() and mprotect()<br /> operations on overlayfs filesystems.<br /> <br /> This patch makes use of the newly created security_mmap_backing_file()<br /> LSM hook to provide the missing backing file enforcement for mmap()<br /> operations, and leverages the backing file API and new LSM blob to<br /> provide the necessary information to properly enforce the mprotect()<br /> access controls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()<br /> <br /> The commit c8e008b60492 ("ext4: ignore xattrs past end")<br /> introduced a refcount leak in when block_csum is false.<br /> <br /> ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to<br /> get iloc.bh, but never releases it with brelse().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: fix MR cleanup on copy error<br /> <br /> __rds_rdma_map() hands sg/pages ownership to the transport after<br /> get_mr() succeeds. If copying the generated cookie back to user space<br /> fails after that point, the error path must not free those resources<br /> again before dropping the MR reference.<br /> <br /> Remove the duplicate unpin/free from the put_user() failure branch so<br /> that MR teardown is handled only through the existing final cleanup<br /> path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix soft lockup in retry_aligned_read()<br /> <br /> When retry_aligned_read() encounters an overlapped stripe, it releases<br /> the stripe via raid5_release_stripe() which puts it on the lockless<br /> released_stripes llist. In the next raid5d loop iteration,<br /> release_stripe_list() drains the stripe onto handle_list (since<br /> STRIPE_HANDLE is set by the original IO), but retry_aligned_read()<br /> runs before handle_active_stripes() and removes the stripe from<br /> handle_list via find_get_stripe() -&gt; list_del_init(). This prevents<br /> handle_stripe() from ever processing the stripe to resolve the<br /> overlap, causing an infinite loop and soft lockup.<br /> <br /> Fix this by using __release_stripe() with temp_inactive_list instead<br /> of raid5_release_stripe() in the failure path, so the stripe does not<br /> go through the released_stripes llist. This allows raid5d to break out<br /> of its loop, and the overlap will be resolved when the stripe is<br /> eventually processed by handle_stripe().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix deadlock with check operation and nowait requests<br /> <br /> When an array check is running it will raise the barrier at which point<br /> normal requests will become blocked and increment the nr_pending value to<br /> signal there is work pending inside of wait_barrier(). NOWAIT requests<br /> do not block and so will return immediately with an error, and additionally<br /> do not increment nr_pending in wait_barrier(). Upstream change commit<br /> 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a<br /> call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit<br /> this condition. raid_end_bio_io() eventually calls allow_barrier() and<br /> it will unconditionally do an atomic_dec_and_test(&amp;conf-&gt;nr_pending) even<br /> though the corresponding increment on nr_pending didn&amp;#39;t happen in the<br /> NOWAIT case.<br /> <br /> This can be easily seen by starting a check operation while an application<br /> is doing nowait IO on the same array. This results in a deadlocked state<br /> due to nr_pending value underflowing and so the md resync thread gets stuck<br /> waiting for nr_pending to == 0.<br /> <br /> Output of r10conf state of the array when we hit this condition:<br /> <br /> crash&gt; struct r10conf<br /> barrier = 1,<br /> nr_pending = {<br /> counter = -41<br /> },<br /> nr_waiting = 15,<br /> nr_queued = 0,<br /> <br /> Example of md_sync thread stuck waiting on raise_barrier() and other<br /> requests stuck in wait_barrier():<br /> <br /> md1_resync<br /> [] raise_barrier+0xce/0x1c0<br /> [] raid10_sync_request+0x1ca/0x1ed0<br /> [] md_do_sync+0x779/0x1110<br /> [] md_thread+0x90/0x160<br /> [] kthread+0xbe/0xf0<br /> [] ret_from_fork+0x34/0x50<br /> [] ret_from_fork_asm+0x1a/0x30<br /> <br /> kworker/u1040:2+flush-253:4<br /> [] wait_barrier+0x1de/0x220<br /> [] regular_request_wait+0x30/0x180<br /> [] raid10_make_request+0x261/0x1000<br /> [] md_handle_request+0x13b/0x230<br /> [] __submit_bio+0x107/0x1f0<br /> [] submit_bio_noacct_nocheck+0x16f/0x390<br /> [] ext4_io_submit+0x24/0x40<br /> [] ext4_do_writepages+0x254/0xc80<br /> [] ext4_writepages+0x84/0x120<br /> [] do_writepages+0x7a/0x260<br /> [] __writeback_single_inode+0x3d/0x300<br /> [] writeback_sb_inodes+0x1dd/0x470<br /> [] __writeback_inodes_wb+0x4c/0xe0<br /> [] wb_writeback+0x18b/0x2d0<br /> [] wb_workfn+0x2a1/0x400<br /> [] process_one_work+0x149/0x330<br /> [] worker_thread+0x2d2/0x410<br /> [] kthread+0xbe/0xf0<br /> [] ret_from_fork+0x34/0x50<br /> [] ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: fix usb_dev refcount leak on probe failure<br /> <br /> create_card() takes a reference on the USB device with usb_get_dev()<br /> and stores the matching usb_put_dev() in card_free(), which is<br /> installed as the snd_card&amp;#39;s -&gt;private_free destructor.<br /> <br /> However, -&gt;private_free is only assigned near the end of init_card(),<br /> after several failure points (usb_set_interface(), EP type checks,<br /> usb_submit_urb(), the EP1_CMD_GET_DEVICE_INFO exchange, and its<br /> timeout). When any of those fail, init_card() returns an error to<br /> snd_probe(), which calls snd_card_free(card). Because -&gt;private_free<br /> is still NULL, card_free() never runs, the usb_get_dev() reference<br /> is not dropped, and the struct usb_device leaks along with its<br /> descriptor allocations and device_private.<br /> <br /> syzbot reproduces this with a malformed UAC3 device whose only valid<br /> altsetting is 0; init_card()&amp;#39;s usb_set_interface(usb_dev, 0, 1) call<br /> fails with -EIO and triggers the leak.<br /> <br /> Move the -&gt;private_free assignment into create_card(), immediately<br /> after usb_get_dev(), so that every error path reaching snd_card_free()<br /> balances the reference. card_free()&amp;#39;s callees (snd_usb_caiaq_input_free,<br /> free_urbs, kfree) already tolerate the partially-initialized state<br /> because the chip private area is zero-initialized by snd_card_new().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: ns: Fix use-after-free in driver remove()<br /> <br /> In the remove callback, if a packet arrives after destroy_workqueue() is<br /> called, but before sock_release(), the qrtr_ns_data_ready() callback will<br /> try to queue the work, causing use-after-free issue.<br /> <br /> Fix this issue by saving the default &amp;#39;sk_data_ready&amp;#39; callback during<br /> qrtr_ns_init() and use it to replace the qrtr_ns_data_ready() callback at<br /> the start of remove(). This ensures that even if a packet arrives after<br /> destroy_workqueue(), the work struct will not be dereferenced.<br /> <br /> Note that it is also required to ensure that the RX threads are completed<br /> before destroying the workqueue, because the threads could be using the<br /> qrtr_ns_data_ready() callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Add fallback to default RSR for S/PDIF<br /> <br /> spdif_passthru_playback_get_resources() uses atc-&gt;pll_rate as the RSR<br /> for the MSR calculation loop. However, pll_rate is only updated in<br /> atc_pll_init() and not in hw_pll_init(), so it remains 0 after the<br /> card init.<br /> <br /> When spdif_passthru_playback_setup() skips atc_pll_init() for<br /> 32000 Hz, (rsr * desc.msr) always becomes 0, causing the loop to spin<br /> indefinitely.<br /> <br /> Add fallback to use atc-&gt;rsr when atc-&gt;pll_rate is 0. This reflects<br /> the hardware state, since hw_card_init() already configures the PLL<br /> to the default RSR.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: only d_add() negative dentries when they are unhashed<br /> <br /> Ceph can call d_add(dentry, NULL) on a negative dentry that is already<br /> present in the primary dcache hash.<br /> <br /> In the current VFS that is not safe. d_add() goes through __d_add()<br /> to __d_rehash(), which unconditionally reinserts dentry-&gt;d_hash into<br /> the hlist_bl bucket. If the dentry is already hashed, reinserting the<br /> same node can corrupt the bucket, including creating a self-loop.<br /> Once that happens, __d_lookup() can spin forever in the hlist_bl walk,<br /> typically looping only on the d_name.hash mismatch check and<br /> eventually triggering RCU stall reports like this one:<br /> <br /> rcu: INFO: rcu_sched self-detected stall on CPU<br /> rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829<br /> rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192)<br /> CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE<br /> Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023<br /> RIP: 0010:__d_lookup+0x46/0xb0<br /> Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f<br /> RSP: 0018:ff745a70c8253898 EFLAGS: 00000282<br /> RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966<br /> RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0<br /> RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89<br /> R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0<br /> R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f<br /> FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> lookup_fast+0x9f/0x100<br /> walk_component+0x1f/0x150<br /> link_path_walk+0x20e/0x3d0<br /> path_lookupat+0x68/0x180<br /> filename_lookup+0xdc/0x1e0<br /> vfs_statx+0x6c/0x140<br /> vfs_fstatat+0x67/0xa0<br /> __do_sys_newfstatat+0x24/0x60<br /> do_syscall_64+0x6a/0x230<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> This is reachable with reused cached negative dentries. A Ceph lookup<br /> or atomic_open can be handed a negative dentry that is already hashed,<br /> and fs/ceph/dir.c then hits one of two paths that incorrectly assume<br /> "negative" also means "unhashed":<br /> <br /> - ceph_finish_lookup():<br /> MDS reply is -ENOENT with no trace<br /> -&gt; d_add(dentry, NULL)<br /> <br /> - ceph_lookup():<br /> local ENOENT fast path for a complete directory with shared caps<br /> -&gt; d_add(dentry, NULL)<br /> <br /> Both paths can therefore re-add an already-hashed negative dentry.<br /> <br /> Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only<br /> calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)<br /> is true.<br /> <br /> Fix both fs/ceph/dir.c sites the same way: only call d_add() for a<br /> negative dentry when it is actually unhashed. If the negative dentry<br /> is already hashed, leave it in place and reuse it as-is.<br /> <br /> This preserves the existing behavior for unhashed dentries while<br /> avoiding d_hash list corruption for reused hashed negatives.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/md-llbitmap: skip reading rdevs that are not in_sync<br /> <br /> When reading bitmap pages from member disks, the code iterates through<br /> all rdevs and attempts to read from the first available one. However,<br /> it only checks for raid_disk assignment and Faulty flag, missing the<br /> In_sync flag check.<br /> <br /> This can cause bitmap data to be read from spare disks that are still<br /> being rebuilt and don&amp;#39;t have valid bitmap information yet. Reading<br /> stale or uninitialized bitmap data from such disks can lead to<br /> incorrect dirty bit tracking, potentially causing data corruption<br /> during recovery or normal operation.<br /> <br /> Add the In_sync flag check to ensure bitmap pages are only read from<br /> fully synchronized member disks that have valid bitmap data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv<br /> <br /> rxe_rcv() currently checks only that the incoming packet is at least<br /> header_size(pkt) bytes long before payload_size() is used.<br /> <br /> However, payload_size() subtracts both the attacker-controlled BTH pad<br /> field and RXE_ICRC_SIZE from pkt-&gt;paylen:<br /> <br /> payload_size = pkt-&gt;paylen - offset[RXE_PAYLOAD] - bth_pad(pkt)<br /> - RXE_ICRC_SIZE<br /> <br /> This means a short packet can still make payload_size() underflow even<br /> if it includes enough bytes for the fixed headers. Simply requiring<br /> header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a<br /> packet with a forged non-zero BTH pad can still leave payload_size()<br /> negative and pass an underflowed value to later receive-path users.<br /> <br /> Fix this by validating pkt-&gt;paylen against the full minimum length<br /> required by payload_size(): header_size(pkt) + bth_pad(pkt) +<br /> RXE_ICRC_SIZE.