Vulnerabilities

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

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 /> 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 /> net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done<br /> <br /> Syzbot reported a slab-use-after-free with the following call trace:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840<br /> Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25<br /> <br /> Call Trace:<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840<br /> crypto_request_complete include/crypto/algapi.h:266<br /> aead_request_complete include/crypto/internal/aead.h:85<br /> cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772<br /> crypto_request_complete include/crypto/algapi.h:266<br /> cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181<br /> process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231<br /> <br /> Allocated by task 8355:<br /> kzalloc_noprof include/linux/slab.h:778<br /> tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466<br /> tipc_init_net+0x2dd/0x430 net/tipc/core.c:72<br /> ops_init+0xb9/0x650 net/core/net_namespace.c:139<br /> setup_net+0x435/0xb40 net/core/net_namespace.c:343<br /> copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508<br /> create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228<br /> ksys_unshare+0x419/0x970 kernel/fork.c:3323<br /> __do_sys_unshare kernel/fork.c:3394<br /> <br /> Freed by task 63:<br /> kfree+0x12a/0x3b0 mm/slub.c:4557<br /> tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539<br /> tipc_exit_net+0x8c/0x110 net/tipc/core.c:119<br /> ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173<br /> cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640<br /> process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231<br /> <br /> After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done<br /> may still visit it in cryptd_queue_worker workqueue.<br /> <br /> I reproduce this issue by:<br /> ip netns add ns1<br /> ip link add veth1 type veth peer name veth2<br /> ip link set veth1 netns ns1<br /> ip netns exec ns1 tipc bearer enable media eth dev veth1<br /> ip netns exec ns1 tipc node set key this_is_a_master_key master<br /> ip netns exec ns1 tipc bearer disable media eth dev veth1<br /> ip netns del ns1<br /> <br /> The key of reproduction is that, simd_aead_encrypt is interrupted, leading<br /> to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is<br /> triggered, and the tipc_crypto tx will be visited.<br /> <br /> tipc_disc_timeout<br /> tipc_bearer_xmit_skb<br /> tipc_crypto_xmit<br /> tipc_aead_encrypt<br /> crypto_aead_encrypt<br /> // encrypt()<br /> simd_aead_encrypt<br /> // crypto_simd_usable() is false<br /> child = &amp;ctx-&gt;cryptd_tfm-&gt;base;<br /> <br /> simd_aead_encrypt<br /> crypto_aead_encrypt<br /> // encrypt()<br /> cryptd_aead_encrypt_enqueue<br /> cryptd_aead_enqueue<br /> cryptd_enqueue_request<br /> // trigger cryptd_queue_worker<br /> queue_work_on(smp_processor_id(), cryptd_wq, &amp;cpu_queue-&gt;work)<br /> <br /> Fix this by holding net reference count before encrypt.

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

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 /> vxlan: Annotate FDB data races<br /> <br /> The &amp;#39;used&amp;#39; and &amp;#39;updated&amp;#39; fields in the FDB entry structure can be<br /> accessed concurrently by multiple threads, leading to reports such as<br /> [1]. Can be reproduced using [2].<br /> <br /> Suppress these reports by annotating these accesses using<br /> READ_ONCE() / WRITE_ONCE().<br /> <br /> [1]<br /> BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit<br /> <br /> write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:<br /> vxlan_xmit+0xb29/0x2380<br /> dev_hard_start_xmit+0x84/0x2f0<br /> __dev_queue_xmit+0x45a/0x1650<br /> packet_xmit+0x100/0x150<br /> packet_sendmsg+0x2114/0x2ac0<br /> __sys_sendto+0x318/0x330<br /> __x64_sys_sendto+0x76/0x90<br /> x64_sys_call+0x14e8/0x1c00<br /> do_syscall_64+0x9e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:<br /> vxlan_xmit+0xadf/0x2380<br /> dev_hard_start_xmit+0x84/0x2f0<br /> __dev_queue_xmit+0x45a/0x1650<br /> packet_xmit+0x100/0x150<br /> packet_sendmsg+0x2114/0x2ac0<br /> __sys_sendto+0x318/0x330<br /> __x64_sys_sendto+0x76/0x90<br /> x64_sys_call+0x14e8/0x1c00<br /> do_syscall_64+0x9e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> value changed: 0x00000000fffbac6e -&gt; 0x00000000fffbac6f<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> <br /> [2]<br /> #!/bin/bash<br /> <br /> set +H<br /> echo whitelist &gt; /sys/kernel/debug/kcsan<br /> echo !vxlan_xmit &gt; /sys/kernel/debug/kcsan<br /> <br /> ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1<br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1<br /> taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &amp;<br /> taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &amp;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost<br /> <br /> set_boost is a per-policy function call, hence a driver wide lock is<br /> unnecessary. Also this mutex_acquire can collide with the mutex_acquire<br /> from the mode-switch path in status_store(), which can lead to a<br /> deadlock. So, remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled<br /> <br /> When attempting to enable MQPRIO while HTB offload is already<br /> configured, the driver currently returns `-EINVAL` and triggers a<br /> `WARN_ON`, leading to an unnecessary call trace.<br /> <br /> Update the code to handle this case more gracefully by returning<br /> `-EOPNOTSUPP` instead, while also providing a helpful user message.