rainbutterfly/cve_corpus huggingface dataset:
CVE-2026-23129 dpll: Prevent duplicate registrations
In the Linux kernel, the following vulnerability has been resolved:

dpll: Prevent duplicate registrations

Modify the internal registration helpers dpll_xa_ref_{dpll,pin}_add()
to reject duplicate registration attempts.

Previously, if a caller attempted to register the same pin multiple
times (with the same ops, priv, and cookie) on the same device, the core
silently increments the reference count and return success. This behavior
is incorrect because if the caller makes these duplicate registrations
then for the first one dpll_pin_registration is allocated and for others
the associated dpll_pin_ref.refcount is incremented. During the first
unregistration the associated dpll_pin_registration is freed and for
others WARN is fired.

Fix this by updating the logic to return `-EEXIST` if a matching
registration is found to enforce a strict "register once" policy.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:09:57.574Z
CVE-2026-23130 wifi: ath12k: fix dead lock while flushing management frames
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix dead lock while flushing management frames

Commit [1] converted the management transmission work item into a
wiphy work. Since a wiphy work can only run under wiphy lock
protection, a race condition happens in below scenario:

1. a management frame is queued for transmission.
2. ath12k_mac_op_flush() gets called to flush pending frames associated
   with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()
   the process waits for the transmission done.
3. Since wiphy lock has been taken by the flush process, the transmission
   work item has no chance to run, hence the dead lock.

>From user view, this dead lock results in below issue:

 wlp8s0: authenticate with xxxxxx (local address=xxxxxx)
 wlp8s0: send auth to xxxxxx (try 1/3)
 wlp8s0: authenticate with xxxxxx (local address=xxxxxx)
 wlp8s0: send auth to xxxxxx (try 1/3)
 wlp8s0: authenticated
 wlp8s0: associate with xxxxxx (try 1/3)
 wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)
 ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1

The dead lock can be avoided by invoking wiphy_work_flush() to proactively
run the queued work item. Note actually it is already present in
ath12k_mac_op_flush(), however it does not protect the case where vif
being NULL. Hence move it ahead to cover this case as well.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:09:58.239Z
CVE-2026-23131 platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names
In the Linux kernel, the following vulnerability has been resolved:

platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names

The hp-bioscfg driver attempts to register kobjects with empty names when
the HP BIOS returns attributes with empty name strings. This causes
multiple kernel warnings:

  kobject: (00000000135fb5e6): attempted to be registered with empty name!
  WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310

Add validation in hp_init_bios_buffer_attribute() to check if the
attribute name is empty after parsing it from the WMI buffer. If empty,
log a debug message and skip registration of that attribute, allowing the
module to continue processing other valid attributes.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:09:58.916Z
CVE-2026-23132 drm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind
In the Linux kernel, the following vulnerability has been resolved:

drm/bridge: synopsys: dw-dp: fix error paths of dw_dp_bind

Fix several issues in dw_dp_bind() error handling:

1. Missing return after drm_bridge_attach() failure - the function
   continued execution instead of returning an error.

2. Resource leak: drm_dp_aux_register() is not a devm function, so
   drm_dp_aux_unregister() must be called on all error paths after
   aux registration succeeds. This affects errors from:
   - drm_bridge_attach()
   - phy_init()
   - devm_add_action_or_reset()
   - platform_get_irq()
   - devm_request_threaded_irq()

3. Bug fix: platform_get_irq() returns the IRQ number or a negative
   error code, but the error path was returning ERR_PTR(ret) instead
   of ERR_PTR(dp->irq).

Use a goto label for cleanup to ensure consistent error handling.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:14:32.334Z
CVE-2026-23133 wifi: ath10k: fix dma_free_coherent() pointer
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: fix dma_free_coherent() pointer

dma_alloc_coherent() allocates a DMA mapped buffer and stores the
addresses in XXX_unaligned fields.  Those should be reused when freeing
the buffer rather than the aligned addresses.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:14:33.102Z
CVE-2026-23134 slab: fix kmalloc_nolock() context check for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:

slab: fix kmalloc_nolock() context check for PREEMPT_RT

