Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: make sure last_fence is always updated<br /> <br /> Update last_fence in the vm-bind path instead of kernel managed path.<br /> <br /> last_fence is used to wait for work to finish in vm_bind contexts but not<br /> used for kernel managed contexts.<br /> <br /> This fixes a bug where last_fence is not waited on context close leading<br /> to faults as resources are freed while in use.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/680080/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix delayed allocation of a cell&amp;#39;s anonymous key<br /> <br /> The allocation of a cell&amp;#39;s anonymous key is done in a background thread<br /> along with other cell setup such as doing a DNS upcall. In the reported<br /> bug, this is triggered by afs_parse_source() parsing the device name given<br /> to mount() and calling afs_lookup_cell() with the name of the cell.<br /> <br /> The normal key lookup then tries to use the key description on the<br /> anonymous authentication key as the reference for request_key() - but it<br /> may not yet be set and so an oops can happen.<br /> <br /> This has been made more likely to happen by the fix for dynamic lookup<br /> failure.<br /> <br /> Fix this by firstly allocating a reference name and attaching it to the<br /> afs_cell record when the record is created. It can share the memory<br /> allocation with the cell name (unfortunately it can&amp;#39;t just overlap the cell<br /> name by prepending it with "afs@" as the cell name already has a &amp;#39;.&amp;#39;<br /> prepended for other purposes). This reference name is then passed to<br /> request_key().<br /> <br /> Secondly, the anon key is now allocated on demand at the point a key is<br /> requested in afs_request_key() if it is not already allocated. A mutex is<br /> used to prevent multiple allocation for a cell.<br /> <br /> Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn&amp;#39;t<br /> yet allocated (if we need it) and then the caller can return -ECHILD to<br /> drop out of RCU-mode and afs_request_key() can be called.<br /> <br /> Note that the anonymous key is kind of necessary to make the key lookup<br /> cache work as that doesn&amp;#39;t currently cache a negative lookup, but it&amp;#39;s<br /> probably worth some investigation to see if NULL can be used instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/namespace: fix reference leak in grab_requested_mnt_ns<br /> <br /> lookup_mnt_ns() already takes a reference on mnt_ns.<br /> grab_requested_mnt_ns() doesn&amp;#39;t need to take an extra reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atlantic: fix fragment overflow handling in RX path<br /> <br /> The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)<br /> fragments when handling large multi-descriptor packets. This causes an<br /> out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.<br /> <br /> The issue occurs because the driver doesn&amp;#39;t check the total number of<br /> fragments before calling skb_add_rx_frag(). When a packet requires more<br /> than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.<br /> <br /> Fix by assuming there will be an extra frag if buff-&gt;len &gt; AQ_CFG_RX_HDR_SIZE,<br /> then all fragments are accounted for. And reusing the existing check to<br /> prevent the overflow earlier in the code path.<br /> <br /> This crash occurred in production with an Aquantia AQC113 10G NIC.<br /> <br /> Stack trace from production environment:<br /> ```<br /> RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0<br /> Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89<br /> ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90<br /> c8 00 00 00 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48<br /> 89 fa 83<br /> RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287<br /> RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:<br /> fffffffe0a0c8000<br /> RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:<br /> 0000000000037a40<br /> RBP: 0000000000000024 R08: 0000000000000000 R09:<br /> 0000000000000021<br /> R10: 0000000000000848 R11: 0000000000000000 R12:<br /> ffffa9bec02a8e24<br /> R13: ffff925ad8615570 R14: 0000000000000000 R15:<br /> ffff925b22e80a00<br /> FS: 0000000000000000(0000)<br /> GS:ffff925e47880000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:<br /> 0000000000f72ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> aq_ring_rx_clean+0x175/0xe60 [atlantic]<br /> ? aq_ring_rx_clean+0x14d/0xe60 [atlantic]<br /> ? aq_ring_tx_clean+0xdf/0x190 [atlantic]<br /> ? kmem_cache_free+0x348/0x450<br /> ? aq_vec_poll+0x81/0x1d0 [atlantic]<br /> ? __napi_poll+0x28/0x1c0<br /> ? net_rx_action+0x337/0x420<br /> ```<br /> <br /> Changes in v4:<br /> - Add Fixes: tag to satisfy patch validation requirements.<br /> <br /> Changes in v3:<br /> - Fix by assuming there will be an extra frag if buff-&gt;len &gt; AQ_CFG_RX_HDR_SIZE,<br /> then all fragments are accounted for.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sxgbe: fix potential NULL dereference in sxgbe_rx()<br /> <br /> Currently, when skb is null, the driver prints an error and then<br /> dereferences skb on the next line.<br /> <br /> To fix this, let&amp;#39;s add a &amp;#39;break&amp;#39; after the error message to switch<br /> to sxgbe_rx_refill(), which is similar to the approach taken by the<br /> other drivers in this particular case, e.g. calxeda with xgmac_rx().<br /> <br /> Found during a code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel: punit_ipc: fix memory corruption<br /> <br /> This passes the address of the pointer "&amp;punit_ipcdev" when the intent<br /> was to pass the pointer itself "punit_ipcdev" (without the ampersand).<br /> This means that the:<br /> <br /> complete(&amp;ipcdev-&gt;cmd_complete);<br /> <br /> in intel_punit_ioc() will write to a wrong memory address corrupting it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: lookup hci_conn on RX path on protocol side<br /> <br /> The hdev lock/lookup/unlock/use pattern in the packet RX path doesn&amp;#39;t<br /> ensure hci_conn* is not concurrently modified/deleted. This locking<br /> appears to be leftover from before conn_hash started using RCU<br /> commit bf4c63252490b ("Bluetooth: convert conn hash to RCU")<br /> and not clear if it had purpose since then.<br /> <br /> Currently, there are code paths that delete hci_conn* from elsewhere<br /> than the ordered hdev-&gt;workqueue where the RX work runs in. E.g.<br /> commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync")<br /> introduced some of these, and there probably were a few others before<br /> it. It&amp;#39;s better to do the locking so that even if these run<br /> concurrently no UAF is possible.<br /> <br /> Move the lookup of hci_conn and associated socket-specific conn to<br /> protocol recv handlers, and do them within a single critical section<br /> to cover hci_conn* usage and lookup.<br /> <br /> syzkaller has reported a crash that appears to be this issue:<br /> <br /> [Task hdev-&gt;workqueue] [Task 2]<br /> hci_disconnect_all_sync<br /> l2cap_recv_acldata(hcon)<br /> hci_conn_get(hcon)<br /> hci_abort_conn_sync(hcon)<br /> hci_dev_lock<br /> hci_dev_lock<br /> hci_conn_del(hcon)<br /> v-------------------------------- hci_dev_unlock<br /> hci_conn_put(hcon)<br /> conn = hcon-&gt;l2cap_data (UAF)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memfd: fix information leak in hugetlb folios<br /> <br /> When allocating hugetlb folios for memfd, three initialization steps are<br /> missing:<br /> <br /> 1. Folios are not zeroed, leading to kernel memory disclosure to userspace<br /> 2. Folios are not marked uptodate before adding to page cache<br /> 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache()<br /> <br /> The memfd allocation path bypasses the normal page fault handler<br /> (hugetlb_no_page) which would handle all of these initialization steps. <br /> This is problematic especially for udmabuf use cases where folios are<br /> pinned and directly accessed by userspace via DMA.<br /> <br /> Fix by matching the initialization pattern used in hugetlb_no_page():<br /> - Zero the folio using folio_zero_user() which is optimized for huge pages<br /> - Mark it uptodate with folio_mark_uptodate()<br /> - Take hugetlb_fault_mutex before adding to page cache to prevent races<br /> <br /> The folio_zero_user() change also fixes a potential security issue where<br /> uninitialized kernel memory could be disclosed to userspace through read()<br /> or mmap() operations on the memfd.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: fix NULL pointer deference when splitting folio<br /> <br /> Commit c010d47f107f ("mm: thp: split huge page to any lower order pages")<br /> introduced an early check on the folio&amp;#39;s order via mapping-&gt;flags before<br /> proceeding with the split work.<br /> <br /> This check introduced a bug: for shmem folios in the swap cache and<br /> truncated folios, the mapping pointer can be NULL. Accessing<br /> mapping-&gt;flags in this state leads directly to a NULL pointer dereference.<br /> <br /> This commit fixes the issue by moving the check for mapping != NULL before<br /> any attempt to access mapping-&gt;flags.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: ensure vectored buffer node import is tied to notification<br /> <br /> When support for vectored registered buffers was added, the import<br /> itself is using &amp;#39;req&amp;#39; rather than the notification io_kiocb, sr-&gt;notif.<br /> For non-vectored imports, sr-&gt;notif is correctly used. This is important<br /> as the lifetime of the two may be different. Use the correct io_kiocb<br /> for the vectored buffer import.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix memory leak in cifs_construct_tcon()<br /> <br /> When having a multiuser mount with domain= specified and using<br /> cifscreds, cifs_set_cifscreds() will end up setting @ctx-&gt;domainname,<br /> so it needs to be freed before leaving cifs_construct_tcon().<br /> <br /> This fixes the following memory leak reported by kmemleak:<br /> <br /> mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...<br /> su - testuser<br /> cifscreds add -d ZELDA -u testuser<br /> ...<br /> ls /mnt/1<br /> ...<br /> umount /mnt<br /> echo scan &gt; /sys/kernel/debug/kmemleak<br /> cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xffff8881203c3f08 (size 8):<br /> comm "ls", pid 5060, jiffies 4307222943<br /> hex dump (first 8 bytes):<br /> 5a 45 4c 44 41 00 cc cc ZELDA...<br /> backtrace (crc d109a8cf):<br /> __kmalloc_node_track_caller_noprof+0x572/0x710<br /> kstrdup+0x3a/0x70<br /> cifs_sb_tlink+0x1209/0x1770 [cifs]<br /> cifs_get_fattr+0xe1/0xf50 [cifs]<br /> cifs_get_inode_info+0xb5/0x240 [cifs]<br /> cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]<br /> cifs_getattr+0x28e/0x450 [cifs]<br /> vfs_getattr_nosec+0x126/0x180<br /> vfs_statx+0xf6/0x220<br /> do_statx+0xab/0x110<br /> __x64_sys_statx+0xd5/0x130<br /> do_syscall_64+0xbb/0x380<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup<br /> <br /> Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB<br /> access in fbcon_remap_all(). Without holding the console lock the call<br /> races with switching outputs.<br /> <br /> VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon<br /> function uses struct fb_info.node, which is set by register_framebuffer().<br /> As the fb-helper code currently sets up VGA switcheroo before registering<br /> the framebuffer, the value of node is -1 and therefore not a legal value.<br /> For example, fbcon uses the value within set_con2fb_map() [1] as an index<br /> into an array.<br /> <br /> Moving vga_switcheroo_client_fb_set() after register_framebuffer() can<br /> result in VGA switching that does not switch fbcon correctly.<br /> <br /> Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),<br /> which already holds the console lock. Fbdev calls fbcon_fb_registered()<br /> from within register_framebuffer(). Serializes the helper with VGA<br /> switcheroo&amp;#39;s call to fbcon_remap_all().<br /> <br /> Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info<br /> as parameter, it really only needs the contained fbcon state. Moving the<br /> call to fbcon initialization is therefore cleaner than before. Only amdgpu,<br /> i915, nouveau and radeon support vga_switcheroo. For all other drivers,<br /> this change does nothing.