Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix crash in process_v2_sparse_read() for encrypted directories<br /> <br /> The crash in process_v2_sparse_read() for fscrypt-encrypted directories<br /> has been reported. Issue takes place for Ceph msgr2 protocol in secure<br /> mode. It can be reproduced by the steps:<br /> <br /> sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure<br /> <br /> (1) mkdir /mnt/cephfs/fscrypt-test-3<br /> (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3<br /> (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3<br /> (4) fscrypt lock /mnt/cephfs/fscrypt-test-3<br /> (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3<br /> (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar<br /> (7) Issue has been triggered<br /> <br /> [ 408.072247] ------------[ cut here ]------------<br /> [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865<br /> ceph_con_v2_try_read+0x4b39/0x72f0<br /> [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common<br /> intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery<br /> pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass<br /> polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse<br /> serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg<br /> pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore<br /> [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+<br /> [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.17.0-5.fc42 04/01/2014<br /> [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn<br /> [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0<br /> [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8<br /> 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff 0b e9 06<br /> fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85<br /> [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246<br /> [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38<br /> [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8<br /> [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8<br /> [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000<br /> [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000)<br /> knlGS:0000000000000000<br /> [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0<br /> [ 408.072336] PKRU: 55555554<br /> [ 408.072337] Call Trace:<br /> [ 408.072338] <br /> [ 408.072340] ? sched_clock_noinstr+0x9/0x10<br /> [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10<br /> [ 408.072347] ? _raw_spin_unlock+0xe/0x40<br /> [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830<br /> [ 408.072353] ? __kasan_check_write+0x14/0x30<br /> [ 408.072357] ? mutex_lock+0x84/0xe0<br /> [ 408.072359] ? __pfx_mutex_lock+0x10/0x10<br /> [ 408.072361] ceph_con_workfn+0x27e/0x10e0<br /> [ 408.072364] ? metric_delayed_work+0x311/0x2c50<br /> [ 408.072367] process_one_work+0x611/0xe20<br /> [ 408.072371] ? __kasan_check_write+0x14/0x30<br /> [ 408.072373] worker_thread+0x7e3/0x1580<br /> [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 408.072378] ? __pfx_worker_thread+0x10/0x10<br /> [ 408.072381] kthread+0x381/0x7a0<br /> [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 408.072385] ? __pfx_kthread+0x10/0x10<br /> [ 408.072387] ? __kasan_check_write+0x14/0x30<br /> [ 408.072389] ? recalc_sigpending+0x160/0x220<br /> [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50<br /> [ 408.072394] ? calculate_sigpending+0x78/0xb0<br /> [ 408.072395] ? __pfx_kthread+0x10/0x10<br /> [ 408.072397] ret_from_fork+0x2b6/0x380<br /> [ 408.072400] ? __pfx_kthread+0x10/0x10<br /> [ 408.072402] ret_from_fork_asm+0x1a/0x30<br /> [ 408.072406] <br /> [ 408.072407] ---[ end trace 0000000000000000 ]---<br /> [ 408.072418] Oops: general protection fault, probably for non-canonical<br /> address 0xdffffc00000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref<br /> <br /> In btusb_mtk_setup(), we set `btmtk_data-&gt;isopkt_intf` to:<br /> usb_ifnum_to_if(data-&gt;udev, MTK_ISO_IFNUM)<br /> <br /> That function can return NULL in some cases. Even when it returns<br /> NULL, though, we still go on to call btusb_mtk_claim_iso_intf().<br /> <br /> As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for<br /> usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf()<br /> when `btmtk_data-&gt;isopkt_intf` is NULL will cause a crash because<br /> we&amp;#39;ll end up passing a bad pointer to device_lock(). Prior to that<br /> commit we&amp;#39;d pass the NULL pointer directly to<br /> usb_driver_claim_interface() which would detect it and return an<br /> error, which was handled.<br /> <br /> Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check<br /> at the start of the function. This makes the code handle a NULL<br /> `btmtk_data-&gt;isopkt_intf` the same way it did before the problematic<br /> commit (just with a slight change to the error message printed).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().<br /> <br /> syzbot reported divide-by-zero in __tcp_select_window() by<br /> MPTCP socket. [0]<br /> <br /> We had a similar issue for the bare TCP and fixed in commit<br /> 499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead<br /> of 0").<br /> <br /> Let&amp;#39;s apply the same fix to mptcp_do_fastclose().<br /> <br /> [0]:<br /> Oops: divide error: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> RIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336<br /> Code: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00<br /> RSP: 0018:ffffc90003017640 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028<br /> R10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> tcp_select_window net/ipv4/tcp_output.c:281 [inline]<br /> __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline]<br /> tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836<br /> mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793<br /> mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253<br /> mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776<br /> mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe5/0x270 net/socket.c:742<br /> __sys_sendto+0x3bd/0x520 net/socket.c:2244<br /> __do_sys_sendto net/socket.c:2251 [inline]<br /> __se_sys_sendto net/socket.c:2247 [inline]<br /> __x64_sys_sendto+0xde/0x100 net/socket.c:2247<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f66e998f749<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: replace BUG_ON with bounds check for map-&gt;max_osd<br /> <br /> OSD indexes come from untrusted network packets. Boundary checks are<br /> added to validate these against map-&gt;max_osd.<br /> <br /> [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic<br /> edits ]