On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current
check in kmalloc_nolock() only verifies we're not in NMI or hard IRQ
context, but misses the case where preemption is disabled.

When a BPF program runs from a tracepoint with preemption disabled
(preempt_count > 0), kmalloc_nolock() proceeds to call
local_lock_irqsave() which attempts to acquire a sleeping lock,
triggering:

  BUG: sleeping function called from invalid context
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128
  preempt_count: 2, expected: 0

Fix this by checking !preemptible() on PREEMPT_RT, which directly
expresses the constraint that we cannot take a sleeping lock when
preemption is disabled. This encompasses the previous checks for NMI
and hard IRQ contexts while also catching cases where preemption is
disabled.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:14:33.806Z
CVE-2026-23135 wifi: ath12k: fix dma_free_coherent() pointer
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix dma_free_coherent() pointer

dma_alloc_coherent() allocates a DMA mapped buffer and stores the
addresses in XXX_unaligned fields.  Those should be reused when freeing
the buffer rather than the aligned addresses.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:14:34.473Z
CVE-2026-23136 libceph: reset sparse-read state in osd_fault()
In the Linux kernel, the following vulnerability has been resolved:

libceph: reset sparse-read state in osd_fault()

When a fault occurs, the connection is abandoned, reestablished, and any
pending operations are retried. The OSD client tracks the progress of a
sparse-read reply using a separate state machine, largely independent of
the messenger's state.

If a connection is lost mid-payload or the sparse-read state machine
returns an error, the sparse-read state is not reset. The OSD client
will then interpret the beginning of a new reply as the continuation of
the old one. If this makes the sparse-read machinery enter a failure
state, it may never recover, producing loops like:

  libceph:  [0] got 0 extents
  libceph: data len 142248331 != extent len 0
  libceph: osd0 (1)...:6801 socket error on read
  libceph: data len 142248331 != extent len 0
  libceph: osd0 (1)...:6801 socket error on read

Therefore, reset the sparse-read state in osd_fault(), ensuring retries
start from a clean state.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
baseScore: 7.5
baseSeverity: HIGH
Published: 2026-02-14T15:22:21.952Z
CVE-2026-23137 of: unittest: Fix memory leak in unittest_data_add()
In the Linux kernel, the following vulnerability has been resolved:

of: unittest: Fix memory leak in unittest_data_add()

In unittest_data_add(), if of_resolve_phandles() fails, the allocated
unittest_data is not freed, leading to a memory leak.

Fix this by using scope-based cleanup helper __free(kfree) for automatic
resource cleanup. This ensures unittest_data is automatically freed when
it goes out of scope in error paths.

For the success path, use retain_and_null_ptr() to transfer ownership
of the memory to the device tree and prevent double freeing.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:22:22.690Z
CVE-2026-23138 tracing: Add recursion protection in kernel stack trace recording
In the Linux kernel, the following vulnerability has been resolved:

tracing: Add recursion protection in kernel stack trace recording

A bug was reported about an infinite recursion caused by tracing the rcu
events with the kernel stack trace trigger enabled. The stack trace code
called back into RCU which then called the stack trace again.

Expand the ftrace recursion protection to add a set of bits to protect
events from recursion. Each bit represents the context that the event is
in (normal, softirq, interrupt and NMI).

Have the stack trace code use the interrupt context to protect against
recursion.

Note, the bug showed an issue in both the RCU code as well as the tracing
stacktrace code. This only handles the tracing stack trace side of the
bug. The RCU fix will be handled separately.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:22:23.385Z
CVE-2026-23139 netfilter: nf_conncount: update last_gc only when GC has been performed
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conncount: update last_gc only when GC has been performed

Currently last_gc is being updated everytime a new connection is
tracked, that means that it is updated even if a GC wasn't performed.
With a sufficiently high packet rate, it is possible to always bypass
the GC, causing the list to grow infinitely.

Update the last_gc value only when a GC has been actually performed.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
baseScore: 7.5
baseSeverity: HIGH
Published: 2026-02-14T15:22:24.059Z
CVE-2026-23140 bpf, test_run: Subtract size of xdp_frame from allowed metadata size
In the Linux kernel, the following vulnerability has been resolved:

