Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: avoid NULL pointer dereference if no valid csum tree<br /> <br /> [BUG]<br /> When trying read-only scrub on a btrfs with rescue=idatacsums mount<br /> option, it will crash with the following call trace:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000208<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]<br /> Call Trace:<br /> <br /> scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]<br /> scrub_simple_mirror+0x175/0x290 [btrfs]<br /> scrub_stripe+0x5f7/0x6f0 [btrfs]<br /> scrub_chunk+0x9a/0x150 [btrfs]<br /> scrub_enumerate_chunks+0x333/0x660 [btrfs]<br /> btrfs_scrub_dev+0x23e/0x600 [btrfs]<br /> btrfs_ioctl+0x1dcf/0x2f80 [btrfs]<br /> __x64_sys_ioctl+0x97/0xc0<br /> do_syscall_64+0x4f/0x120<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> [CAUSE]<br /> Mount option "rescue=idatacsums" will completely skip loading the csum<br /> tree, so that any data read will not find any data csum thus we will<br /> ignore data checksum verification.<br /> <br /> Normally call sites utilizing csum tree will check the fs state flag<br /> NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.<br /> <br /> This results in scrub to call btrfs_search_slot() on a NULL pointer<br /> and triggered above crash.<br /> <br /> [FIX]<br /> Check both extent and csum tree root before doing any tree search.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda: Fix UAF when reloading module<br /> <br /> hda_generic_machine_select() appends -idisp to the tplg filename by<br /> allocating a new string with devm_kasprintf(), then stores the string<br /> right back into the global variable snd_soc_acpi_intel_hda_machines.<br /> When the module is unloaded, this memory is freed, resulting in a global<br /> variable pointing to freed memory. Reloading the module then triggers<br /> a use-after-free:<br /> <br /> BUG: KFENCE: use-after-free read in string+0x48/0xe0<br /> <br /> Use-after-free read at 0x00000000967e0109 (in kfence-#99):<br /> string+0x48/0xe0<br /> vsnprintf+0x329/0x6e0<br /> devm_kvasprintf+0x54/0xb0<br /> devm_kasprintf+0x58/0x80<br /> hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]<br /> sof_probe_work+0x7f/0x600 [snd_sof]<br /> process_one_work+0x17b/0x330<br /> worker_thread+0x2ce/0x3f0<br /> kthread+0xcf/0x100<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64<br /> <br /> allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago):<br /> devm_kmalloc+0x52/0x120<br /> devm_kvasprintf+0x66/0xb0<br /> devm_kasprintf+0x58/0x80<br /> hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic]<br /> sof_probe_work+0x7f/0x600 [snd_sof]<br /> process_one_work+0x17b/0x330<br /> worker_thread+0x2ce/0x3f0<br /> kthread+0xcf/0x100<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago):<br /> release_nodes+0x43/0xb0<br /> devres_release_all+0x90/0xf0<br /> device_unbind_cleanup+0xe/0x70<br /> device_release_driver_internal+0x1c1/0x200<br /> driver_detach+0x48/0x90<br /> bus_remove_driver+0x6d/0xf0<br /> pci_unregister_driver+0x42/0xb0<br /> __do_sys_delete_module+0x1d1/0x310<br /> do_syscall_64+0x82/0x190<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Fix it by copying the match array with devm_kmemdup_array() before we<br /> modify it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: pktgen: fix access outside of user given buffer in pktgen_thread_write()<br /> <br /> Honour the user given buffer size for the strn_len() calls (otherwise<br /> strn_len() will access memory outside of the user given buffer).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> espintcp: fix skb leaks<br /> <br /> A few error paths are missing a kfree_skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock<br /> <br /> ... or we risk stealing final mntput from sync umount - raising mnt_count<br /> after umount(2) has verified that victim is not busy, but before it<br /> has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn&amp;#39;t see<br /> that it&amp;#39;s safe to quietly undo mnt_count increment and leaves dropping<br /> the reference to caller, where it&amp;#39;ll be a full-blown mntput().<br /> <br /> Check under mount_lock is needed; leaving the current one done before<br /> taking that makes no sense - it&amp;#39;s nowhere near common enough to bother<br /> with.

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 /> idpf: fix null-ptr-deref in idpf_features_check<br /> <br /> idpf_features_check is used to validate the TX packet. skb header<br /> length is compared with the hardware supported value received from<br /> the device control plane. The value is stored in the adapter structure<br /> and to access it, vport pointer is used. During reset all the vports<br /> are released and the vport pointer that the netdev private structure<br /> points to is NULL.<br /> <br /> To avoid null-ptr-deref, store the max header length value in netdev<br /> private structure. This also helps to cache the value and avoid<br /> accessing adapter pointer in hot path.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000068<br /> ...<br /> RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x154/0x520<br /> ? exc_page_fault+0x76/0x190<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? idpf_features_check+0x6d/0xe0 [idpf]<br /> netif_skb_features+0x88/0x310<br /> validate_xmit_skb+0x2a/0x2b0<br /> validate_xmit_skb_list+0x4c/0x70<br /> sch_direct_xmit+0x19d/0x3a0<br /> __dev_queue_xmit+0xb74/0xe70<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios<br /> <br /> A kernel crash was observed when replacing free hugetlb folios:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary)<br /> RIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0<br /> RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000<br /> RDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000<br /> RBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000<br /> R10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000<br /> R13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004<br /> FS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> replace_free_hugepage_folios+0xb6/0x100<br /> alloc_contig_range_noprof+0x18a/0x590<br /> ? srso_return_thunk+0x5/0x5f<br /> ? down_read+0x12/0xa0<br /> ? srso_return_thunk+0x5/0x5f<br /> cma_range_alloc.constprop.0+0x131/0x290<br /> __cma_alloc+0xcf/0x2c0<br /> cma_alloc_write+0x43/0xb0<br /> simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110<br /> debugfs_attr_write+0x46/0x70<br /> full_proxy_write+0x62/0xa0<br /> vfs_write+0xf8/0x420<br /> ? srso_return_thunk+0x5/0x5f<br /> ? filp_flush+0x86/0xa0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? filp_close+0x1f/0x30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? do_dup2+0xaf/0x160<br /> ? srso_return_thunk+0x5/0x5f<br /> ksys_write+0x65/0xe0<br /> do_syscall_64+0x64/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> There is a potential race between __update_and_free_hugetlb_folio() and<br /> replace_free_hugepage_folios():<br /> <br /> CPU1 CPU2<br /> __update_and_free_hugetlb_folio replace_free_hugepage_folios<br /> folio_test_hugetlb(folio)<br /> -- It&amp;#39;s still hugetlb folio.<br /> <br /> __folio_clear_hugetlb(folio)<br /> hugetlb_free_folio(folio)<br /> h = folio_hstate(folio)<br /> -- Here, h is NULL pointer<br /> <br /> When the above race condition occurs, folio_hstate(folio) returns NULL,<br /> and subsequent access to this NULL pointer will cause the system to crash.<br /> To resolve this issue, execute folio_hstate(folio) under the protection<br /> of the hugetlb_lock lock, ensuring that folio_hstate(folio) does not<br /> return NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fred: Fix system hang during S4 resume with FRED enabled<br /> <br /> Upon a wakeup from S4, the restore kernel starts and initializes the<br /> FRED MSRs as needed from its perspective. It then loads a hibernation<br /> image, including the image kernel, and attempts to load image pages<br /> directly into their original page frames used before hibernation unless<br /> those frames are currently in use. Once all pages are moved to their<br /> original locations, it jumps to a "trampoline" page in the image kernel.<br /> <br /> At this point, the image kernel takes control, but the FRED MSRs still<br /> contain values set by the restore kernel, which may differ from those<br /> set by the image kernel before hibernation. Therefore, the image kernel<br /> must ensure the FRED MSRs have the same values as before hibernation.<br /> Since these values depend only on the location of the kernel text and<br /> data, they can be recomputed from scratch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fix debug actions order<br /> <br /> The order of actions taken for debug was implemented incorrectly.<br /> Now we implemented the dump split and do the FW reset only in the<br /> middle of the dump (rather than the FW killing itself on error.)<br /> As a result, some of the actions taken when applying the config<br /> will now crash the device, so we need to fix the order.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Fix use-after-free in cifs_fill_dirent<br /> <br /> There is a race condition in the readdir concurrency process, which may<br /> access the rsp buffer after it has been released, triggering the<br /> following KASAN warning.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]<br /> Read of size 4 at addr ffff8880099b819c by task a.out/342975<br /> <br /> CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x53/0x70<br /> print_report+0xce/0x640<br /> kasan_report+0xb8/0xf0<br /> cifs_fill_dirent+0xb03/0xb60 [cifs]<br /> cifs_readdir+0x12cb/0x3190 [cifs]<br /> iterate_dir+0x1a1/0x520<br /> __x64_sys_getdents+0x134/0x220<br /> do_syscall_64+0x4b/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f996f64b9f9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89<br /> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01<br /> f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8<br /> RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e<br /> RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88<br /> R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000<br /> <br /> <br /> Allocated by task 408:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x14/0x30<br /> __kasan_slab_alloc+0x6e/0x70<br /> kmem_cache_alloc_noprof+0x117/0x3d0<br /> mempool_alloc_noprof+0xf2/0x2c0<br /> cifs_buf_get+0x36/0x80 [cifs]<br /> allocate_buffers+0x1d2/0x330 [cifs]<br /> cifs_demultiplex_thread+0x22b/0x2690 [cifs]<br /> kthread+0x394/0x720<br /> ret_from_fork+0x34/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 342979:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x37/0x50<br /> kmem_cache_free+0x2b8/0x500<br /> cifs_buf_release+0x3c/0x70 [cifs]<br /> cifs_readdir+0x1c97/0x3190 [cifs]<br /> iterate_dir+0x1a1/0x520<br /> __x64_sys_getdents64+0x134/0x220<br /> do_syscall_64+0x4b/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The buggy address belongs to the object at ffff8880099b8000<br /> which belongs to the cache cifs_request of size 16588<br /> The buggy address is located 412 bytes inside of<br /> freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8<br /> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> anon flags: 0x80000000000040(head|node=0|zone=1)<br /> page_type: f5(slab)<br /> raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001<br /> raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000<br /> head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001<br /> head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000<br /> head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff<br /> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt;ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> <br /> POC is available in the link [1].<br /> <br /> The problem triggering process is as follows:<br /> <br /> Process 1 Process 2<br /> -----------------------------------<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN<br /> <br /> syzbot reports a data-race when accessing the event_triggered, here is the<br /> simplified stack when the issue occurred:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed<br /> <br /> write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0:<br /> virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653<br /> start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264<br /> __netdev_start_xmit include/linux/netdevice.h:5151 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5160 [inline]<br /> xmit_one net/core/dev.c:3800 [inline]<br /> <br /> read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1:<br /> virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline]<br /> virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566<br /> skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777<br /> vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715<br /> __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158<br /> handle_irq_event_percpu kernel/irq/handle.c:193 [inline]<br /> <br /> value changed: 0x01 -&gt; 0x00<br /> ==================================================================<br /> <br /> When the data race occurs, the function virtqueue_enable_cb_delayed() sets<br /> event_triggered to false, and virtqueue_disable_cb_split/packed() reads it<br /> as false due to the race condition. Since event_triggered is an unreliable<br /> hint used for optimization, this should only cause the driver temporarily<br /> suggest that the device not send an interrupt notification when the event<br /> index is used.<br /> <br /> Fix this KCSAN reported data-race issue by explicitly tagging the access as<br /> data_racy.