vdanen/rhvex-cve huggingface dataset:
CVE-2025-23141 (Moderate severity, published 2025-04-30)
CVSS score: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L)
CWE: CWE-284
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses

Acquire a lock on kvm->srcu when userspace is getting MP state to handle a
rather extreme edge case where "accepting" APIC events, i.e. processing
pending INIT or SIPI, can trigger accesses to guest memory.  If the vCPU
is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP
state will trigger a nested VM-Exit by way of ->check_nested_events(), and
emuating the nested VM-Exit can access guest memory.

The splat was originally hit by syzkaller on a Google-internal kernel, and
reproduced on an upstream kernel by hacking the triple_fault_event_test
selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a
memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.

  =============================
  WARNING: suspicious RCU usage
  6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
  -----------------------------
  include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  rcu_scheduler_active = 2, debug_locks = 1
  1 lock held by triple_fault_ev/1256:
   #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]

  stack backtrace:
  CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   <TASK>
   dump_stack_lvl+0x7f/0x90
   lockdep_rcu_suspicious+0x144/0x190
   kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]
   kvm_vcpu_read_guest+0x3e/0x90 [kvm]
   read_and_check_msr_entry+0x2e/0x180 [kvm_intel]
   __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]
   kvm_check_nested_events+0x1b/0x30 [kvm]
   kvm_apic_accept_events+0x33/0x100 [kvm]
   kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]
   kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]
   __x64_sys_ioctl+0x8b/0xb0
   do_syscall_64+0x6c/0x170
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   </TASK>
Statement: The security impact is limited by potentially accessing guest memory when KVM virtual machine being used.
Mitigation: To mitigate this issue, prevent module kvm from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
CVE-2025-47277 (Moderate severity, published 2025-05-20)
CVSS score: 7.5 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-502
Description: A flaw was found in vLLM. This vulnerability allows unauthorized access to key-value caches via network exposure of the `TCPStore` interface when using the `PyNcclPipe` KV cache transfer integration with the V0 engine.
Statement: By default, Red Hat products are configured to restrict vLLM nodes to an isolated network. However, this vulnerability could become relevant if customers change the specific configurations, and therefore, Red Hat products are affected.

This vulnerability is classified as Moderate rather than Critical because its exploitability and impact are constrained by specific deployment contexts and assumptions about network trust boundaries. While the use of pickle.loads on untrusted input typically leads to remote code execution (RCE), the vulnerable PyNcclPipe interface is not intended to be exposed to the internet or untrusted networks, it is designed for use within a secured, internal cluster environment as explicitly documented by vLLM. Successful exploitation requires an attacker to have direct network access to a misconfigured or poorly segmented system where the KV cache transfer service is bound to a public interface. Additionally, the vulnerable code path exists only in a niche configuration (V0 engine with PyNcclPipe), further reducing its exposure. Therefore, while the flaw does introduce RCE risk in misconfigured setups, the combination of non-default exposure, clear documentation, and limited applicability justifies a reduced impact.
Mitigation: No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability.
CVE-2025-38280 (Moderate severity, published 2025-07-09)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-670
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Avoid __bpf_prog_ret0_warn when jit fails

syzkaller reported an issue:

WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Modules linked in:
CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39
RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Call Trace:
 <TASK>
 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
 __bpf_prog_run include/linux/filter.h:718 [inline]
 bpf_prog_run include/linux/filter.h:725 [inline]
 cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
 ...

