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-64435

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: Fix data races of skb_queue_len() readers on audit_queue<br /> <br /> Multiple readers access audit_queue.qlen via skb_queue_len() without<br /> holding the queue lock or using READ_ONCE(), while kauditd writes to<br /> this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE()<br /> protected by a spinlock. This constitutes data races.<br /> <br /> All affected skb_queue_len(&amp;audit_queue) call sites:<br /> - kauditd_thread() wait_event_freezable() condition<br /> - audit_receive_msg() AUDIT_GET handler (s.backlog assignment)<br /> - audit_receive() backlog check<br /> - audit_log_start() backlog check and pr_warn()<br /> <br /> KCSAN reports the following conflicting access pattern (one example):<br /> ==================================================================<br /> BUG: KCSAN: data-race in audit_log_start / skb_dequeue<br /> <br /> write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57:<br /> skb_dequeue+0x70/0xf0<br /> kauditd_send_queue+0x71/0x220<br /> kauditd_thread+0x1cb/0x430<br /> kthread+0x1c2/0x210<br /> ret_from_fork+0x162/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1:<br /> audit_log_start+0x2a0/0x6b0<br /> audit_core_dumps+0x64/0xa0<br /> do_coredump+0x14b/0x1260<br /> get_signal+0xeb2/0xf70<br /> arch_do_signal_or_restart+0x41/0x170<br /> exit_to_user_mode_loop+0xa2/0x1c0<br /> do_syscall_64+0x1a3/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0xe0<br /> <br /> value changed: 0x00000001 -&gt; 0x00000000<br /> ==================================================================<br /> <br /> Resolve the race by switching to lockless helper skb_queue_len_lockless(),<br /> which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE()<br /> write accesses already present on the writer side.<br /> <br /> [PM: line length tweak]
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64429

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: eic-sprd: use raw_spinlock_t in the irq startup path<br /> <br /> sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller<br /> state through sprd_eic_update(), which takes sprd_eic-&gt;lock with<br /> spin_lock_irqsave(). The callback can be reached from irq_startup()<br /> while setting up a requested IRQ. That path is not sleepable, but on<br /> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;<br /> irq_startup() -&gt; sprd_eic_irq_unmask() -&gt; sprd_eic_update() carrier and<br /> used the original spin_lock_irqsave(&amp;sprd_eic-&gt;lock) edge. Lockdep<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]<br /> sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The<br /> locked section only serializes MMIO register updates and does not contain<br /> sleepable operations, so keeping it non-sleeping is appropriate for the<br /> irqchip callbacks.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64433

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete<br /> <br /> add_device_complete() runs from the hci_cmd_sync_work kworker, which<br /> holds only hci_req_sync_lock and *not* hci_dev_lock. It calls<br /> hci_conn_params_lookup() and then dereferences the returned object<br /> (params-&gt;flags) without taking hci_dev_lock:<br /> <br /> params = hci_conn_params_lookup(hdev, &amp;cp-&gt;addr.bdaddr,<br /> le_addr_type(cp-&gt;addr.type));<br /> ...<br /> device_flags_changed(NULL, hdev, &amp;cp-&gt;addr.bdaddr,<br /> cp-&gt;addr.type, hdev-&gt;conn_flags,<br /> params ? params-&gt;flags : 0);<br /> <br /> hci_conn_params_lookup() walks hdev-&gt;le_conn_params and is documented to<br /> require hdev-&gt;lock. A concurrent MGMT_OP_REMOVE_DEVICE<br /> (remove_device()), which does run under hci_dev_lock, can call<br /> hci_conn_params_free() to list_del() and kfree() the very object the<br /> lookup returned, so the subsequent params-&gt;flags read touches freed<br /> memory [0].<br /> <br /> Hold hci_dev_lock() across the hci_conn_params_lookup() and the read of<br /> params-&gt;flags (and the matching event emission) so the lookup result<br /> cannot be freed by a concurrent remove_device() before it is used,<br /> honouring the locking contract of hci_conn_params_lookup().<br /> <br /> [0]: (trailing page/memory-state dump trimmed)<br /> BUG: KASAN: slab-use-after-free in add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> Read of size 1 at addr ffff000017ab26c1 by task kworker/u9:8/388<br /> <br /> CPU: 1 UID: 0 PID: 388 Comm: kworker/u9:8 Not tainted 7.0.11 #20 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x118/0x5d8 mm/kasan/report.c:482<br /> kasan_report+0xb0/0xf4 mm/kasan/report.c:595<br /> __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378<br /> add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c:334<br /> process_one_work+0x628/0xd38 kernel/workqueue.c:3289<br /> process_scheduled_works kernel/workqueue.c:3372 [inline]<br /> worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453<br /> kthread+0x39c/0x444 kernel/kthread.c:436<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860<br /> <br /> Allocated by task 3401:<br /> kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57<br /> kasan_save_track+0x20/0x3c mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385<br /> kmalloc_noprof include/linux/slab.h:950 [inline]<br /> kzalloc_noprof include/linux/slab.h:1188 [inline]<br /> hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c:2279<br /> hci_conn_params_set net/bluetooth/mgmt.c:5162 [inline]<br /> add_device+0x5b4/0xa54 net/bluetooth/mgmt.c:7755<br /> hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline]<br /> hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe0/0x128 net/socket.c:742<br /> sock_write_iter+0x250/0x390 net/socket.c:1195<br /> new_sync_write fs/read_write.c:595 [inline]<br /> vfs_write+0x66c/0xab0 fs/read_write.c:688<br /> ksys_write+0x1fc/0x24c fs/read_write.c:740<br /> __do_sys_write fs/read_write.c:751 [inline]<br /> __se_sys_write fs/read_write.c:748 [inline]<br /> __arm64_sys_write+0x70/0xa4 fs/read_write.c:748<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724<br /> el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596<br /> <br /> Freed by task 3740:<br /> kasan_save_stack+0x3c/0x64 <br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64422

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes<br /> <br /> Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP<br /> socket state. The sysctl is stored as an `int` but copied into the<br /> `u32` `tp-&gt;reordering` field for new sockets, so negative writes wrap<br /> to large values.<br /> <br /> With `tcp_mtu_probing=2`, the wrapped value can overflow the<br /> `tcp_mtu_probe()` size calculation and drive the MTU probing path into<br /> an out-of-bounds read. Route `tcp_reordering` writes through<br /> `proc_dointvec_minmax()` and require it to be at least 1. Also require<br /> `tcp_max_reordering` to be at least 1 so the configured maximum cannot<br /> become negative either.<br /> <br /> When registering the table for a non-init network namespace, relocate<br /> `extra2` pointers that refer into `init_net.ipv4` so the<br /> `tcp_reordering` upper bound follows that namespace&amp;#39;s<br /> `tcp_max_reordering`.<br /> <br /> Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`.<br /> This keeps the send queue and window checks from being bypassed through<br /> signed integer overflow.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64423

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: igmp: remove multicast group from hash table on device destruction<br /> <br /> When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through<br /> the multicast list and calls ip_ma_put() on each membership, scheduling<br /> them for RCU reclamation. However, they are not unlinked from the device&amp;#39;s<br /> multicast hash table (mc_hash).<br /> <br /> Since the device remains published in dev-&gt;ip_ptr until after<br /> ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash<br /> can still locate and access the multicast group after its refcount is<br /> decremented. If the RCU callback runs and frees the group while a reader is<br /> accessing it, a use-after-free occurs.<br /> <br /> Fix this by unlinking the multicast group from mc_hash using<br /> ip_mc_hash_remove() before scheduling it for reclamation.<br /> <br /> BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0<br /> Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x67/0x90<br /> print_report+0x175/0x7c0<br /> kasan_report+0x147/0x180<br /> ip_check_mc_rcu+0x149/0x3f0<br /> udp_v4_early_demux+0x36d/0x12d0<br /> ip_rcv_finish_core+0xb8b/0x1390<br /> ip_rcv_finish+0x54/0x120<br /> NF_HOOK+0x213/0x2b0<br /> __netif_receive_skb+0x126/0x340<br /> process_backlog+0x4f2/0xf00<br /> __napi_poll+0x92/0x2c0<br /> net_rx_action+0x583/0xc60<br /> handle_softirqs+0x236/0x7f0<br /> do_softirq+0x57/0x80<br /> <br /> <br /> Allocated by task 2239:<br /> kasan_save_track+0x3e/0x80<br /> __kasan_kmalloc+0x72/0x90<br /> ____ip_mc_inc_group+0x31a/0xa40<br /> __ip_mc_join_group+0x334/0x3f0<br /> do_ip_setsockopt+0x16fa/0x2010<br /> ip_setsockopt+0x3f/0x90<br /> do_sock_setsockopt+0x1ad/0x300<br /> <br /> Freed by task 0:<br /> kasan_save_track+0x3e/0x80<br /> kasan_save_free_info+0x40/0x50<br /> __kasan_slab_free+0x3a/0x60<br /> __rcu_free_sheaf_prepare+0xd4/0x220<br /> rcu_free_sheaf+0x36/0x190<br /> rcu_core+0x8d9/0x12f0<br /> handle_softirqs+0x236/0x7f0
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64421

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Fix use-after-free on remove<br /> <br /> KASAN reports a slab-use-after-free in __media_entity_remove_link()<br /> during rmmod of imx8_isi:<br /> <br /> BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650<br /> Read of size 2 at addr ffff0000d47cb02a by task rmmod/724<br /> <br /> Call trace:<br /> __media_entity_remove_link+0x608/0x650<br /> __media_entity_remove_links+0x78/0x144<br /> __media_device_unregister_entity+0x150/0x280<br /> media_device_unregister_entity+0x48/0x68<br /> v4l2_device_unregister_subdev+0x158/0x300<br /> v4l2_async_unbind_subdev_one+0x22c/0x358<br /> v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0<br /> v4l2_async_nf_unregister+0x5c/0x14c<br /> mxc_isi_remove+0x124/0x2a0 [imx8_isi]<br /> <br /> Allocated by task 249:<br /> __kmalloc_noprof+0x27c/0x690<br /> mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi]<br /> <br /> Freed by task 724:<br /> kfree+0x1e4/0x5b0<br /> mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi]<br /> mxc_isi_remove+0x11c/0x2a0 [imx8_isi]<br /> <br /> The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup()<br /> before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media<br /> entity pads, but the subsequent v4l2 cleanup still tries to remove<br /> media links that reference those pads.<br /> <br /> Fix this by calling mxc_isi_v4l2_cleanup() before<br /> mxc_isi_crossbar_cleanup() to ensure all media entities are properly<br /> unregistered while the pads are still valid.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64424

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netpoll: fix a use-after-free on shutdown path<br /> <br /> There is a use-after-free error on netpoll, which is clearly detected by<br /> KASAN.<br /> <br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80<br /> Read of size 1 at addr ... by task kworker/9:1<br /> Workqueue: events queue_process<br /> Call Trace:<br /> skb_dequeue+0x1e/0xb0<br /> queue_process+0x2c/0x600<br /> process_scheduled_works+0x4b6/0x850<br /> worker_thread+0x414/0x5a0<br /> Allocated by task 242:<br /> __netpoll_setup+0x201/0x4a0<br /> netpoll_setup+0x249/0x550<br /> enabled_store+0x32f/0x380<br /> Freed by task 0:<br /> kfree+0x1b7/0x540<br /> rcu_core+0x3f8/0x7a0<br /> <br /> The problem happens when there is a pending TX worker running in<br /> parallel with the cleanup path.<br /> <br /> This is what happens on netpoll shutdown path:<br /> <br /> 1) __netpoll_cleanup() is called<br /> 2) set dev-&gt;npinfo to NULL<br /> 3) call_rcu() with rcu_cleanup_netpoll_info()<br /> 3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with<br /> cancel_delayed_work(), but doesn&amp;#39;t wait for the worker to finish<br /> 4) and kfree(npinfo);<br /> <br /> Because 3.1) doesn&amp;#39;t really cancel the work, as the comment says "we<br /> can&amp;#39;t call cancel_delayed_work_sync here, as we are in softirq", the TX<br /> worker can run after 4).<br /> <br /> Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through<br /> the work item via container_of().<br /> <br /> Use disable_delayed_work_sync() to ensure the worker is completely<br /> stopped and prevent any future re-arming attempts. Once npinfo is set<br /> to NULL, senders will bail out and not queue new work. The disable flag<br /> ensures any in-flight re-arming attempts also fail silently.<br /> <br /> In the future, we can do the cleanup inline here without needing the<br /> npinfo-&gt;rcu rcu_head, but that is net-next material.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64425

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item<br /> <br /> commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work<br /> run loop") fixed the obvious case where io_worker_handle_work() took one<br /> exit-bit snapshot before draining pending work, but the fix stops one<br /> level too early.<br /> <br /> io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work<br /> run loop, yet it still snapshots that bit once before processing a whole<br /> dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT<br /> after the first linked item has started, the remaining linked items can<br /> still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue<br /> running after exit has begun.<br /> <br /> Move the check further inside, so it covers linked items too. Note: this<br /> is a syzbot special as it loves setting up tons of slow linked work on<br /> weird devices like msr that take forever to read, and immediately close<br /> the ring. Exit then takes a long time.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64426

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE<br /> <br /> NOP file-acquisition support choses between a fixed (registered) file and<br /> a normal fget()&amp;#39;d file based on its own IORING_NOP_FIXED_FILE flag in<br /> sqe-&gt;nop_flags. However, a request&amp;#39;s REQ_F_FIXED_FILE is set<br /> independently from the generic IOSQE_FIXED_FILE sqe flag during request<br /> init, before the issue handler runs.<br /> <br /> If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is<br /> set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path<br /> and grabs a real reference via io_file_get_normal(). On completion,<br /> io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear,<br /> so the fget()&amp;#39;d file is never released and leaks:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88800f42c240 (size 176):<br /> kmem_cache_alloc_noprof+0x358/0x440<br /> alloc_empty_file+0x57/0x180<br /> path_openat+0x44/0x1e50<br /> do_file_open+0x121/0x200<br /> do_sys_openat2+0xa7/0x150<br /> __x64_sys_openat+0x82/0xf0<br /> <br /> Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE,<br /> the same way io_assign_file() does for every other opcode, and fold<br /> IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64427

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-dj: Fix maxfield check in DJ short report validation<br /> <br /> Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT<br /> related user initiated OOB write") added validation for the DJ short<br /> output report, but the error path dereferences rep-&gt;field[0] even when<br /> rep-&gt;maxfield is zero.<br /> <br /> Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad<br /> DJ_SHORT output report") made the check conditional on rep being present,<br /> but a crafted descriptor can still create report ID 0x20 with only padding<br /> output items. hid-core registers the report, ignores the padding field,<br /> and leaves rep-&gt;maxfield as zero.<br /> <br /> In that case the validation enters the rep-&gt;maxfield field[0]-&gt;report_count while printing the error message,<br /> causing a NULL pointer dereference during probe. This is reproducible with<br /> uhid by emulating a Logitech receiver with a padding-only DJ short output<br /> report:<br /> <br /> BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]<br /> Read of size 4 at addr 0000000000000028 by task kworker/4:1/129<br /> ...<br /> Call Trace:<br /> logi_dj_probe+0xb1/0x754 [hid_logitech_dj]<br /> hid_device_probe+0x329/0x3f0 [hid]<br /> really_probe+0x162/0x570<br /> __device_attach+0x137/0x2c0<br /> bus_probe_device+0x38/0xc0<br /> device_add+0xa56/0xce0<br /> hid_add_device+0x19c/0x280 [hid]<br /> uhid_device_add_worker+0x2c/0xb0 [uhid]<br /> <br /> Reject the zero-field report before printing the field report_count.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64428

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sch: use raw_spinlock_t in the irq startup path<br /> <br /> sch_irq_unmask() enables the GPIO IRQ and then updates the controller<br /> state through sch_irq_mask_unmask(), which takes sch-&gt;lock with<br /> spin_lock_irqsave(). The callback can be reached from irq_startup()<br /> while setting up a requested IRQ. That path is not sleepable, but on<br /> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;<br /> irq_startup() -&gt; sch_irq_unmask() -&gt; sch_irq_mask_unmask() carrier and<br /> used the original spin_lock_irqsave(&amp;sch-&gt;lock) edge. Lockdep reported:<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the SCH controller lock to raw_spinlock_t. The same lock is<br /> also used by the GPIO direction and value callbacks, but those critical<br /> sections only update MMIO-backed GPIO registers and do not contain<br /> sleepable operations. Keeping this register lock non-sleeping is<br /> therefore appropriate for the irqchip callbacks and does not change the<br /> GPIO-side locking contract.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026

CVE-2026-64413

Publication date:
25/07/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: zero chainstack array<br /> <br /> sashiko reports:<br /> looking at ebtables table<br /> translation, could a sparse cpu_possible_mask lead to an uninitialized pointer<br /> free?<br /> <br /> If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible,<br /> but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at<br /> CPU 2, the cleanup loop will blindly decrement and call vfree() on<br /> newinfo-&gt;chainstack[1].<br /> <br /> Not a real-world bug, such allocation isn&amp;#39;t expected to fail<br /> in the first place.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2026