bpf, test_run: Subtract size of xdp_frame from allowed metadata size

The xdp_frame structure takes up part of the XDP frame headroom,
limiting the size of the metadata. However, in bpf_test_run, we don't
take this into account, which makes it possible for userspace to supply
a metadata size that is too large (taking up the entire headroom).

If userspace supplies such a large metadata size in live packet mode,
the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call
will fail, after which packet transmission proceeds with an
uninitialised frame structure, leading to the usual Bad Stuff.

The commit in the Fixes tag fixed a related bug where the second check
in xdp_update_frame_from_buff() could fail, but did not add any
additional constraints on the metadata size. Complete the fix by adding
an additional check on the metadata size. Reorder the checks slightly to
make the logic clearer and add a comment.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:22:24.727Z
CVE-2026-23141 btrfs: send: check for inline extents in range_is_hole_in_parent()
In the Linux kernel, the following vulnerability has been resolved:

btrfs: send: check for inline extents in range_is_hole_in_parent()

Before accessing the disk_bytenr field of a file extent item we need
to check if we are dealing with an inline extent.
This is because for inline extents their data starts at the offset of
the disk_bytenr field. So accessing the disk_bytenr
means we are accessing inline data or in case the inline data is less
than 8 bytes we can actually cause an invalid
memory access if this inline extent item is the first item in the leaf
or access metadata from other items.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:36:07.417Z
CVE-2026-23142 mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure
In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure

When a DAMOS-scheme DAMON sysfs directory setup fails after setup of
access_pattern/ directory, subdirectories of access_pattern/ directory are
not cleaned up.  As a result, DAMON sysfs interface is nearly broken until
the system reboots, and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:36:08.147Z
CVE-2026-23143 virtio_net: Fix misalignment bug in struct virtnet_info
In the Linux kernel, the following vulnerability has been resolved:

virtio_net: Fix misalignment bug in struct virtnet_info

Use the new TRAILING_OVERLAP() helper to fix a misalignment bug
along with the following warning:

drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

