Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate()<br /> <br /> cpufreq_cpu_get_raw() can return NULL when the target CPU is not present<br /> in the policy-&gt;cpus mask. apple_soc_cpufreq_get_rate() does not check<br /> for this case, which results in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()<br /> <br /> cpufreq_cpu_get_raw() can return NULL when the target CPU is not present<br /> in the policy-&gt;cpus mask. scpi_cpufreq_get_rate() does not check for<br /> this case, which results in a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort()<br /> <br /> A race can occur between the MCQ completion path and the abort handler:<br /> once a request completes, __blk_mq_free_request() sets rq-&gt;mq_hctx to<br /> NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in<br /> ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is<br /> dereferenced, the kernel will crash.<br /> <br /> Add a NULL check for the returned hwq pointer. If hwq is NULL, log an<br /> error and return FAILED, preventing a potential NULL-pointer<br /> dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is<br /> removed.<br /> <br /> This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix<br /> ufshcd_abort_one racing issue").<br /> <br /> This is found by our static analysis tool KNighter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads<br /> <br /> Fix niu_try_msix() to not cause a fatal trap on sparc systems.<br /> <br /> Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to<br /> work around a bug in the hardware or firmware.<br /> <br /> For each vector entry in the msix table, niu chips will cause a fatal<br /> trap if any registers in that entry are read before that entries&amp;#39;<br /> ENTRY_DATA register is written to. Testing indicates writes to other<br /> registers are not sufficient to prevent the fatal trap, however the value<br /> does not appear to matter. This only needs to happen once after power up,<br /> so simply rebooting into a kernel lacking this fix will NOT cause the<br /> trap.<br /> <br /> NON-RESUMABLE ERROR: Reporting on cpu 64<br /> NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <br /> NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff<br /> NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]<br /> NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]<br /> NON-RESUMABLE ERROR: type [precise nonresumable]<br /> NON-RESUMABLE ERROR: attrs [0x02000080] <br /> NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]<br /> NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]<br /> NON-RESUMABLE ERROR: size [0x8]<br /> NON-RESUMABLE ERROR: asi [0x00]<br /> CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63<br /> Workqueue: events work_for_cpu_fn<br /> TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted<br /> TPC: <br /> g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100<br /> g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000<br /> o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620<br /> o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128<br /> RPC: <br /> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020<br /> l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734<br /> i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d<br /> i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0<br /> I7: <br /> Call Trace:<br /> [] niu_try_msix.constprop.0+0xc0/0x130 [niu]<br /> [] niu_get_invariants+0x183c/0x207c [niu]<br /> [] niu_pci_init_one+0x27c/0x2fc [niu]<br /> [] local_pci_probe+0x28/0x74<br /> [] work_for_cpu_fn+0x8/0x1c<br /> [] process_scheduled_works+0x144/0x210<br /> [] worker_thread+0x13c/0x1c0<br /> [] kthread+0xb8/0xc8<br /> [] ret_from_fork+0x1c/0x2c<br /> [] 0x0<br /> Kernel panic - not syncing: Non-resumable error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmscan: don&amp;#39;t try to reclaim hwpoison folio<br /> <br /> Syzkaller reports a bug as follows:<br /> <br /> Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000<br /> Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users<br /> Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed<br /> page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e<br /> memcg:ffff0000dd6d9000<br /> anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)<br /> raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9<br /> raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000<br /> page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/swap_state.c:184!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : add_to_swap+0xbc/0x158<br /> lr : add_to_swap+0xbc/0x158<br /> sp : ffff800087f37340<br /> x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780<br /> x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0<br /> x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4<br /> x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000<br /> x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c<br /> x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b<br /> x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000<br /> x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001<br /> x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000<br /> Call trace:<br /> add_to_swap+0xbc/0x158<br /> shrink_folio_list+0x12ac/0x2648<br /> shrink_inactive_list+0x318/0x948<br /> shrink_lruvec+0x450/0x720<br /> shrink_node_memcgs+0x280/0x4a8<br /> shrink_node+0x128/0x978<br /> balance_pgdat+0x4f0/0xb20<br /> kswapd+0x228/0x438<br /> kthread+0x214/0x230<br /> ret_from_fork+0x10/0x20<br /> <br /> I can reproduce this issue with the following steps:<br /> <br /> 1) When a dirty swapcache page is isolated by reclaim process and the<br /> page isn&amp;#39;t locked, inject memory failure for the page. <br /> me_swapcache_dirty() clears uptodate flag and tries to delete from lru,<br /> but fails. Reclaim process will put the hwpoisoned page back to lru.<br /> <br /> 2) The process that maps the hwpoisoned page exits, the page is deleted<br /> the page will never be freed and will be in the lru forever.<br /> <br /> 3) If we trigger a reclaim again and tries to reclaim the page,<br /> add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is<br /> cleared.<br /> <br /> To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the<br /> hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap<br /> it in shrink_folio_list(), otherwise the folio will fail to be unmaped by<br /> hwpoison_user_mappings() since the folio isn&amp;#39;t in lru list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()<br /> <br /> cpufreq_cpu_get_raw() can return NULL when the target CPU is not present<br /> in the policy-&gt;cpus mask. scmi_cpufreq_get_rate() does not check for<br /> this case, which results in a NULL pointer dereference.<br /> <br /> Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix out-of-bounds access in nvmet_enable_port<br /> <br /> When trying to enable a port that has no transport configured yet,<br /> nvmet_enable_port() uses NVMF_TRTYPE_MAX (255) to query the transports<br /> array, causing an out-of-bounds access:<br /> <br /> [ 106.058694] BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da<br /> [ 106.058719] Read of size 8 at addr ffffffff89dafa58 by task ln/632<br /> [...]<br /> [ 106.076026] nvmet: transport type 255 not supported<br /> <br /> Since commit 200adac75888, NVMF_TRTYPE_MAX is the default state as configured by<br /> nvmet_ports_make().<br /> Avoid this by checking for NVMF_TRTYPE_MAX before proceeding.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix NULL pointer dereference in tipc_mon_reinit_self()<br /> <br /> syzbot reported:<br /> <br /> tipc: Node number set to 1055423674<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: events tipc_net_finalize_work<br /> RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719<br /> ...<br /> RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba<br /> RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010<br /> RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007<br /> R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010<br /> FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140<br /> process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3319 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400<br /> kthread+0x3c2/0x780 kernel/kthread.c:464<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> ...<br /> RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719<br /> ...<br /> RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba<br /> RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010<br /> RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007<br /> R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010<br /> FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> <br /> There is a racing condition between workqueue created when enabling<br /> bearer and another thread created when disabling bearer right after<br /> that as follow:<br /> <br /> enabling_bearer | disabling_bearer<br /> --------------- | ----------------<br /> tipc_disc_timeout() |<br /> { | bearer_disable()<br /> ... | {<br /> schedule_work(&amp;tn-&gt;work); | tipc_mon_delete()<br /> ... | {<br /> } | ...<br /> | write_lock_bh(&amp;mon-&gt;lock);<br /> | mon-&gt;self = NULL;<br /> | write_unlock_bh(&amp;mon-&gt;lock);<br /> | ...<br /> | }<br /> tipc_net_finalize_work() | }<br /> { |<br /> ... |<br /> tipc_net_finalize() |<br /> { |<br /> ... |<br /> tipc_mon_reinit_self() |<br /> { |<br /> ... |<br /> write_lock_bh(&amp;mon-&gt;lock); |<br /> mon-&gt;self-&gt;addr = tipc_own_addr(net); |<br /> write_unlock_bh(&amp;mon-&gt;lock); |<br /> ... <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too<br /> <br /> Similarly to the previous patch, we need to safe guard hfsc_dequeue()<br /> too. But for this one, we don&amp;#39;t have a reliable reproducer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: return EIO on RAID1 block group write pointer mismatch<br /> <br /> There was a bug report about a NULL pointer dereference in<br /> __btrfs_add_free_space_zoned() that ultimately happens because a<br /> conversion from the default metadata profile DUP to a RAID1 profile on two<br /> disks.<br /> <br /> The stack trace has the following signature:<br /> <br /> BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<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] PREEMPT SMP NOPTI<br /> RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0<br /> RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001<br /> RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410<br /> RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000<br /> R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000<br /> FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? page_fault_oops+0x15c/0x2f0<br /> ? exc_page_fault+0x7e/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0<br /> btrfs_add_free_space_async_trimmed+0x34/0x40<br /> btrfs_add_new_free_space+0x107/0x120<br /> btrfs_make_block_group+0x104/0x2b0<br /> btrfs_create_chunk+0x977/0xf20<br /> btrfs_chunk_alloc+0x174/0x510<br /> ? srso_return_thunk+0x5/0x5f<br /> btrfs_inc_block_group_ro+0x1b1/0x230<br /> btrfs_relocate_block_group+0x9e/0x410<br /> btrfs_relocate_chunk+0x3f/0x130<br /> btrfs_balance+0x8ac/0x12b0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __kmalloc_cache_noprof+0x14c/0x3e0<br /> btrfs_ioctl+0x2686/0x2a80<br /> ? srso_return_thunk+0x5/0x5f<br /> ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120<br /> __x64_sys_ioctl+0x97/0xc0<br /> do_syscall_64+0x82/0x160<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __memcg_slab_free_hook+0x11a/0x170<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kmem_cache_free+0x3f0/0x450<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? syscall_exit_to_user_mode+0x10/0x210<br /> ? srso_return_thunk+0x5/0x5f<br /> ? do_syscall_64+0x8e/0x160<br /> ? sysfs_emit+0xaf/0xc0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? seq_read_iter+0x207/0x460<br /> ? srso_return_thunk+0x5/0x5f<br /> ? vfs_read+0x29c/0x370<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? syscall_exit_to_user_mode+0x10/0x210<br /> ? srso_return_thunk+0x5/0x5f<br /> ? do_syscall_64+0x8e/0x160<br /> ? srso_return_thunk+0x5/0x5f<br /> ? exc_page_fault+0x7e/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdab1e0ca6d<br /> RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d<br /> RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003<br /> RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001<br /> <br /> CR2: 0000000000000058<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The 1st line is the most interesting here:<br /> <br /> BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile<br /> <br /> When a RAID1 block-group is created and a write pointer mismatch between<br /> the disks in the RAID set is detected, btrfs sets the alloc_offset to the<br /> length of the block group marking it as full. Afterwards the code expects<br /> that a balance operation will evacuate the data in this block-group and<br /> repair the problems.<br /> <br /> But before this is possible, the new space of this block-group will be<br /> accounted in the free space cache. But in __btrfs_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/eevdf: Fix se-&gt;slice being set to U64_MAX and resulting crash<br /> <br /> There is a code path in dequeue_entities() that can set the slice of a<br /> sched_entity to U64_MAX, which sometimes results in a crash.<br /> <br /> The offending case is when dequeue_entities() is called to dequeue a<br /> delayed group entity, and then the entity&amp;#39;s parent&amp;#39;s dequeue is delayed.<br /> In that case:<br /> <br /> 1. In the if (entity_is_task(se)) else block at the beginning of<br /> dequeue_entities(), slice is set to<br /> cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then<br /> it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.<br /> 2. The first for_each_sched_entity() loop dequeues the entity.<br /> 3. If the entity was its parent&amp;#39;s only child, then the next iteration<br /> tries to dequeue the parent.<br /> 4. If the parent&amp;#39;s dequeue needs to be delayed, then it breaks from the<br /> first for_each_sched_entity() loop _without updating slice_.<br /> 5. The second for_each_sched_entity() loop sets the parent&amp;#39;s -&gt;slice to<br /> the saved slice, which is still U64_MAX.<br /> <br /> This throws off subsequent calculations with potentially catastrophic<br /> results. A manifestation we saw in production was:<br /> <br /> 6. In update_entity_lag(), se-&gt;slice is used to calculate limit, which<br /> ends up as a huge negative number.<br /> 7. limit is used in se-&gt;vlag = clamp(vlag, -limit, limit). Because limit<br /> is negative, vlag &gt; limit, so se-&gt;vlag is set to the same huge<br /> negative number.<br /> 8. In place_entity(), se-&gt;vlag is scaled, which overflows and results in<br /> another huge (positive or negative) number.<br /> 9. The adjusted lag is subtracted from se-&gt;vruntime, which increases or<br /> decreases se-&gt;vruntime by a huge number.<br /> 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which<br /> incorrectly returns false because the vruntime is so far from the<br /> other vruntimes on the queue, causing the<br /> (vruntime - cfs_rq-&gt;min_vruntime) * load calulation to overflow.<br /> 11. Nothing appears to be eligible, so pick_eevdf() returns NULL.<br /> 12. pick_next_entity() tries to dereference the return value of<br /> pick_eevdf() and crashes.<br /> <br /> Dumping the cfs_rq states from the core dumps with drgn showed tell-tale<br /> huge vruntime ranges and bogus vlag values, and I also traced se-&gt;slice<br /> being set to U64_MAX on live systems (which was usually "benign" since<br /> the rest of the runqueue needed to be in a particular state to crash).<br /> <br /> Fix it in dequeue_entities() by always setting slice from the first<br /> non-empty cfs_rq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()<br /> <br /> The function xdp_convert_buff_to_frame() may return NULL if it fails<br /> to correctly convert the XDP buffer into an XDP frame due to memory<br /> constraints, internal errors, or invalid data. Failing to check for NULL<br /> may lead to a NULL pointer dereference if the result is used later in<br /> processing, potentially causing crashes, data corruption, or undefined<br /> behavior.<br /> <br /> On XDP redirect failure, the associated page must be released explicitly<br /> if it was previously retained via get_page(). Failing to do so may result<br /> in a memory leak, as the pages reference count is not decremented.