Vulnerabilities

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 /> 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 ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: prevent potential out-of-bounds writes in handle_auth_session_key()<br /> <br /> The len field originates from untrusted network packets. Boundary<br /> checks have been added to prevent potential out-of-bounds writes when<br /> decrypting the connection secret or processing service tickets.<br /> <br /> [ idryomov: changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix potential use-after-free in have_mon_and_osd_map()<br /> <br /> The wait loop in __ceph_open_session() can race with the client<br /> receiving a new monmap or osdmap shortly after the initial map is<br /> received. Both ceph_monc_handle_map() and handle_one_map() install<br /> a new map immediately after freeing the old one<br /> <br /> kfree(monc-&gt;monmap);<br /> monc-&gt;monmap = monmap;<br /> <br /> ceph_osdmap_destroy(osdc-&gt;osdmap);<br /> osdc-&gt;osdmap = newmap;<br /> <br /> under client-&gt;monc.mutex and client-&gt;osdc.lock respectively, but<br /> because neither is taken in have_mon_and_osd_map() it&amp;#39;s possible for<br /> client-&gt;monc.monmap-&gt;epoch and client-&gt;osdc.osdmap-&gt;epoch arms in<br /> <br /> client-&gt;monc.monmap &amp;&amp; client-&gt;monc.monmap-&gt;epoch &amp;&amp;<br /> client-&gt;osdc.osdmap &amp;&amp; client-&gt;osdc.osdmap-&gt;epoch;<br /> <br /> condition to dereference an already freed map. This happens to be<br /> reproducible with generic/395 and generic/397 with KASAN enabled:<br /> <br /> BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70<br /> Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305<br /> CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266<br /> ...<br /> Call Trace:<br /> <br /> have_mon_and_osd_map+0x56/0x70<br /> ceph_open_session+0x182/0x290<br /> ceph_get_tree+0x333/0x680<br /> vfs_get_tree+0x49/0x180<br /> do_new_mount+0x1a3/0x2d0<br /> path_mount+0x6dd/0x730<br /> do_mount+0x99/0xe0<br /> __do_sys_mount+0x141/0x180<br /> do_syscall_64+0x9f/0x100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> Allocated by task 13305:<br /> ceph_osdmap_alloc+0x16/0x130<br /> ceph_osdc_init+0x27a/0x4c0<br /> ceph_create_client+0x153/0x190<br /> create_fs_client+0x50/0x2a0<br /> ceph_get_tree+0xff/0x680<br /> vfs_get_tree+0x49/0x180<br /> do_new_mount+0x1a3/0x2d0<br /> path_mount+0x6dd/0x730<br /> do_mount+0x99/0xe0<br /> __do_sys_mount+0x141/0x180<br /> do_syscall_64+0x9f/0x100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 9475:<br /> kfree+0x212/0x290<br /> handle_one_map+0x23c/0x3b0<br /> ceph_osdc_handle_map+0x3c9/0x590<br /> mon_dispatch+0x655/0x6f0<br /> ceph_con_process_message+0xc3/0xe0<br /> ceph_con_v1_try_read+0x614/0x760<br /> ceph_con_workfn+0x2de/0x650<br /> process_one_work+0x486/0x7c0<br /> process_scheduled_works+0x73/0x90<br /> worker_thread+0x1c8/0x2a0<br /> kthread+0x2ec/0x300<br /> ret_from_fork+0x24/0x40<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Rewrite the wait loop to check the above condition directly with<br /> client-&gt;monc.mutex and client-&gt;osdc.lock taken as appropriate. While<br /> at it, improve the timeout handling (previously mount_timeout could be<br /> exceeded in case wait_event_interruptible_timeout() slept more than<br /> once) and access client-&gt;auth_err under client-&gt;monc.mutex to match<br /> how it&amp;#39;s set in finish_auth().<br /> <br /> monmap_show() and osdmap_show() now take the respective lock before<br /> accessing the map as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check NULL before accessing<br /> <br /> [WHAT]<br /> IGT kms_cursor_legacy&amp;#39;s long-nonblocking-modeset-vs-cursor-atomic<br /> fails with NULL pointer dereference. This can be reproduced with<br /> both an eDP panel and a DP monitors connected.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted<br /> 6.16.0-99-custom #8 PREEMPT(voluntary)<br /> Hardware name: AMD ........<br /> RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu]<br /> Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49<br /> 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30<br /> c2 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02<br /> RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668<br /> RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000<br /> RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760<br /> R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000<br /> R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c<br /> FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu]<br /> amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu]<br /> ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu]<br /> amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu]<br /> drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400<br /> drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30<br /> drm_crtc_get_last_vbltimestamp+0x55/0x90<br /> drm_crtc_next_vblank_start+0x45/0xa0<br /> drm_atomic_helper_wait_for_fences+0x81/0x1f0<br /> ...<br /> <br /> (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths<br /> <br /> This patch addresses a race condition caused by unsynchronized<br /> execution of multiple call paths invoking `dwc3_remove_requests()`,<br /> leading to premature freeing of USB requests and subsequent crashes.<br /> <br /> Three distinct execution paths interact with `dwc3_remove_requests()`:<br /> Path 1:<br /> Triggered via `dwc3_gadget_reset_interrupt()` during USB reset<br /> handling. The call stack includes:<br /> - `dwc3_ep0_reset_state()`<br /> - `dwc3_ep0_stall_and_restart()`<br /> - `dwc3_ep0_out_start()`<br /> - `dwc3_remove_requests()`<br /> - `dwc3_gadget_del_and_unmap_request()`<br /> <br /> Path 2:<br /> Also initiated from `dwc3_gadget_reset_interrupt()`, but through<br /> `dwc3_stop_active_transfers()`. The call stack includes:<br /> - `dwc3_stop_active_transfers()`<br /> - `dwc3_remove_requests()`<br /> - `dwc3_gadget_del_and_unmap_request()`<br /> <br /> Path 3:<br /> Occurs independently during `adb root` execution, which triggers<br /> USB function unbind and bind operations. The sequence includes:<br /> - `gserial_disconnect()`<br /> - `usb_ep_disable()`<br /> - `dwc3_gadget_ep_disable()`<br /> - `dwc3_remove_requests()` with `-ESHUTDOWN` status<br /> <br /> Path 3 operates asynchronously and lacks synchronization with Paths<br /> 1 and 2. When Path 3 completes, it disables endpoints and frees &amp;#39;out&amp;#39;<br /> requests. If Paths 1 or 2 are still processing these requests,<br /> accessing freed memory leads to a crash due to use-after-free conditions.<br /> <br /> To fix this added check for request completion and skip processing<br /> if already completed and added the request status for ep0 while queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: storage: Fix memory leak in USB bulk transport<br /> <br /> A kernel memory leak was identified by the &amp;#39;ioctl_sg01&amp;#39; test from Linux<br /> Test Project (LTP). The following bytes were mainly observed: 0x53425355.<br /> <br /> When USB storage devices incorrectly skip the data phase with status data,<br /> the code extracts/validates the CSW from the sg buffer, but fails to clear<br /> it afterwards. This leaves status protocol data in srb&amp;#39;s transfer buffer,<br /> such as the US_BULK_CS_SIGN &amp;#39;USBS&amp;#39; signature observed here. Thus, this can<br /> lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)<br /> interfaces, such as the one seen here when the LTP test requested 512 KiB.<br /> <br /> Fix the leak by zeroing the CSW data in srb&amp;#39;s transfer buffer immediately<br /> after the validation of devices that skip data phase.<br /> <br /> Note: Differently from CVE-2018-1000204, which fixed a big leak by zero-<br /> ing pages at allocation time, this leak occurs after allocation, when USB<br /> protocol data is written to already-allocated sg pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_eem: Fix memory leak in eem_unwrap<br /> <br /> The existing code did not handle the failure case of usb_ep_queue in the<br /> command path, potentially leading to memory leaks.<br /> <br /> Improve error handling to free all allocated resources on usb_ep_queue<br /> failure. This patch continues to use goto logic for error handling, as the<br /> existing error handling is complex and not easily adaptable to auto-cleanup<br /> helpers.<br /> <br /> kmemleak results:<br /> unreferenced object 0xffffff895a512300 (size 240):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> kmem_cache_alloc+0x1b4/0x358<br /> skb_clone+0x90/0xd8<br /> eem_unwrap+0x1cc/0x36c<br /> unreferenced object 0xffffff8a157f4000 (size 256):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> __kmem_cache_alloc_node+0x1b4/0x2dc<br /> kmalloc_trace+0x48/0x140<br /> dwc3_gadget_ep_alloc_request+0x58/0x11c<br /> usb_ep_alloc_request+0x40/0xe4<br /> eem_unwrap+0x204/0x36c<br /> unreferenced object 0xffffff8aadbaac00 (size 128):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> __kmem_cache_alloc_node+0x1b4/0x2dc<br /> __kmalloc+0x64/0x1a8<br /> eem_unwrap+0x218/0x36c<br /> unreferenced object 0xffffff89ccef3500 (size 64):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> __kmem_cache_alloc_node+0x1b4/0x2dc<br /> kmalloc_trace+0x48/0x140<br /> eem_unwrap+0x238/0x36c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: fix double free on late probe failure<br /> <br /> The MOST subsystem has a non-standard registration function which frees<br /> the interface on registration failures and on deregistration.<br /> <br /> This unsurprisingly leads to bugs in the MOST drivers, and a couple of<br /> recent changes turned a reference underflow and use-after-free in the<br /> USB driver into several double free and a use-after-free on late probe<br /> failures.