xamxte/cve-to-cwe huggingface dataset:
CVE-2026-23064: In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_ife: avoid possible NULL deref  tcf_ife_encode() must make sure ife_encode() does not return NULL.  syzbot reported:  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]  RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace:  <TASK>   ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101   tcf_ife_encode net/sched/act_ife.c:841 [inline]   tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877   tc_act include/net/tc_wrapper.h:130 [inline]   tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152   tcf_exts_exec include/net/pkt_cls.h:349 [inline]   mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42   tc_classify include/net/tc_wrapper.h:197 [inline]   __tcf_classify net/sched/cls_api.c:1764 [inline]   tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860   multiq_classify net/sched/sch_multiq.c:39 [inline]   multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66   dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147   __dev_xmit_skb net/core/dev.c:4262 [inline]   __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798
CVE-2026-23065: In the Linux kernel, the following vulnerability has been resolved:  platform/x86/amd: Fix memory leak in wbrf_record()  The tmp buffer is allocated using kcalloc() but is not freed if acpi_evaluate_dsm() fails. This causes a memory leak in the error path.  Fix this by explicitly freeing the tmp buffer in the error handling path of acpi_evaluate_dsm().
CVE-2026-23066: In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix recvmsg() unconditional requeue  If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued.  The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it.  The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns.  Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued.  If we don't queue it, we have to put the ref we obtained by dequeuing it.  Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.
CVE-2026-23067: In the Linux kernel, the following vulnerability has been resolved:  iommu/io-pgtable-arm: fix size_t signedness bug in unmap path  __arm_lpae_unmap() returns size_t but was returning -ENOENT (negative error code) when encountering an unmapped PTE. Since size_t is unsigned, -ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE on 64-bit systems).  This corrupted value propagates through the call chain:   __arm_lpae_unmap() returns -ENOENT as size_t   -> arm_lpae_unmap_pages() returns it   -> __iommu_unmap() adds it to iova address   -> iommu_pgsize() triggers BUG_ON due to corrupted iova  This can cause IOVA address overflow in __iommu_unmap() loop and trigger BUG_ON in iommu_pgsize() from invalid address alignment.  Fix by returning 0 instead of -ENOENT. The WARN_ON already signals the error condition, and returning 0 (meaning "nothing unmapped") is the correct semantic for size_t return type. This matches the behavior of other io-pgtable implementations (io-pgtable-arm-v7s, io-pgtable-dart) which return 0 on error conditions.
CVE-2026-23068: In the Linux kernel, the following vulnerability has been resolved:  spi: spi-sprd-adi: Fix double free in probe error path  The driver currently uses spi_alloc_host() to allocate the controller but registers it using devm_spi_register_controller().  If devm_register_restart_handler() fails, the code jumps to the put_ctlr label and calls spi_controller_put(). However, since the controller was registered via a devm function, the device core will automatically call spi_controller_put() again when the probe fails. This results in a double-free of the spi_controller structure.  Fix this by switching to devm_spi_alloc_host() and removing the manual spi_controller_put() call.
CVE-2026-23069: In the Linux kernel, the following vulnerability has been resolved:  vsock/virtio: fix potential underflow in virtio_transport_get_credit()  The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic:    ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);  If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle.  Reuse virtio_transport_has_space() which already handles this case and add a comment to make it clear why we are doing that.  [Stefano: use virtio_transport_has_space() instead of duplicating the code] [Stefano: tweak the commit message]
CVE-2026-23070: In the Linux kernel, the following vulnerability has been resolved:  Octeontx2-af: Add proper checks for fwdata  firmware populates MAC address, link modes (supported, advertised) and EEPROM data in shared firmware structure which kernel access via MAC block(CGX/RPM).  Accessing fwdata, on boards booted with out MAC block leading to kernel panics.  Internal error: Oops: 0000000096000005 [#1]  SMP [   10.460721] Modules linked in: [   10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT [   10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT) [   10.479793] Workqueue: events work_for_cpu_fn [   10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [   10.491124] pc : rvu_sdp_init+0x18/0x114 [   10.495051] lr : rvu_probe+0xe58/0x1d18
CVE-2026-23071: In the Linux kernel, the following vulnerability has been resolved:  regmap: Fix race condition in hwspinlock irqsave routine  Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner.  Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.
CVE-2026-23072: In the Linux kernel, the following vulnerability has been resolved:  l2tp: Fix memleak in l2tp_udp_encap_recv().  syzbot reported memleak of struct l2tp_session, l2tp_tunnel, sock, etc. [0]  The cited commit moved down the validation of the protocol version in l2tp_udp_encap_recv().  The new place requires an extra error handling to avoid the memleak.  Let's call l2tp_session_put() there.  [0]: BUG: memory leak unreferenced object 0xffff88810a290200 (size 512):   comm "syz.0.17", pid 6086, jiffies 4294944299   hex dump (first 32 bytes):     7d eb 04 0c 00 00 00 00 01 00 00 00 00 00 00 00  }...............     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................   backtrace (crc babb6a4f):     kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]     slab_post_alloc_hook mm/slub.c:4958 [inline]     slab_alloc_node mm/slub.c:5263 [inline]     __do_kmalloc_node mm/slub.c:5656 [inline]     __kmalloc_noprof+0x3e0/0x660 mm/slub.c:5669     kmalloc_noprof include/linux/slab.h:961 [inline]     kzalloc_noprof include/linux/slab.h:1094 [inline]     l2tp_session_create+0x3a/0x3b0 net/l2tp/l2tp_core.c:1778     pppol2tp_connect+0x48b/0x920 net/l2tp/l2tp_ppp.c:755     __sys_connect_file+0x7a/0xb0 net/socket.c:2089     __sys_connect+0xde/0x110 net/socket.c:2108     __do_sys_connect net/socket.c:2114 [inline]     __se_sys_connect net/socket.c:2111 [inline]     __x64_sys_connect+0x1c/0x30 net/socket.c:2111     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]     do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94     entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2026-23073: In the Linux kernel, the following vulnerability has been resolved:  wifi: rsi: Fix memory corruption due to not set vif driver data size  The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed.  The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure "struct vif_priv". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory.  In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash.  The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do "ip link set wlan0 up", "sleep 1", "ip link set wlan0 down" and the crash occurs.  Fix this by setting the correct size of vif driver data, which is the size of "struct vif_priv", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.
CVE-2026-23074: In the Linux kernel, the following vulnerability has been resolved:  net/sched: Enforce that teql can only be used as root qdisc  Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.  Although not important, I will describe the scenario that unearthed this issue for the curious.  GangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows:  ROOT qdisc 1:0 (QFQ)   ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s   └── class 1:2 (weight=1, lmax=1514) teql  GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.
CVE-2026-23075: In the Linux kernel, the following vulnerability has been resolved:  can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak  Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").  In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted).  However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close().  Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.
CVE-2026-23076: In the Linux kernel, the following vulnerability has been resolved:  ALSA: ctxfi: Fix potential OOB access in audio mixer handling  In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()).  As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]'  After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field.  This patch addresses those OOB accesses by adding the proper initializations of the loop indices.
CVE-2026-23078: In the Linux kernel, the following vulnerability has been resolved:  ALSA: scarlett2: Fix buffer overflow in config retrieval  The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1.  The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated.  Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.
CVE-2026-23079: In the Linux kernel, the following vulnerability has been resolved:  gpio: cdev: Fix resource leaks on errors in lineinfo_changed_notify()  On error handling paths, lineinfo_changed_notify() doesn't free the allocated resources which results leaks.  Fix it.
CVE-2026-23080: In the Linux kernel, the following vulnerability has been resolved:  can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak  Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").  In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted).  However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs().  Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.
CVE-2026-23081: In the Linux kernel, the following vulnerability has been resolved:  net: phy: intel-xway: fix OF node refcount leakage  Automated review spotted am OF node reference count leakage when checking if the 'leds' child node exists.  Call of_put_node() to correctly maintain the refcount.
CVE-2026-23082: In the Linux kernel, the following vulnerability has been resolved:  can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error  In commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"), the URB was re-anchored before usb_submit_urb() in gs_usb_receive_bulk_callback() to prevent a leak of this URB during cleanup.  However, this patch did not take into account that usb_submit_urb() could fail. The URB remains anchored and usb_kill_anchored_urbs(&parent->rx_submitted) in gs_can_close() loops infinitely since the anchor list never becomes empty.  To fix the bug, unanchor the URB when an usb_submit_urb() error occurs, also print an info message.
CVE-2026-23083: In the Linux kernel, the following vulnerability has been resolved:  fou: Don't allow 0 for FOU_ATTR_IPPROTO.  fou_udp_recv() has the same problem mentioned in the previous patch.  If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu().  Let's forbid 0 for FOU_ATTR_IPPROTO.
CVE-2026-23084: In the Linux kernel, the following vulnerability has been resolved:  be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list  When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function.  However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer.  To resolve this issue, it is necessary to pass the address of a stub variable to the function.
CVE-2026-23086: In the Linux kernel, the following vulnerability has been resolved:  vsock/virtio: cap TX credit to local buffer size  The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.  On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.  Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc.  This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.  On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.  With this patch applied:    Before:     MemFree:        ~61.6 GiB     Slab:           ~142 MiB     SUnreclaim:     ~117 MiB    After 32 high-credit connections:     MemFree:        ~61.5 GiB     Slab:           ~178 MiB     SUnreclaim:     ~152 MiB  Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.  Compatibility with non-virtio transports:    - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per     socket based on the local vsk->buffer_* values; the remote side     cannot enlarge those queues beyond what the local endpoint     configured.    - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and     an MTU bound; there is no peer-controlled credit field comparable     to peer_buf_alloc, and the remote endpoint cannot drive in-flight     kernel memory above those ring sizes.    - The loopback path reuses virtio_transport_common.c, so it     naturally follows the same semantics as the virtio transport.  This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.  [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]
CVE-2026-23087: In the Linux kernel, the following vulnerability has been resolved:  scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()  Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().
CVE-2026-23089: In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()  When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read.  Call trace:   get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411   get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241   mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381   snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887   ...   snd_card_register+0x4ed/0x6d0 sound/core/init.c:923   usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025  Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.
CVE-2026-23090: In the Linux kernel, the following vulnerability has been resolved:  slimbus: core: fix device reference leak on report present  Slimbus devices can be allocated dynamically upon reception of report-present messages.  Make sure to drop the reference taken when looking up already registered devices.  Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.
CVE-2026-23091: In the Linux kernel, the following vulnerability has been resolved:  intel_th: fix device leak on output open()  Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close().  Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().
CVE-2026-23092: In the Linux kernel, the following vulnerability has been resolved:  iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source  When simple_write_to_buffer() succeeds, it returns the number of bytes actually copied to the buffer. The code incorrectly uses 'count' as the index for null termination instead of the actual bytes copied. If count exceeds the buffer size, this leads to out-of-bounds write. Add a check for the count and use the return value as the index.  The bug was validated using a demo module that mirrors the original code and was tested under QEMU.  Pattern of the bug: - A fixed 64-byte stack buffer is filled using count. - If count > 64, the code still does buf[count] = '\0', causing an - out-of-bounds write on the stack.  Steps for reproduce: - Opens the device node. - Writes 128 bytes of A to it. - This overflows the 64-byte stack buffer and KASAN reports the OOB.  Found via static analysis. This is similar to the commit da9374819eb3 ("iio: backend: fix out-of-bound write")
CVE-2026-23094: In the Linux kernel, the following vulnerability has been resolved:  uacce: fix isolate sysfs check condition  uacce supports the device isolation feature. If the driver implements the isolate_err_threshold_read and isolate_err_threshold_write callback functions, uacce will create sysfs files now. Users can read and configure the isolation policy through sysfs. Currently, sysfs files are created as long as either isolate_err_threshold_read or isolate_err_threshold_write callback functions are present.  However, accessing a non-existent callback function may cause the system to crash. Therefore, intercept the creation of sysfs if neither read nor write exists; create sysfs if either is supported, but intercept unsupported operations at the call site.