When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.
This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set
and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,
but jit failed due to FAULT_INJECTION. As a result, incorrectly
treats the program as valid, when the program runs it calls
`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).
Statement: A flaw was found in the BPF JIT selection logic. When CONFIG_BPF_JIT_ALWAYS_ON is not set and bpf_jit_enable=1, the system may attempt to JIT-compile a BPF program. If JIT compilation fails (e.g., due to fault injection or unsupported architecture), the program may still be treated as valid. When later executed, this leads to invocation of __bpf_prog_ret0_warn() which triggers WARN_ON_ONCE(1) and kernel warning. This issue was reported by syzkaller and occurs due to incorrectly treating a non-JITed program as valid. For the Red Hat Enterprise Linux the BPF not accessible by default (and only root user can enable it).
CVE-2025-23136 (Moderate severity, published 2025-04-15)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL.
This is similar to the commit cd2fd6eab480
("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in int3402_thermal_probe().

Note, under the same directory, int3400_thermal_probe() has such a
check.

[ rjw: Subject edit, added Fixes: ]
CVE-2025-21808 (Moderate severity, published 2025-02-26)
CVSS score: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-703
Description: In the Linux kernel, the following vulnerability has been resolved:

net: xdp: Disallow attaching device-bound programs in generic mode

Device-bound programs are used to support RX metadata kfuncs. These
kfuncs are driver-specific and rely on the driver context to read the
metadata. This means they can't work in generic XDP mode. However, there
is no check to disallow such programs from being attached in generic
mode, in which case the metadata kfuncs will be called in an invalid
context, leading to crashes.

Fix this by adding a check to disallow attaching device-bound programs
in generic mode.
CVE-2025-22232 (Moderate severity, published 2025-04-10)
CVSS score: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)
CWE: CWE-287
Description: Spring Cloud Config Server may not use Vault token sent by clients using a X-CONFIG-TOKEN header when making requests to Vault.
Your application may be affected by this if the following are true:
  *  You have Spring Vault on the classpath of your Spring Cloud Config Server and
  *  You are using the X-CONFIG-TOKEN header to send a Vault token to the Spring Cloud Config Server for the Config Server to use when making requests to Vault and
  *  You are using the default Spring Vault SessionManager implementation LifecycleAwareSessionManager or a SessionManager implementation that persists the Vault token such as SimpleSessionManager.

In this case the SessionManager persists the first token it retrieves and will continue to use that token even if client requests to the Spring Cloud Config Server include a X-CONFIG-TOKEN header with a different value.
Affected Spring Products and Versions
Spring Cloud Config:
  *  2.2.1.RELEASE - 4.2.1


Mitigation
Users of affected versions should upgrade to the corresponding fixed version.

Affected version(s)Fix versionAvailability4.2.x4.2.2OSS4.1.x4.1.6OSS4.0.x4.0.10Commercial3.1.x3.1.10Commercial3.0.x4.1.6OSS2.2.x4.1.6OSS
NOTE: Spring Cloud Config 3.0.x and 2.2.x are no longer under open source or commercial support. Users of these versions are encouraged to upgrade to a supported version.

No other mitigation steps are necessary.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-37933 (Moderate severity, published 2025-05-19)
CVSS score: 5.6 (CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H)
CWE: CWE-1341
Description: In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: Fix host hang issue during device reboot

When the host loses heartbeat messages from the device,
the driver calls the device-specific ndo_stop function,
which frees the resources. If the driver is unloaded in
this scenario, it calls ndo_stop again, attempting to free
resources that have already been freed, leading to a host
hang issue. To resolve this, dev_close should be called
instead of the device-specific stop function.dev_close
internally calls ndo_stop to stop the network interface
and performs additional cleanup tasks. During the driver
unload process, if the device is already down, ndo_stop
is not called.
CVE-2025-37899 (Low severity, published 2025-05-19)
CVSS score: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-416
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in session logoff

The sess->user object can currently be in use by another thread, for
example if another connection has sent a session setup request to
bind to the session being free'd. The handler for that connection could
be in the smb2_sess_setup function which makes use of sess->user.
CVE-2025-49005 (Low severity, published 2025-07-03)
CVSS score: 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N)
CWE: CWE-444
Description: A cache poisoning flaw has been discovered in Next.js. This flaw can allow page requests for HTML content to return a React Server Component (RSC) payload instead under certain conditions.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-37749 (Moderate severity, published 2025-04-30)
CVSS score: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H)
CWE: CWE-125
Description: An out-of-bounds read vulnerability exists in the ppp_sync_txmunge() function in the Linux kernel's PPP subsystem. Insufficient bounds checking on incoming PPP packets may lead to a kernel crash if a packet with an empty or truncated payload is processed.
Statement: This is rated Moderate because it involves an out-of-bounds read, not write, in the ppp_sync_txmunge() function, triggered by malformed PPP packets with insufficient linear data. While it can cause a kernel crash (DoS), exploitation is limited as PPP is not widely used or exposed in most modern systems. The affected path requires a crafted PPPoE packet and direct access to a PPP interface, reducing its overall impact and likelihood of exploitation.
Mitigation: No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability.
CVE-2025-38146 (Moderate severity, published 2025-07-02)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: Fix the dead loop of MPLS parse

The unexpected MPLS packet may not end with the bottom label stack.
When there are many stacks, The label count value has wrapped around.
A dead loop occurs, soft lockup/CPU stuck finally.

stack backtrace:
UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26
index -1 is out of range for type '__be32 [3]'
CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G           OE   5.15.0-121-generic #131-Ubuntu
Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021
Call Trace:
 <IRQ>
 show_stack+0x52/0x5c
 dump_stack_lvl+0x4a/0x63
 dump_stack+0x10/0x16
 ubsan_epilogue+0x9/0x36
 __ubsan_handle_out_of_bounds.cold+0x44/0x49
 key_extract_l3l4+0x82a/0x840 [openvswitch]
 ? kfree_skbmem+0x52/0xa0
 key_extract+0x9c/0x2b0 [openvswitch]
 ovs_flow_key_extract+0x124/0x350 [openvswitch]
 ovs_vport_receive+0x61/0xd0 [openvswitch]
 ? kernel_init_free_pages.part.0+0x4a/0x70
 ? get_page_from_freelist+0x353/0x540
 netdev_port_receive+0xc4/0x180 [openvswitch]
 ? netdev_port_receive+0x180/0x180 [openvswitch]
 netdev_frame_hook+0x1f/0x40 [openvswitch]
 __netif_receive_skb_core.constprop.0+0x23a/0xf00
 __netif_receive_skb_list_core+0xfa/0x240
 netif_receive_skb_list_internal+0x18e/0x2a0
 napi_complete_done+0x7a/0x1c0
 bnxt_poll+0x155/0x1c0 [bnxt_en]
 __napi_poll+0x30/0x180
 net_rx_action+0x126/0x280
 ? bnxt_msix+0x67/0x80 [bnxt_en]
 handle_softirqs+0xda/0x2d0
 irq_exit_rcu+0x96/0xc0
 common_interrupt+0x8e/0xa0
 </IRQ>
CVE-2025-5024 (Moderate severity, published 2025-05-21)
CVSS score: 7.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:H)
CWE: CWE-400
Description: A flaw was found in gnome-remote-desktop. Once gnome-remote-desktop listens for RDP connections, an unauthenticated attacker can exhaust system resources and repeatedly crash the process. There may be a resource leak after many attacks, which will also result in gnome-remote-desktop no longer being able to open files even after it is restarted via systemd.
Statement: The severity of this issue is considered moderate rather than important because successful exploitation requires the gnome-remote-desktop service to be actively configured and running in RDP mode, which is not enabled by default in most deployments. While the attack can be performed remotely and without authentication, it relies on sending specially crafted RDP packets that exploit a resource handling flaw, resulting in excessive consumption of system file descriptors and eventual denial of service. However, the vulnerability does not enable code execution, privilege escalation, or compromise of data integrity or confidentiality. The impact is therefore confined to service disruption rather than a direct security breach.

Additionally, the attack vector involves sustained resource abuse over time, requiring specific environmental conditions, such as systemd-managed user services with elevated file descriptor limits. This further limits the exploitability in default or hardened configurations. As such, the potential for widespread exploitation is constrained by the need for non-default service activation and prolonged interaction, reducing its overall security impact when compared to vulnerabilities that offer immediate compromise or broader applicability across system roles.
Mitigation: Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-21737 (Moderate severity, published 2025-02-26)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-401
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: fix memory leak in ceph_mds_auth_match()

We now free the temporary target path substring allocation on every
possible branch, instead of omitting the default branch.  In some
cases, a memory leak occured, which could rapidly crash the system
(depending on how many file accesses were attempted).

This was detected in production because it caused a continuous memory
growth, eventually triggering kernel OOM and completely hard-locking
the kernel.

Relevant kmemleak stacktrace:

    unreferenced object 0xffff888131e69900 (size 128):
      comm "git", pid 66104, jiffies 4295435999
      hex dump (first 32 bytes):
        76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65  volumes/containe
        72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67  rs/gitea/gitea/g
      backtrace (crc 2f3bb450):
        [<ffffffffaa68fb49>] __kmalloc_noprof+0x359/0x510
        [<ffffffffc32bf1df>] ceph_mds_check_access+0x5bf/0x14e0 [ceph]
        [<ffffffffc3235722>] ceph_open+0x312/0xd80 [ceph]
        [<ffffffffaa7dd786>] do_dentry_open+0x456/0x1120
        [<ffffffffaa7e3729>] vfs_open+0x79/0x360
        [<ffffffffaa832875>] path_openat+0x1de5/0x4390
        [<ffffffffaa834fcc>] do_filp_open+0x19c/0x3c0
        [<ffffffffaa7e44a1>] do_sys_openat2+0x141/0x180
        [<ffffffffaa7e4945>] __x64_sys_open+0xe5/0x1a0
        [<ffffffffac2cc2f7>] do_syscall_64+0xb7/0x210
        [<ffffffffac400130>] entry_SYSCALL_64_after_hwframe+0x77/0x7f

It can be triggered by mouting a subdirectory of a CephFS filesystem,
and then trying to access files on this subdirectory with an auth token
using a path-scoped capability:

    $ ceph auth get client.services
    [client.services]
            key = REDACTED
            caps mds = "allow rw fsname=cephfs path=/volumes/"
            caps mon = "allow r fsname=cephfs"
            caps osd = "allow rw tag cephfs data=cephfs"

    $ cat /proc/self/mounts
    services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=<hidden>,ms_mode=prefer-crc,mount_timeout=300,acl,mon_addr=[REDACTED]:3300,recover_session=clean 0 0

    $ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} && \
    seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}

[ idryomov: combine if statements, rename rc to path_matched and make
            it a bool, formatting ]
CVE-2025-38003 (Moderate severity, published 2025-06-07)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

can: bcm: add missing rcu read protection for procfs content

When the procfs content is generated for a bcm_op which is in the process
to be removed the procfs output might show unreliable data (UAF).

As the removal of bcm_op's is already implemented with rcu handling this
patch adds the missing rcu_read_lock() and makes sure the list entries
are properly removed under rcu protection.
CVE-2025-21672 (Moderate severity, published 2025-01-30)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-667
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix merge preference rule failure condition

syzbot reported a lock held when returning to userspace[1].  This is
because if argc is less than 0 and the function returns directly, the held
inode lock is not released.

Fix this by store the error in ret and jump to done to clean up instead of
returning directly.

[dh: Modified Lizhi Xu's original patch to make it honour the error code
from afs_split_string()]

[1]
WARNING: lock held when returning to user space!
6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted
------------------------------------------------
syz-executor133/5823 is leaving the kernel with locks still held!
1 lock held by syz-executor133/5823:
 #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline]
 #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388
CVE-2025-31672 (Moderate severity, published 2025-04-09)
CVSS score: 4.4 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N)
CWE: CWE-20
Description: A flaw was found in Apache POI's poi-ooxml component. This vulnerability allows attackers to manipulate file parsing behavior via specially crafted OOXML files containing ZIP entries with duplicate file names. Different systems can interpret these files differently, leading to inconsistent data processing or security issues.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2025-1088 (Low severity, published 2025-06-18)
CVSS score: 2.7 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L)
CWE: CWE-20
Description: In Grafana, an excessively long dashboard title or panel name will cause Chromium browsers to become unresponsive due to Improper Input Validation vulnerability in Grafana.
This issue affects Grafana: before 11.6.2 and is fixed in 11.6.2 and higher.
Mitigation: To mitigate this flaw limit dashboard titles and panel names to a reasonable length.
CVE-2025-37821 (Low severity, published 2025-05-07)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash

There is a code path in dequeue_entities() that can set the slice of a
sched_entity to U64_MAX, which sometimes results in a crash.

The offending case is when dequeue_entities() is called to dequeue a
delayed group entity, and then the entity's parent's dequeue is delayed.
In that case:

1. In the if (entity_is_task(se)) else block at the beginning of
   dequeue_entities(), slice is set to
   cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then
   it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.
2. The first for_each_sched_entity() loop dequeues the entity.
3. If the entity was its parent's only child, then the next iteration
   tries to dequeue the parent.
4. If the parent's dequeue needs to be delayed, then it breaks from the
   first for_each_sched_entity() loop _without updating slice_.
5. The second for_each_sched_entity() loop sets the parent's ->slice to
   the saved slice, which is still U64_MAX.

This throws off subsequent calculations with potentially catastrophic
results. A manifestation we saw in production was:

6. In update_entity_lag(), se->slice is used to calculate limit, which
   ends up as a huge negative number.
7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit
   is negative, vlag > limit, so se->vlag is set to the same huge
   negative number.
8. In place_entity(), se->vlag is scaled, which overflows and results in
   another huge (positive or negative) number.
9. The adjusted lag is subtracted from se->vruntime, which increases or
   decreases se->vruntime by a huge number.
10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which
    incorrectly returns false because the vruntime is so far from the
    other vruntimes on the queue, causing the
    (vruntime - cfs_rq->min_vruntime) * load calulation to overflow.
11. Nothing appears to be eligible, so pick_eevdf() returns NULL.
12. pick_next_entity() tries to dereference the return value of
    pick_eevdf() and crashes.

Dumping the cfs_rq states from the core dumps with drgn showed tell-tale
huge vruntime ranges and bogus vlag values, and I also traced se->slice
being set to U64_MAX on live systems (which was usually "benign" since
the rest of the runqueue needed to be in a particular state to crash).

Fix it in dequeue_entities() by always setting slice from the first
non-empty cfs_rq.