This helper creates a union between a flexible-array member (FAM)
and a set of members that would otherwise follow it (in this case
`u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This
overlays the trailing members (rss_hash_key_data) onto the FAM
(hash_key_data) while keeping the FAM and the start of MEMBERS aligned.
The static_assert() ensures this alignment remains.

Notice that due to tail padding in flexible `struct
virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`
(at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at
offset 84 in struct virtnet_info) are misaligned by one byte. See
below:

struct virtio_net_rss_config_trailer {
        __le16                     max_tx_vq;            /*     0     2 */
        __u8                       hash_key_length;      /*     2     1 */
        __u8                       hash_key_data[];      /*     3     0 */

        /* size: 4, cachelines: 1, members: 3 */
        /* padding: 1 */
        /* last cacheline: 4 bytes */
};

struct virtnet_info {
...
        struct virtio_net_rss_config_trailer rss_trailer; /*    80     4 */

        /* XXX last struct has 1 byte of padding */

        u8                         rss_hash_key_data[40]; /*    84    40 */
...
        /* size: 832, cachelines: 13, members: 48 */
        /* sum members: 801, holes: 8, sum holes: 31 */
        /* paddings: 2, sum paddings: 5 */
};

After changes, those members are correctly aligned at offset 795:

struct virtnet_info {
...
        union {
                struct virtio_net_rss_config_trailer rss_trailer; /*   792     4 */
                struct {
                        unsigned char __offset_to_hash_key_data[3]; /*   792     3 */
                        u8         rss_hash_key_data[40]; /*   795    40 */
                };                                       /*   792    43 */
        };                                               /*   792    44 */
...
        /* size: 840, cachelines: 14, members: 47 */
        /* sum members: 801, holes: 8, sum holes: 35 */
        /* padding: 4 */
        /* paddings: 1, sum paddings: 4 */
        /* last cacheline: 8 bytes */
};

As a result, the RSS key passed to the device is shifted by 1
byte: the last byte is cut off, and instead a (possibly
uninitialized) byte is added at the beginning.

As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also
moved to the end, since it seems those three members should stick
around together. :)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:36:08.834Z
CVE-2026-23144 mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure
In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure

When a context DAMON sysfs directory setup is failed after setup of attrs/
directory, subdirectories of attrs/ directory are not cleaned up.  As a
result, DAMON sysfs interface is nearly broken until the system reboots,
and the memory for the unremoved directory is leaked.

Cleanup the directories under such failures.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:36:09.518Z
CVE-2026-23145 ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref
In the Linux kernel, the following vulnerability has been resolved:

ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref

The error branch for ext4_xattr_inode_update_ref forget to release the
refcount for iloc.bh. Find this when review code.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T15:36:10.207Z
CVE-2026-23146 Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work

hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling
hci_uart_register_dev(), which calls proto->open() to initialize
hu->priv. However, if a TTY write wakeup occurs during this window,
hci_uart_tx_wakeup() may schedule write_work before hu->priv is
initialized, leading to a NULL pointer dereference in
hci_uart_write_work() when proto->dequeue() accesses hu->priv.

The race condition is:

  CPU0                              CPU1
  ----                              ----
  hci_uart_set_proto()
    set_bit(HCI_UART_PROTO_INIT)
    hci_uart_register_dev()
                                    tty write wakeup
                                      hci_uart_tty_wakeup()
                                        hci_uart_tx_wakeup()
                                          schedule_work(&hu->write_work)
      proto->open(hu)
        // initializes hu->priv
                                    hci_uart_write_work()
                                      hci_uart_dequeue()
                                        proto->dequeue(hu)
                                          // accesses hu->priv (NULL!)

Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open()
succeeds, ensuring hu->priv is initialized before any work can be
scheduled.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T16:01:16.169Z
CVE-2026-23147 btrfs: zlib: fix the folio leak on S390 hardware acceleration
In the Linux kernel, the following vulnerability has been resolved:

btrfs: zlib: fix the folio leak on S390 hardware acceleration

[BUG]
After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration
buffer preparation"), we no longer release the folio of the page cache
of folio returned by btrfs_compress_filemap_get_folio() for S390
hardware acceleration path.

[CAUSE]
Before that commit, we call kumap_local() and folio_put() after handling
each folio.

Although the timing is not ideal (it release previous folio at the
beginning of the loop, and rely on some extra cleanup out of the loop),
it at least handles the folio release correctly.

Meanwhile the refactored code is easier to read, it lacks the call to
release the filemap folio.

[FIX]
Add the missing folio_put() for copy_data_into_buffer().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T16:01:16.917Z
CVE-2026-23148 nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference
In the Linux kernel, the following vulnerability has been resolved:

nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference

There is a race condition in nvmet_bio_done() that can cause a NULL
pointer dereference in blk_cgroup_bio_start():

1. nvmet_bio_done() is called when a bio completes
2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req)
3. The queue_response callback can re-queue and re-submit the same request
4. The re-submission reuses the same inline_bio from nvmet_req
5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete)
   invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL
6. The re-submitted bio enters submit_bio_noacct_nocheck()
7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash:

  BUG: kernel NULL pointer dereference, address: 0000000000000028
  #PF: supervisor read access in kernel mode
  RIP: 0010:blk_cgroup_bio_start+0x10/0xd0
  Call Trace:
   submit_bio_noacct_nocheck+0x44/0x250
   nvmet_bdev_execute_rw+0x254/0x370 [nvmet]
   process_one_work+0x193/0x3c0
   worker_thread+0x281/0x3a0

Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put()
BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before
the request can be re-submitted, preventing the race condition.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
CVSS v3.1: version: 3.1
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
baseScore: 7.5
baseSeverity: HIGH
Published: 2026-02-14T16:01:17.575Z
CVE-2026-23149 drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl()
In the Linux kernel, the following vulnerability has been resolved:

drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl()

Since GEM bo handles are u32 in the uapi and the internal implementation
uses idr_alloc() which uses int ranges, passing a new handle larger than
INT_MAX trivially triggers a kernel warning:

idr_alloc():
...
	if (WARN_ON_ONCE(start < 0))
		return -EINVAL;
...

Fix it by rejecting new handles above INT_MAX and at the same time make
the end limit calculation more obvious by moving into int domain.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2026-02-14T16:01:18.281Z