Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues<br /> <br /> Add NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes<br /> during resume from suspend when rings[q_idx]-&gt;q_vector is NULL.<br /> <br /> Tested adaptor:<br /> 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02)<br /> Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]<br /> <br /> SR-IOV state: both disabled and enabled can reproduce this issue.<br /> <br /> kernel version: v6.18<br /> <br /> Reproduce steps:<br /> Boot up and execute suspend like systemctl suspend or rtcwake.<br /> <br /> Log:<br /> [ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> [ 231.444052] #PF: supervisor read access in kernel mode<br /> [ 231.444484] #PF: error_code(0x0000) - not-present page<br /> [ 231.444913] PGD 0 P4D 0<br /> [ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170<br /> [ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89<br /> [ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202<br /> [ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010<br /> [ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000<br /> [ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000<br /> [ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001<br /> [ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000<br /> [ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000<br /> [ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0<br /> [ 231.451629] PKRU: 55555554<br /> [ 231.452076] Call Trace:<br /> [ 231.452549] <br /> [ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]<br /> [ 231.453482] ice_resume+0xfd/0x220 [ice]<br /> [ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10<br /> [ 231.454425] pci_pm_resume+0x8c/0x140<br /> [ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10<br /> [ 231.455347] dpm_run_callback+0x5f/0x160<br /> [ 231.455796] ? dpm_wait_for_superior+0x107/0x170<br /> [ 231.456244] device_resume+0x177/0x270<br /> [ 231.456708] dpm_resume+0x209/0x2f0<br /> [ 231.457151] dpm_resume_end+0x15/0x30<br /> [ 231.457596] suspend_devices_and_enter+0x1da/0x2b0<br /> [ 231.458054] enter_state+0x10e/0x570<br /> <br /> Add defensive checks for both the ring pointer and its q_vector<br /> before dereferencing, allowing the system to resume successfully even when<br /> q_vectors are unmapped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix deadlock in RSS config read<br /> <br /> Since cited commit, core locks the net_device&amp;#39;s rss_lock when handling<br /> ethtool -x command, so driver&amp;#39;s implementation should not lock it<br /> again. Remove the latter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rocker: fix memory leak in rocker_world_port_post_fini()<br /> <br /> In rocker_world_port_pre_init(), rocker_port-&gt;wpriv is allocated with<br /> kzalloc(wops-&gt;port_priv_size, GFP_KERNEL). However, in<br /> rocker_world_port_post_fini(), the memory is only freed when<br /> wops-&gt;port_post_fini callback is set:<br /> <br /> if (!wops-&gt;port_post_fini)<br /> return;<br /> wops-&gt;port_post_fini(rocker_port);<br /> kfree(rocker_port-&gt;wpriv);<br /> <br /> Since rocker_ofdpa_ops does not implement port_post_fini callback<br /> (it is NULL), the wpriv memory allocated for each port is never freed<br /> when ports are removed. This leads to a memory leak of<br /> sizeof(struct ofdpa_port) bytes per port on every device removal.<br /> <br /> Fix this by always calling kfree(rocker_port-&gt;wpriv) regardless of<br /> whether the port_post_fini callback exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove<br /> <br /> On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and<br /> ih2 interrupt ring buffers are not initialized. This is by design, as<br /> these secondary IH rings are only available on discrete GPUs. See<br /> vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when<br /> AMD_IS_APU is set.<br /> <br /> However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to<br /> get the timestamp of the last interrupt entry. When retry faults are<br /> enabled on APUs (noretry=0), this function is called from the SVM page<br /> fault recovery path, resulting in a NULL pointer dereference when<br /> amdgpu_ih_decode_iv_ts_helper() attempts to access ih-&gt;ring[].<br /> <br /> The crash manifests as:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000004<br /> RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]<br /> Call Trace:<br /> amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]<br /> svm_range_restore_pages+0xae5/0x11c0 [amdgpu]<br /> amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]<br /> gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]<br /> amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]<br /> amdgpu_ih_process+0x84/0x100 [amdgpu]<br /> <br /> This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW<br /> IP 9.3.0 from noretry=1") which changed the default for Renoir APU from<br /> noretry=1 to noretry=0, enabling retry fault handling and thus<br /> exercising the buggy code path.<br /> <br /> Fix this by adding a check for ih1.ring_size before attempting to use<br /> it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu:<br /> Rework retry fault removal"). This is needed if the hardware doesn&amp;#39;t<br /> support secondary HW IH rings.<br /> <br /> v2: additional updates (Alex)<br /> <br /> (cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/nvm: Fix double-free on aux add failure<br /> <br /> After a successful auxiliary_device_init(), aux_dev-&gt;dev.release<br /> (xe_nvm_release_dev()) is responsible for the kfree(nvm). When<br /> there is failure with auxiliary_device_add(), driver will call<br /> auxiliary_device_uninit(), which call put_device(). So that the<br /> .release callback will be triggered to free the memory associated<br /> with the auxiliary_device.<br /> <br /> Move the kfree(nvm) into the auxiliary_device_init() failure path<br /> and remove the err goto path to fix below error.<br /> <br /> "<br /> [ 13.232905] ==================================================================<br /> [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]<br /> [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273<br /> <br /> [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)<br /> ...<br /> [ 13.233125] Call Trace:<br /> [ 13.233126] <br /> [ 13.233127] dump_stack_lvl+0x7f/0xc0<br /> [ 13.233132] print_report+0xce/0x610<br /> [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0<br /> [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]<br /> ...<br /> "<br /> <br /> v2: drop err goto path. (Alexander)<br /> <br /> (cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeon_ep: Fix memory leak in octep_device_setup()<br /> <br /> In octep_device_setup(), if octep_ctrl_net_init() fails, the function<br /> returns directly without unmapping the mapped resources and freeing the<br /> allocated configuration memory.<br /> <br /> Fix this by jumping to the unsupported_dev label, which performs the<br /> necessary cleanup. This aligns with the error handling logic of other<br /> paths in this function.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: sched: Fix perf crash with new is_user_task() helper<br /> <br /> In order to do a user space stacktrace the current task needs to be a user<br /> task that has executed in user space. It use to be possible to test if a<br /> task is a user task or not by simply checking the task_struct mm field. If<br /> it was non NULL, it was a user task and if not it was a kernel task.<br /> <br /> But things have changed over time, and some kernel tasks now have their<br /> own mm field.<br /> <br /> An idea was made to instead test PF_KTHREAD and two functions were used to<br /> wrap this check in case it became more complex to test if a task was a<br /> user task or not[1]. But this was rejected and the C code simply checked<br /> the PF_KTHREAD directly.<br /> <br /> It was later found that not all kernel threads set PF_KTHREAD. The io-uring<br /> helpers instead set PF_USER_WORKER and this needed to be added as well.<br /> <br /> But checking the flags is still not enough. There&amp;#39;s a very small window<br /> when a task exits that it frees its mm field and it is set back to NULL.<br /> If perf were to trigger at this moment, the flags test would say its a<br /> user space task but when perf would read the mm field it would crash with<br /> at NULL pointer dereference.<br /> <br /> Now there are flags that can be used to test if a task is exiting, but<br /> they are set in areas that perf may still want to profile the user space<br /> task (to see where it exited). The only real test is to check both the<br /> flags and the mm field.<br /> <br /> Instead of making this modification in every location, create a new<br /> is_user_task() helper function that does all the tests needed to know if<br /> it is safe to read the user space memory or not.<br /> <br /> [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/shmem, swap: fix race of truncate and swap entry split<br /> <br /> The helper for shmem swap freeing is not handling the order of swap<br /> entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it<br /> gets the entry order before that using xa_get_order without lock<br /> protection, and it may get an outdated order value if the entry is split<br /> or changed in other ways after the xa_get_order and before the<br /> xa_cmpxchg_irq.<br /> <br /> And besides, the order could grow and be larger than expected, and cause<br /> truncation to erase data beyond the end border. For example, if the<br /> target entry and following entries are swapped in or freed, then a large<br /> folio was added in place and swapped out, using the same entry, the<br /> xa_cmpxchg_irq will still succeed, it&amp;#39;s very unlikely to happen though.<br /> <br /> To fix that, open code the Xarray cmpxchg and put the order retrieval and<br /> value checking in the same critical section. Also, ensure the order won&amp;#39;t<br /> exceed the end border, skip it if the entry goes across the border.<br /> <br /> Skipping large swap entries crosses the end border is safe here. Shmem<br /> truncate iterates the range twice, in the first iteration,<br /> find_lock_entries already filtered such entries, and shmem will swapin the<br /> entries that cross the end border and partially truncate the folio (split<br /> the folio or at least zero part of it). So in the second loop here, if we<br /> see a swap entry that crosses the end order, it must at least have its<br /> content erased already.<br /> <br /> I observed random swapoff hangs and kernel panics when stress testing<br /> ZSWAP with shmem. After applying this patch, all problems are gone.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: correctly decode TTLM with default link map<br /> <br /> TID-To-Link Mapping (TTLM) elements do not contain any link mapping<br /> presence indicator if a default mapping is used and parsing needs to be<br /> skipped.<br /> <br /> Note that access points should not explicitly report an advertised TTLM<br /> with a default mapping as that is the implied mapping if the element is<br /> not included, this is even the case when switching back to the default<br /> mapping. However, mac80211 would incorrectly parse the frame and would<br /> also read one byte beyond the end of the element.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix memory leak in set_ssp_complete<br /> <br /> Fix memory leak in set_ssp_complete() where mgmt_pending_cmd structures<br /> are not freed after being removed from the pending list.<br /> <br /> Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") replaced<br /> mgmt_pending_foreach() calls with individual command handling but missed<br /> adding mgmt_pending_free() calls in both error and success paths of<br /> set_ssp_complete(). Other completion functions like set_le_complete()<br /> were fixed correctly in the same commit.<br /> <br /> This causes a memory leak of the mgmt_pending_cmd structure and its<br /> associated parameter data for each SSP command that completes.<br /> <br /> Add the missing mgmt_pending_free(cmd) calls in both code paths to fix<br /> the memory leak. Also fix the same issue in set_advertising_complete().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().<br /> <br /> syzbot reported various memory leaks related to NFC, struct<br /> nfc_llcp_sock, sk_buff, nfc_dev, etc. [0]<br /> <br /> The leading log hinted that nfc_llcp_send_ui_frame() failed<br /> to allocate skb due to sock_error(sk) being -ENXIO.<br /> <br /> ENXIO is set by nfc_llcp_socket_release() when struct<br /> nfc_llcp_local is destroyed by local_cleanup().<br /> <br /> The problem is that there is no synchronisation between<br /> nfc_llcp_send_ui_frame() and local_cleanup(), and skb<br /> could be put into local-&gt;tx_queue after it was purged in<br /> local_cleanup():<br /> <br /> CPU1 CPU2<br /> ---- ----<br /> nfc_llcp_send_ui_frame() local_cleanup()<br /> |- do { &amp;#39;<br /> |- pdu = nfc_alloc_send_skb(..., &amp;err)<br /> | .<br /> | |- nfc_llcp_socket_release(local, false, ENXIO);<br /> | |- skb_queue_purge(&amp;local-&gt;tx_queue); |<br /> | &amp;#39; |<br /> |- skb_queue_tail(&amp;local-&gt;tx_queue, pdu); |<br /> ... |<br /> |- pdu = nfc_alloc_send_skb(..., &amp;err) |<br /> ^._________________________________.&amp;#39;<br /> <br /> local_cleanup() is called for struct nfc_llcp_local only<br /> after nfc_llcp_remove_local() unlinks it from llcp_devices.<br /> <br /> If we hold local-&gt;tx_queue.lock then, we can synchronise<br /> the thread and nfc_llcp_send_ui_frame().<br /> <br /> Let&amp;#39;s do that and check list_empty(&amp;local-&gt;list) before<br /> queuing skb to local-&gt;tx_queue in nfc_llcp_send_ui_frame().<br /> <br /> [0]:<br /> [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)<br /> [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> BUG: memory leak<br /> unreferenced object 0xffff8881272f6800 (size 1024):<br /> comm "syz.0.17", pid 6096, jiffies 4294942766<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 &amp;#39;..@............<br /> backtrace (crc da58d84d):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4979 [inline]<br /> slab_alloc_node mm/slub.c:5284 [inline]<br /> __do_kmalloc_node mm/slub.c:5645 [inline]<br /> __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239<br /> sk_alloc+0x36/0x360 net/core/sock.c:2295<br /> nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979<br /> llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044<br /> nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31<br /> __sock_create+0x1a9/0x340 net/socket.c:1605<br /> sock_create net/socket.c:1663 [inline]<br /> __sys_socket_create net/socket.c:1700 [inline]<br /> __sys_socket+0xb9/0x1a0 net/socket.c:1747<br /> __do_sys_socket net/socket.c:1761 [inline]<br /> __se_sys_socket net/socket.c:1759 [inline]<br /> __x64_sys_socket+0x1b/0x30 net/socket.c:1759<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810fbd9800 (size 240):<br /> comm "syz.0.17", pid 6096, jiffies 4294942850<br /> hex dump (first 32 bytes):<br /> 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.......<br /> 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/&amp;#39;....<br /> backtrace (crc 6cc652b1):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4979 [inline]<br /> slab_alloc_node mm/slub.c:5284 [inline]<br /> kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336<br /> __alloc_skb+0x203/0x240 net/core/skbuff.c:660<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0x69/0x3f0 net/core/sk<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl()<br /> <br /> Since GEM bo handles are u32 in the uapi and the internal implementation<br /> uses idr_alloc() which uses int ranges, passing a new handle larger than<br /> INT_MAX trivially triggers a kernel warning:<br /> <br /> idr_alloc():<br /> ...<br /> if (WARN_ON_ONCE(start