Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Fix use-after-free, permit out-of-order decoder shutdown<br /> <br /> In support of investigating an initialization failure report [1],<br /> cxl_test was updated to register mock memory-devices after the mock<br /> root-port/bus device had been registered. That led to cxl_test crashing<br /> with a use-after-free bug with the following signature:<br /> <br /> cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1<br /> cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1<br /> cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0<br /> 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1<br /> [..]<br /> cxld_unregister: cxl decoder14.0:<br /> cxl_region_decode_reset: cxl_region region3:<br /> mock_decoder_reset: cxl_port port3: decoder3.0 reset<br /> 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1<br /> cxl_endpoint_decoder_release: cxl decoder14.0:<br /> [..]<br /> cxld_unregister: cxl decoder7.0:<br /> 3) cxl_region_decode_reset: cxl_region region3:<br /> Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI<br /> [..]<br /> RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> cxl_region_decode_reset+0x69/0x190 [cxl_core]<br /> cxl_region_detach+0xe8/0x210 [cxl_core]<br /> cxl_decoder_kill_region+0x27/0x40 [cxl_core]<br /> cxld_unregister+0x5d/0x60 [cxl_core]<br /> <br /> At 1) a region has been established with 2 endpoint decoders (7.0 and<br /> 14.0). Those endpoints share a common switch-decoder in the topology<br /> (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits<br /> the "out of order reset case" in the switch decoder. The effect though<br /> is that region3 cleanup is aborted leaving it in-tact and<br /> referencing decoder14.0. At 3) the second attempt to teardown region3<br /> trips over the stale decoder14.0 object which has long since been<br /> deleted.<br /> <br /> The fix here is to recognize that the CXL specification places no<br /> mandate on in-order shutdown of switch-decoders, the driver enforces<br /> in-order allocation, and hardware enforces in-order commit. So, rather<br /> than fail and leave objects dangling, always remove them.<br /> <br /> In support of making cxl_region_decode_reset() always succeed,<br /> cxl_region_invalidate_memregion() failures are turned into warnings.<br /> Crashing the kernel is ok there since system integrity is at risk if<br /> caches cannot be managed around physical address mutation events like<br /> CXL region destruction.<br /> <br /> A new device_for_each_child_reverse_from() is added to cleanup<br /> port-&gt;commit_end after all dependent decoders have been disabled. In<br /> other words if decoders are allocated 0-&gt;1-&gt;2 and disabled 1-&gt;2-&gt;0 then<br /> port-&gt;commit_end only decrements from 2 after 2 has been disabled, and<br /> it decrements all the way to zero since 1 was disabled previously.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan()<br /> <br /> KASAN reported following issue:<br /> <br /> BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt]<br /> Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387<br /> Tainted: [U]=USER<br /> Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6c/0x90<br /> print_report+0xd1/0x630<br /> kasan_report+0xdb/0x110<br /> __asan_report_load4_noabort+0x14/0x20<br /> tb_retimer_scan+0xffe/0x1550 [thunderbolt]<br /> tb_scan_port+0xa6f/0x2060 [thunderbolt]<br /> tb_handle_hotplug+0x17b1/0x3080 [thunderbolt]<br /> process_one_work+0x626/0x1100<br /> worker_thread+0x6c8/0xfa0<br /> kthread+0x2c8/0x3a0<br /> ret_from_fork+0x3a/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> This happens because the loop variable still gets incremented by one so<br /> max becomes 3 instead of 2, and this makes the second loop read past the<br /> the array declared on the stack.<br /> <br /> Fix this by assigning to max directly in the loop body.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential deadlock with newly created symlinks<br /> <br /> Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers<br /> memory reclamation involving the filesystem layer, which can result in<br /> circular lock dependencies among the reader/writer semaphore<br /> nilfs-&gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the<br /> fs_reclaim pseudo lock.<br /> <br /> This is because after commit 21fc61c73c39 ("don&amp;#39;t put symlink bodies in<br /> pagecache into highmem"), the gfp flags of the page cache for symbolic<br /> links are overwritten to GFP_KERNEL via inode_nohighmem().<br /> <br /> This is not a problem for symlinks read from the backing device, because<br /> the __GFP_FS flag is dropped after inode_nohighmem() is called. However,<br /> when a new symlink is created with nilfs_symlink(), the gfp flags remain<br /> overwritten to GFP_KERNEL. Then, memory allocation called from<br /> page_symlink() etc. triggers memory reclamation including the FS layer,<br /> which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can<br /> cause a deadlock if they are called while nilfs-&gt;ns_segctor_sem is held:<br /> <br /> Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags<br /> of newly created symlinks in the same way that nilfs_new_inode() and<br /> __nilfs_read_inode() do, as a workaround until we adopt nofs allocation<br /> scope consistently or improve the locking constraints.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix kernel bug due to missing clearing of checked flag<br /> <br /> Syzbot reported that in directory operations after nilfs2 detects<br /> filesystem corruption and degrades to read-only,<br /> __block_write_begin_int(), which is called to prepare block writes, may<br /> fail the BUG_ON check for accesses exceeding the folio/page size,<br /> triggering a kernel bug.<br /> <br /> This was found to be because the "checked" flag of a page/folio was not<br /> cleared when it was discarded by nilfs2&amp;#39;s own routine, which causes the<br /> sanity check of directory entries to be skipped when the directory<br /> page/folio is reloaded. So, fix that.<br /> <br /> This was necessary when the use of nilfs2&amp;#39;s own page discard routine was<br /> applied to more than just metadata files.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()<br /> <br /> Mounting btrfs from two images (which have the same one fsid and two<br /> different dev_uuids) in certain executing order may trigger an UAF for<br /> variable &amp;#39;device-&gt;bdev_file&amp;#39; in __btrfs_free_extra_devids(). And<br /> following are the details:<br /> <br /> 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs<br /> devices by ioctl(BTRFS_IOC_SCAN_DEV):<br /> <br /> / btrfs_device_1 → loop0<br /> fs_device<br /> \ btrfs_device_2 → loop1<br /> 2. mount /dev/loop0 /mnt<br /> btrfs_open_devices<br /> btrfs_device_1-&gt;bdev_file = btrfs_get_bdev_and_sb(loop0)<br /> btrfs_device_2-&gt;bdev_file = btrfs_get_bdev_and_sb(loop1)<br /> btrfs_fill_super<br /> open_ctree<br /> fail: btrfs_close_devices // -ENOMEM<br /> btrfs_close_bdev(btrfs_device_1)<br /> fput(btrfs_device_1-&gt;bdev_file)<br /> // btrfs_device_1-&gt;bdev_file is freed<br /> btrfs_close_bdev(btrfs_device_2)<br /> fput(btrfs_device_2-&gt;bdev_file)<br /> <br /> 3. mount /dev/loop1 /mnt<br /> btrfs_open_devices<br /> btrfs_get_bdev_and_sb(&amp;bdev_file)<br /> // EIO, btrfs_device_1-&gt;bdev_file is not assigned,<br /> // which points to a freed memory area<br /> btrfs_device_2-&gt;bdev_file = btrfs_get_bdev_and_sb(loop1)<br /> btrfs_fill_super<br /> open_ctree<br /> btrfs_free_extra_devids<br /> if (btrfs_device_1-&gt;bdev_file)<br /> fput(btrfs_device_1-&gt;bdev_file) // UAF !<br /> <br /> Fix it by setting &amp;#39;device-&gt;bdev_file&amp;#39; as &amp;#39;NULL&amp;#39; after closing the<br /> btrfs_device in btrfs_close_one_device().

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fork: do not invoke uffd on fork if error occurs<br /> <br /> Patch series "fork: do not expose incomplete mm on fork".<br /> <br /> During fork we may place the virtual memory address space into an<br /> inconsistent state before the fork operation is complete.<br /> <br /> In addition, we may encounter an error during the fork operation that<br /> indicates that the virtual memory address space is invalidated.<br /> <br /> As a result, we should not be exposing it in any way to external machinery<br /> that might interact with the mm or VMAs, machinery that is not designed to<br /> deal with incomplete state.<br /> <br /> We specifically update the fork logic to defer khugepaged and ksm to the<br /> end of the operation and only to be invoked if no error arose, and<br /> disallow uffd from observing fork events should an error have occurred.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Currently on fork we expose the virtual address space of a process to<br /> userland unconditionally if uffd is registered in VMAs, regardless of<br /> whether an error arose in the fork.<br /> <br /> This is performed in dup_userfaultfd_complete() which is invoked<br /> unconditionally, and performs two duties - invoking registered handlers<br /> for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down<br /> userfaultfd_fork_ctx objects established in dup_userfaultfd().<br /> <br /> This is problematic, because the virtual address space may not yet be<br /> correctly initialised if an error arose.<br /> <br /> The change in commit d24062914837 ("fork: use __mt_dup() to duplicate<br /> maple tree in dup_mmap()") makes this more pertinent as we may be in a<br /> state where entries in the maple tree are not yet consistent.<br /> <br /> We address this by, on fork error, ensuring that we roll back state that<br /> we would otherwise expect to clean up through the event being handled by<br /> userland and perform the memory freeing duty otherwise performed by<br /> dup_userfaultfd_complete().<br /> <br /> We do this by implementing a new function, dup_userfaultfd_fail(), which<br /> performs the same loop, only decrementing reference counts.<br /> <br /> Note that we perform mmgrab() on the parent and child mm&amp;#39;s, however<br /> userfaultfd_ctx_put() will mmdrop() this once the reference count drops to<br /> zero, so we will avoid memory leaks correctly here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Vangogh: Fix kernel memory out of bounds write<br /> <br /> KASAN reports that the GPU metrics table allocated in<br /> vangogh_tables_init() is not large enough for the memset done in<br /> smu_cmn_init_soft_gpu_metrics(). Condensed report follows:<br /> <br /> [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]<br /> [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067<br /> ...<br /> [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544<br /> [ 33.861816] Tainted: [W]=WARN<br /> [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023<br /> [ 33.861822] Call Trace:<br /> [ 33.861826] <br /> [ 33.861829] dump_stack_lvl+0x66/0x90<br /> [ 33.861838] print_report+0xce/0x620<br /> [ 33.861853] kasan_report+0xda/0x110<br /> [ 33.862794] kasan_check_range+0xfd/0x1a0<br /> [ 33.862799] __asan_memset+0x23/0x40<br /> [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]<br /> [ 33.867135] dev_attr_show+0x43/0xc0<br /> [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0<br /> [ 33.867155] seq_read_iter+0x3f8/0x1140<br /> [ 33.867173] vfs_read+0x76c/0xc50<br /> [ 33.867198] ksys_read+0xfb/0x1d0<br /> [ 33.867214] do_syscall_64+0x90/0x160<br /> ...<br /> [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s:<br /> [ 33.867358] kasan_save_stack+0x33/0x50<br /> [ 33.867364] kasan_save_track+0x17/0x60<br /> [ 33.867367] __kasan_kmalloc+0x87/0x90<br /> [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]<br /> [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu]<br /> [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu]<br /> [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]<br /> [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]<br /> [ 33.869608] local_pci_probe+0xda/0x180<br /> [ 33.869614] pci_device_probe+0x43f/0x6b0<br /> <br /> Empirically we can confirm that the former allocates 152 bytes for the<br /> table, while the latter memsets the 168 large block.<br /> <br /> Root cause appears that when GPU metrics tables for v2_4 parts were added<br /> it was not considered to enlarge the table to fit.<br /> <br /> The fix in this patch is rather "brute force" and perhaps later should be<br /> done in a smarter way, by extracting and consolidating the part version to<br /> size logic to a common helper, instead of brute forcing the largest<br /> possible allocation. Nevertheless, for now this works and fixes the out of<br /> bounds write.<br /> <br /> v2:<br /> * Drop impossible v3_0 case. (Mario)<br /> <br /> (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP<br /> <br /> generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem,<br /> on huge=always tmpfs, issues a warning and then hangs (interruptibly):<br /> <br /> WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9<br /> CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2<br /> ...<br /> copy_page_from_iter_atomic+0xa6/0x5ec<br /> generic_perform_write+0xf6/0x1b4<br /> shmem_file_write_iter+0x54/0x67<br /> <br /> Fix copy_page_from_iter_atomic() by limiting it in that case<br /> (include/linux/skbuff.h skb_frag_must_loop() does similar).<br /> <br /> But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too<br /> surprising, has outlived its usefulness, and should just be removed?

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/numa: Fix the potential null pointer dereference in task_numa_work()<br /> <br /> When running stress-ng-vm-segv test, we found a null pointer dereference<br /> error in task_numa_work(). Here is the backtrace:<br /> <br /> [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ......<br /> [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se<br /> ......<br /> [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)<br /> [323676.067115] pc : vma_migratable+0x1c/0xd0<br /> [323676.067122] lr : task_numa_work+0x1ec/0x4e0<br /> [323676.067127] sp : ffff8000ada73d20<br /> [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010<br /> [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000<br /> [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000<br /> [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8<br /> [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035<br /> [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8<br /> [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4<br /> [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001<br /> [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000<br /> [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000<br /> [323676.067152] Call trace:<br /> [323676.067153] vma_migratable+0x1c/0xd0<br /> [323676.067155] task_numa_work+0x1ec/0x4e0<br /> [323676.067157] task_work_run+0x78/0xd8<br /> [323676.067161] do_notify_resume+0x1ec/0x290<br /> [323676.067163] el0_svc+0x150/0x160<br /> [323676.067167] el0t_64_sync_handler+0xf8/0x128<br /> [323676.067170] el0t_64_sync+0x17c/0x180<br /> [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000)<br /> [323676.067177] SMP: stopping secondary CPUs<br /> [323676.070184] Starting crashdump kernel...<br /> <br /> stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error<br /> handling function of the system, which tries to cause a SIGSEGV error on<br /> return from unmapping the whole address space of the child process.<br /> <br /> Normally this program will not cause kernel crashes. But before the<br /> munmap system call returns to user mode, a potential task_numa_work()<br /> for numa balancing could be added and executed. In this scenario, since the<br /> child process has no vma after munmap, the vma_next() in task_numa_work()<br /> will return a null pointer even if the vma iterator restarts from 0.<br /> <br /> Recheck the vma pointer before dereferencing it in task_numa_work().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-fsl-dspi: Fix crash when not using GPIO chip select<br /> <br /> Add check for the return value of spi_get_csgpiod() to avoid passing a NULL<br /> pointer to gpiod_direction_output(), preventing a crash when GPIO chip<br /> select is not used.<br /> <br /> Fix below crash:<br /> [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 4.260762] Mem abort info:<br /> [ 4.263556] ESR = 0x0000000096000004<br /> [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 4.272624] SET = 0, FnV = 0<br /> [ 4.275681] EA = 0, S1PTW = 0<br /> [ 4.278822] FSC = 0x04: level 0 translation fault<br /> [ 4.283704] Data abort info:<br /> [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 4.302445] [0000000000000000] user address but active_mm is swapper<br /> [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 4.315072] Modules linked in:<br /> [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359<br /> [ 4.328130] Hardware name: LS1046A QDS Board (DT)<br /> [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 4.339794] pc : gpiod_direction_output+0x34/0x5c<br /> [ 4.344505] lr : gpiod_direction_output+0x18/0x5c<br /> [ 4.349208] sp : ffff80008003b8f0<br /> [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068<br /> [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810<br /> [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002<br /> [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff<br /> [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007<br /> [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e<br /> [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008<br /> [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000<br /> [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000<br /> [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 4.423921] Call trace:<br /> [ 4.426362] gpiod_direction_output+0x34/0x5c (P)<br /> [ 4.431067] gpiod_direction_output+0x18/0x5c (L)<br /> [ 4.435771] dspi_setup+0x220/0x334