CVE Vulnerability Catalog

In the Linux kernel scheduler (sched/core), core scheduling's pick_next_task() breaks when a ->pick_task() implementation can release the rq lock. The selection state derived on entry is only valid while the lock is held continuously; once a pick can drop the lock, an interleaving selection can invalidate it, leading to an incorrect committed pick or skewed forceidle accounting.

In the Linux kernel scheduler (sched/core), core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. When a ->pick_task() releases the rq lock, every sibling __lock is momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was.

In the Linux kernel's sched_ext scheduler, the SCX_RQ_BAL_KEEP flag tells the pick to keep running the previous task, a leftover from when balancing and picking were separate operations. An rq-level flag only works while dispatches and picks pair up one to one, which core scheduling breaks: selections interleave through dispatch's lock drops and a pick can consume a stale flag, keeping a task that has since been dequeued.

A bug was fixed in the Linux kernel's sched_ext scheduler regarding dispatch kfuncs. Under core scheduling, ops.dispatch() may run on a different CPU than the dispatched rq, leading to incorrect assumptions in several kfunc paths, including a potential deadlock in scx_dsq_move() and incorrect resolution of SCX_DSQ_LOCAL.

In the Linux kernel, a bug in the sched_ext scheduler caused corruption of rq->core_pick state under core scheduling. When a task pick released the rq lock during dispatch, concurrent selections on the same SMT core corrupted each other's state, leading to a NULL deref or deadlock and hard hangs. The fix forces RETRY_TASK whenever dispatch released the lock, so a selection only commits picks made under a continuously held lock.

In the Linux kernel's sched_ext scheduler, scx_bpf_dsq_reenq() queues a deferred reenq (dru) that runs from run_deferred(), not ops.dispatch(). If the DSQ is destroyed before the dru runs, process_deferred_reenq_users() sees dsq->id == SCX_DSQ_INVALID and hits the BUG_ON. destroy_dsq() doesn't flush pending drus, so it should just skip.

A vulnerability exists in the Linux kernel SCSI subsystem where scsi_alloc_sgtables() leaves DMA padding bytes (pad_len) uninitialized for the last unaligned scatterlist element. This leads to an uninitialized memory read (detected by KMSAN) during DMA operations, potentially causing data leakage or system instability.

In the Linux kernel, the fnic (SCSI/FCoE) driver allocates a VLAN descriptor with GFP_KERNEL while holding the vlans_lock spinlock. GFP_KERNEL allocation may sleep, which is not allowed in this atomic context and can trigger a sleeping-from-invalid-context warning or deadlock.

In the Linux kernel, the RISC-V KVM implementation has an integer overflow in the PMU event info array size calculation. The guest-controlled num_events value is multiplied by sizeof(*einfo) and stored in a 32-bit integer, causing truncation for large values and allocation of an undersized buffer. The subsequent loop iterates over the original num_events, resulting in out-of-bounds reads and writes.

In the Linux kernel, the remoteproc subsystem (SCP driver) leaks a device reference on a failed driver data lookup before the driver has been bound. The reference taken to the SCP device is not dropped when the lookup fails.

In the Linux kernel, the qede driver (QLogic FastLinQ NIC) has a bug where memory pressure causes a NULL pointer dereference while processing TPA continuation fragments. Because tpa_info->buffer.data is not assigned in qede_tpa_start(), a "ghost" buffer with a valid DMA mapping but a NULL data pointer is pushed back into the Rx ring, causing a kernel panic in qede_fill_frag_skb().

In the Linux kernel, the RDMA/cxgb4 driver's c4iw_remove() can free ctx->dev while the queued reg_work (which registers the RDMA device) is still pending or running. This leaves c4iw_register_device() accessing the freed device.

In the Linux kernel, the RDMA/ionic driver was not adapted to the requirement of embedding struct rdma_counter in a driver-specific struct and registering its size via INIT_RDMA_OBJ_SIZE. As a result, rdma_zalloc_drv_obj() allocates zero bytes, causing a NULL pointer dereference in alloc_and_bind().

In the Linux kernel, ucma_set_ib_path() called ucma_event_handler() from the write() path without the handler lock that keeps ctx->file stable while a uevent is queued. A concurrent ucma_migrate_id() could reassign ctx->file, causing list operations on another file's event_list without the correct mutex, leading to a use-after-free (detected by KASAN).

A vulnerability in the Linux kernel RDMA/ucma module: ucma_write_cm_event() does not take the handler lock. While ucma_migrate_id() moves a context to another file, ctx->file can be swapped mid-sequence, causing list corruption, a permanently held mutex, and a process stuck in D state. The flaw is reachable by an unprivileged user via /dev/infiniband/rdma_cm.

In the Linux kernel, the RDMA/uverbs subsystem's UVERBS_METHOD_REG_MR method is missing the UVERBS_ATTR_UHW attribute, even though three drivers (mthca, irdma, siw) have UHW data associated with reg_mr and assume udata cannot be NULL. A malicious userspace process can trigger a NULL udata crash in those drivers.

In the Linux kernel, the RDMA/uverbs subsystem's legacy write() path passes a uverbs_attr_bundle to provider code without an ioctl method element. If malformed provider input causes the common validation code to emit an error message, uverbs_get_handler_fn() dereferences the uninitialized method_elm pointer.

In the Linux kernel's as3722_get_regulator_dt_data(), of_get_child_by_name() acquires a reference on np which is assigned to pdev->dev.of_node, but of_node_put(np) is then called immediately, releasing the reference and leaving a dangling pointer. Removing the of_node_put(np) call lets the device hold the reference.

In the Linux kernel ring-buffer subsystem, ring_buffer_alloc_read_page() races with ring_buffer_subbuf_order_set, potentially allocating a reader page with an outdated order. If subbuf_order changes mid-allocation, bpage->order may not match the actual allocated memory.

In the Linux kernel ring-buffer subsystem, when sub-buffers use an order greater than 0, cpu_buffer->free_page is allocated with subbuf_order. The fix ensures the correct order is used for cpu_buffer->free_page.