Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE  (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2026-43456

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix type confusion in bond_setup_by_slave()<br /> <br /> kernel BUG at net/core/skbuff.c:2306!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306<br /> RSP: 0018:ffffc90004aff760 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e<br /> RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900<br /> RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780<br /> R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900<br /> dev_hard_header include/linux/netdevice.h:3439 [inline]<br /> packet_snd net/packet/af_packet.c:3028 [inline]<br /> packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592<br /> ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646<br /> __sys_sendmsg+0x170/0x220 net/socket.c:2678<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe1a0e6c1a9<br /> <br /> When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,<br /> bond_setup_by_slave() directly copies the slave&amp;#39;s header_ops to the<br /> bond device:<br /> <br /> bond_dev-&gt;header_ops = slave_dev-&gt;header_ops;<br /> <br /> This causes a type confusion when dev_hard_header() is later called<br /> on the bond device. Functions like ipgre_header(), ip6gre_header(),all use<br /> netdev_priv(dev) to access their device-specific private data. When<br /> called with the bond device, netdev_priv() returns the bond&amp;#39;s private<br /> data (struct bonding) instead of the expected type (e.g. struct<br /> ip_tunnel), leading to garbage values being read and kernel crashes.<br /> <br /> Fix this by introducing bond_header_ops with wrapper functions that<br /> delegate to the active slave&amp;#39;s header_ops using the slave&amp;#39;s own<br /> device. This ensures netdev_priv() in the slave&amp;#39;s header functions<br /> always receives the correct device.<br /> <br /> The fix is placed in the bonding driver rather than individual device<br /> drivers, as the root cause is bond blindly inheriting header_ops from<br /> the slave without considering that these callbacks expect a specific<br /> netdev_priv() layout.<br /> <br /> The type confusion can be observed by adding a printk in<br /> ipgre_header() and running the following commands:<br /> <br /> ip link add dummy0 type dummy<br /> ip addr add 10.0.0.1/24 dev dummy0<br /> ip link set dummy0 up<br /> ip link add gre1 type gre local 10.0.0.1<br /> ip link add bond1 type bond mode active-backup<br /> ip link set gre1 master bond1<br /> ip link set gre1 up<br /> ip link set bond1 up<br /> ip addr add fe80::1/64 dev bond1
Severity CVSS v4.0: Pending analysis
Last modification:
20/05/2026

CVE-2026-43455

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: route: hold key-&gt;lock in mctp_flow_prepare_output()<br /> <br /> mctp_flow_prepare_output() checks key-&gt;dev and may call<br /> mctp_dev_set_key(), but it does not hold key-&gt;lock while doing so.<br /> <br /> mctp_dev_set_key() and mctp_dev_release_key() are annotated with<br /> __must_hold(&amp;key-&gt;lock), so key-&gt;dev access is intended to be<br /> serialized by key-&gt;lock. The mctp_sendmsg() transmit path reaches<br /> mctp_flow_prepare_output() via mctp_local_output() -&gt; mctp_dst_output()<br /> without holding key-&gt;lock, so the check-and-set sequence is racy.<br /> <br /> Example interleaving:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> mctp_flow_prepare_output(key, devA)<br /> if (!key-&gt;dev) // sees NULL<br /> mctp_flow_prepare_output(<br /> key, devB)<br /> if (!key-&gt;dev) // still NULL<br /> mctp_dev_set_key(devB, key)<br /> mctp_dev_hold(devB)<br /> key-&gt;dev = devB<br /> mctp_dev_set_key(devA, key)<br /> mctp_dev_hold(devA)<br /> key-&gt;dev = devA // overwrites devB<br /> <br /> Now both devA and devB references were acquired, but only the final<br /> key-&gt;dev value is tracked for release. One reference can be lost,<br /> causing a resource leak as mctp_dev_release_key() would only decrease<br /> the reference on one dev.<br /> <br /> Fix by taking key-&gt;lock around the key-&gt;dev check and<br /> mctp_dev_set_key() call.
Severity CVSS v4.0: Pending analysis
Last modification:
20/05/2026

CVE-2026-43454

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix for duplicate device in netdev hooks<br /> <br /> When handling NETDEV_REGISTER notification, duplicate device<br /> registration must be avoided since the device may have been added by<br /> nft_netdev_hook_alloc() already when creating the hook.
Severity CVSS v4.0: Pending analysis
Last modification:
20/05/2026

CVE-2026-43461

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic: spifc-a4: Fix DMA mapping error handling<br /> <br /> Fix three bugs in aml_sfc_dma_buffer_setup() error paths:<br /> 1. Unnecessary goto: When the first DMA mapping (sfc-&gt;daddr) fails,<br /> nothing needs cleanup. Use direct return instead of goto.<br /> 2. Double-unmap bug: When info DMA mapping failed, the code would<br /> unmap sfc-&gt;daddr inline, then fall through to out_map_data which<br /> would unmap it again, causing a double-unmap.<br /> 3. Wrong unmap size: The out_map_info label used datalen instead of<br /> infolen when unmapping sfc-&gt;iaddr, which could lead to incorrect<br /> DMA sync behavior.
Severity CVSS v4.0: Pending analysis
Last modification:
20/05/2026

CVE-2026-43460

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: rockchip-sfc: Fix double-free in remove() callback<br /> <br /> The driver uses devm_spi_register_controller() for registration, which<br /> automatically unregisters the controller via devm cleanup when the<br /> device is removed. The manual call to spi_unregister_controller() in<br /> the remove() callback can lead to a double-free.<br /> <br /> And to make sure controller is unregistered before DMA buffer is<br /> unmapped, switch to use spi_register_controller() in probe().
Severity CVSS v4.0: Pending analysis
Last modification:
20/05/2026

CVE-2026-43446

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix runtime suspend deadlock when there is pending job<br /> <br /> The runtime suspend callback drains the running job workqueue before<br /> suspending the device. If a job is still executing and calls<br /> pm_runtime_resume_and_get(), it can deadlock with the runtime suspend<br /> path.<br /> <br /> Fix this by moving pm_runtime_resume_and_get() from the job execution<br /> routine to the job submission routine, ensuring the device is resumed<br /> before the job is queued and avoiding the deadlock during runtime<br /> suspend.
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2026-43447

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: fix PTP use-after-free during reset<br /> <br /> Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a<br /> worker to cache PHC time, but failed to stop it during reset or disable.<br /> <br /> This creates a race condition where `iavf_reset_task()` or<br /> `iavf_disable_vf()` free adapter resources (AQ) while the worker is still<br /> running. If the worker triggers `iavf_queue_ptp_cmd()` during teardown, it<br /> accesses freed memory/locks, leading to a crash.<br /> <br /> Fix this by calling `iavf_ptp_release()` before tearing down the adapter.<br /> This ensures `ptp_clock_unregister()` synchronously cancels the worker and<br /> cleans up the chardev before the backing resources are destroyed.
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2026-43448

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: Fix race bug in nvme_poll_irqdisable()<br /> <br /> In the following scenario, pdev can be disabled between (1) and (3) by<br /> (2). This sets pdev-&gt;msix_enabled = 0. Then, pci_irq_vector() will<br /> return MSI-X IRQ(&gt;15) for (1) whereas return INTx IRQ(cq_vector)) ...(1)<br /> enable_irq(pci_irq_vector(pdev, nvmeq-&gt;cq_vector)) ...(3)<br /> <br /> task 2:<br /> nvme_reset_work()<br /> nvme_dev_disable()<br /> pdev-&gt;msix_enable = 0; ...(2)<br /> <br /> crash log:<br /> <br /> ------------[ cut here ]------------<br /> Unbalanced enable for IRQ 10<br /> WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kblockd blk_mq_timeout_work<br /> RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753<br /> Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9<br /> RSP: 0018:ffffc900001bf550 EFLAGS: 00010046<br /> RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90<br /> RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0<br /> RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001<br /> R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000<br /> R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293<br /> FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797<br /> nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494<br /> nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744<br /> blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]<br /> blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721<br /> bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292<br /> __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]<br /> sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]<br /> bt_for_each block/blk-mq-tag.c:324 [inline]<br /> blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536<br /> blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> irq event stamp: 74478<br /> hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]<br /> hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202<br /> hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]<br /> hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162<br /> softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline]<br /> softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline]<br /> softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2026-43449

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set<br /> <br /> dev-&gt;online_queues is a count incremented in nvme_init_queue. Thus,<br /> valid indices are 0 through dev-&gt;online_queues − 1.<br /> <br /> This patch fixes the loop condition to ensure the index stays within the<br /> valid range. Index 0 is excluded because it is the admin queue.<br /> <br /> KASAN splat:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]<br /> BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404<br /> Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74<br /> <br /> CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: nvme-reset-wq nvme_reset_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xce/0x5d0 mm/kasan/report.c:482<br /> kasan_report+0xdc/0x110 mm/kasan/report.c:595<br /> __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379<br /> nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]<br /> nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404<br /> nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> <br /> Allocated by task 34 on cpu 1 at 4.241550s:<br /> kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57<br /> kasan_save_track+0x1c/0x70 mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __do_kmalloc_node mm/slub.c:5657 [inline]<br /> __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663<br /> kmalloc_array_node_noprof include/linux/slab.h:1075 [inline]<br /> nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline]<br /> nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534<br /> local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324<br /> pci_call_probe drivers/pci/pci-driver.c:392 [inline]<br /> __pci_device_probe drivers/pci/pci-driver.c:417 [inline]<br /> pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451<br /> call_driver_probe drivers/base/dd.c:583 [inline]<br /> really_probe+0x29b/0xb70 drivers/base/dd.c:661<br /> __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803<br /> driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833<br /> __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159<br /> async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> The buggy address belongs to the object at ffff88800592a000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 244 bytes to the right of<br /> allocated 1152-byte region [ffff88800592a000, ffff88800592a480)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928<br /> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)<br /> page_type: f5(slab)<br /> raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001<br /> raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000<br /> head: 000fffffc0000040 ffff888001042000 00000<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2026-43450

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()<br /> <br /> nfnl_cthelper_dump_table() has a &amp;#39;goto restart&amp;#39; that jumps to a label<br /> inside the for loop body. When the "last" helper saved in cb-&gt;args[1]<br /> is deleted between dump rounds, every entry fails the (cur != last)<br /> check, so cb-&gt;args[1] is never cleared. The for loop finishes with<br /> cb-&gt;args[0] == nf_ct_helper_hsize, and the &amp;#39;goto restart&amp;#39; jumps back<br /> into the loop body bypassing the bounds check, causing an 8-byte<br /> out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].<br /> <br /> The &amp;#39;goto restart&amp;#39; block was meant to re-traverse the current bucket<br /> when "last" is no longer found, but it was placed after the for loop<br /> instead of inside it. Move the block into the for loop body so that<br /> the restart only occurs while cb-&gt;args[0] is still within bounds.<br /> <br /> BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0<br /> Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131<br /> Call Trace:<br /> nfnl_cthelper_dump_table+0x9f/0x1b0<br /> netlink_dump+0x333/0x880<br /> netlink_recvmsg+0x3e2/0x4b0<br /> sock_recvmsg+0xde/0xf0<br /> __sys_recvfrom+0x150/0x200<br /> __x64_sys_recvfrom+0x76/0x90<br /> do_syscall_64+0xc3/0x6e0<br /> <br /> Allocated by task 1:<br /> __kvmalloc_node_noprof+0x21b/0x700<br /> nf_ct_alloc_hashtable+0x65/0xd0<br /> nf_conntrack_helper_init+0x21/0x60<br /> nf_conntrack_init_start+0x18d/0x300<br /> nf_conntrack_standalone_init+0x12/0xc0
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2026-43451

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path<br /> <br /> nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue<br /> entry from the queue data structures, taking ownership of the entry.<br /> For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN<br /> attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN<br /> present but NFQA_VLAN_TCI missing), the function returns immediately<br /> without freeing the dequeued entry or its sk_buff.<br /> <br /> This leaks the nf_queue_entry, its associated sk_buff, and all held<br /> references (net_device refcounts, struct net refcount). Repeated<br /> triggering exhausts kernel memory.<br /> <br /> Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict<br /> on the error path, consistent with other error handling in this file.
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2026-43452

Publication date:
08/05/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: guard option walkers against 1-byte tail reads<br /> <br /> When the last byte of options is a non-single-byte option kind, walkers<br /> that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end<br /> of the option area.<br /> <br /> Add an explicit i == optlen - 1 check before dereferencing op[i + 1]<br /> in xt_tcpudp and xt_dccp option walkers.
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026