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 (http://nvd.nist.gov/) (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 (http://cve.mitre.org/) 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 (https://www.incibe.es/enfeed/vulnerabilities) or Newsletters (https://www.incibe.es/encert/simplenews/subscriptions/landing) 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-2024-35899

Publication date:
19/05/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: flush pending destroy work before exit_net release<br /> <br /> Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy<br /> work before netlink notifier") to address a race between exit_net and<br /> the destroy workqueue.<br /> <br /> The trace below shows an element to be released via destroy workqueue<br /> while exit_net path (triggered via module removal) has already released<br /> the set that is used in such transaction.<br /> <br /> [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465<br /> [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359<br /> [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]<br /> [ 1360.547984] Call Trace:<br /> [ 1360.547991] <br /> [ 1360.547998] dump_stack_lvl+0x53/0x70<br /> [ 1360.548014] print_report+0xc4/0x610<br /> [ 1360.548026] ? __virt_addr_valid+0xba/0x160<br /> [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.548176] kasan_report+0xae/0xe0<br /> [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]<br /> [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30<br /> [ 1360.548591] process_one_work+0x2f1/0x670<br /> [ 1360.548610] worker_thread+0x4d3/0x760<br /> [ 1360.548627] ? __pfx_worker_thread+0x10/0x10<br /> [ 1360.548640] kthread+0x16b/0x1b0<br /> [ 1360.548653] ? __pfx_kthread+0x10/0x10<br /> [ 1360.548665] ret_from_fork+0x2f/0x50<br /> [ 1360.548679] ? __pfx_kthread+0x10/0x10<br /> [ 1360.548690] ret_from_fork_asm+0x1a/0x30<br /> [ 1360.548707] <br /> <br /> [ 1360.548719] Allocated by task 192061:<br /> [ 1360.548726] kasan_save_stack+0x20/0x40<br /> [ 1360.548739] kasan_save_track+0x14/0x30<br /> [ 1360.548750] __kasan_kmalloc+0x8f/0xa0<br /> [ 1360.548760] __kmalloc_node+0x1f1/0x450<br /> [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]<br /> [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]<br /> [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]<br /> [ 1360.548927] netlink_unicast+0x367/0x4f0<br /> [ 1360.548935] netlink_sendmsg+0x34b/0x610<br /> [ 1360.548944] ____sys_sendmsg+0x4d4/0x510<br /> [ 1360.548953] ___sys_sendmsg+0xc9/0x120<br /> [ 1360.548961] __sys_sendmsg+0xbe/0x140<br /> [ 1360.548971] do_syscall_64+0x55/0x120<br /> [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d<br /> <br /> [ 1360.548994] Freed by task 192222:<br /> [ 1360.548999] kasan_save_stack+0x20/0x40<br /> [ 1360.549009] kasan_save_track+0x14/0x30<br /> [ 1360.549019] kasan_save_free_info+0x3b/0x60<br /> [ 1360.549028] poison_slab_object+0x100/0x180<br /> [ 1360.549036] __kasan_slab_free+0x14/0x30<br /> [ 1360.549042] kfree+0xb6/0x260<br /> [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]<br /> [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]<br /> [ 1360.549221] ops_exit_list+0x50/0xa0<br /> [ 1360.549229] free_exit_list+0x101/0x140<br /> [ 1360.549236] unregister_pernet_operations+0x107/0x160<br /> [ 1360.549245] unregister_pernet_subsys+0x1c/0x30<br /> [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]<br /> [ 1360.549345] __do_sys_delete_module+0x253/0x370<br /> [ 1360.549352] do_syscall_64+0x55/0x120<br /> [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d<br /> <br /> (gdb) list *__nft_release_table+0x473<br /> 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).<br /> 11349 list_for_each_entry_safe(flowtable, nf, &amp;table-&gt;flowtables, list) {<br /> 11350 list_del(&amp;flowtable-&gt;list);<br /> 11351 nft_use_dec(&amp;table-&gt;use);<br /> 11352 nf_tables_flowtable_destroy(flowtable);<br /> 11353 }<br /> 11354 list_for_each_entry_safe(set, ns, &amp;table-&gt;sets, list) {<br /> 11355 list_del(&amp;set-&gt;list);<br /> 11356 nft_use_dec(&amp;table-&gt;use);<br /> 11357 if (set-&gt;flags &amp; (NFT_SET_MAP | NFT_SET_OBJECT))<br /> 11358 nft_map_deactivat<br /> ---truncated---
Severity: Pending analysis
Last modification:
19/05/2024

CVE-2024-35900

Publication date:
19/05/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: reject new basechain after table flag update<br /> <br /> When dormant flag is toggled, hooks are disabled in the commit phase by<br /> iterating over current chains in table (existing and new).<br /> <br /> The following configuration allows for an inconsistent state:<br /> <br /> add table x<br /> add chain x y { type filter hook input priority 0; }<br /> add table x { flags dormant; }<br /> add chain x w { type filter hook input priority 1; }<br /> <br /> which triggers the following warning when trying to unregister chain w<br /> which is already unregistered.<br /> <br /> [ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260<br /> [...]<br /> [ 127.322519] Call Trace:<br /> [ 127.322521] <br /> [ 127.322524] ? __warn+0x9f/0x1a0<br /> [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260<br /> [ 127.322537] ? report_bug+0x1b1/0x1e0<br /> [ 127.322545] ? handle_bug+0x3c/0x70<br /> [ 127.322552] ? exc_invalid_op+0x17/0x40<br /> [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 127.322563] ? kasan_save_free_info+0x3b/0x60<br /> [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260<br /> [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260<br /> [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260<br /> [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]<br /> [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]<br /> [ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]
Severity: Pending analysis
Last modification:
19/05/2024

CVE-2024-35884

Publication date:
19/05/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: do not accept non-tunnel GSO skbs landing in a tunnel<br /> <br /> When rx-udp-gro-forwarding is enabled UDP packets might be GROed when<br /> being forwarded. If such packets might land in a tunnel this can cause<br /> various issues and udp_gro_receive makes sure this isn&amp;#39;t the case by<br /> looking for a matching socket. This is performed in<br /> udp4/6_gro_lookup_skb but only in the current netns. This is an issue<br /> with tunneled packets when the endpoint is in another netns. In such<br /> cases the packets will be GROed at the UDP level, which leads to various<br /> issues later on. The same thing can happen with rx-gro-list.<br /> <br /> We saw this with geneve packets being GROed at the UDP level. In such<br /> case gso_size is set; later the packet goes through the geneve rx path,<br /> the geneve header is pulled, the offset are adjusted and frag_list skbs<br /> are not adjusted with regard to geneve. When those skbs hit<br /> skb_fragment, it will misbehave. Different outcomes are possible<br /> depending on what the GROed skbs look like; from corrupted packets to<br /> kernel crashes.<br /> <br /> One example is a BUG_ON[1] triggered in skb_segment while processing the<br /> frag_list. Because gso_size is wrong (geneve header was pulled)<br /> skb_segment thinks there is "geneve header size" of data in frag_list,<br /> although it&amp;#39;s in fact the next packet. The BUG_ON itself has nothing to<br /> do with the issue. This is only one of the potential issues.<br /> <br /> Looking up for a matching socket in udp_gro_receive is fragile: the<br /> lookup could be extended to all netns (not speaking about performances)<br /> but nothing prevents those packets from being modified in between and we<br /> could still not find a matching socket. It&amp;#39;s OK to keep the current<br /> logic there as it should cover most cases but we also need to make sure<br /> we handle tunnel packets being GROed too early.<br /> <br /> This is done by extending the checks in udp_unexpected_gso: GSO packets<br /> lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must<br /> be segmented.<br /> <br /> [1] kernel BUG at net/core/skbuff.c:4408!<br /> RIP: 0010:skb_segment+0xd2a/0xf70<br /> __udp_gso_segment+0xaa/0x560
Severity: Pending analysis
Last modification:
19/05/2024

CVE-2024-35885

Publication date:
19/05/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxbf_gige: stop interface during shutdown<br /> <br /> The mlxbf_gige driver intermittantly encounters a NULL pointer<br /> exception while the system is shutting down via "reboot" command.<br /> The mlxbf_driver will experience an exception right after executing<br /> its shutdown() method. One example of this exception is:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000<br /> [0000000000000070] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] SMP<br /> CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1<br /> Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023<br /> pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]<br /> lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]<br /> sp : ffff8000080d3c10<br /> x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58<br /> x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008<br /> x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128<br /> x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff<br /> x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7<br /> x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101<br /> x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404<br /> x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080<br /> x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]<br /> mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]<br /> __napi_poll+0x40/0x1c8<br /> net_rx_action+0x314/0x3a0<br /> __do_softirq+0x128/0x334<br /> run_ksoftirqd+0x54/0x6c<br /> smpboot_thread_fn+0x14c/0x190<br /> kthread+0x10c/0x110<br /> ret_from_fork+0x10/0x20<br /> Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)<br /> ---[ end trace 7cc3941aa0d8e6a4 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> Kernel Offset: 0x4ce722520000 from 0xffff800008000000<br /> PHYS_OFFSET: 0x80000000<br /> CPU features: 0x000005c1,a3330e5a<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> During system shutdown, the mlxbf_gige driver&amp;#39;s shutdown() is always executed.<br /> However, the driver&amp;#39;s stop() method will only execute if networking interface<br /> configuration logic within the Linux distribution has been setup to do so.<br /> <br /> If shutdown() executes but stop() does not execute, NAPI remains enabled<br /> and this can lead to an exception if NAPI is scheduled while the hardware<br /> interface has only been partially deinitialized.<br /> <br /> The networking interface managed by the mlxbf_gige driver must be properly<br /> stopped during system shutdown so that IFF_UP is cleared, the hardware<br /> interface is put into a clean state, and NAPI is fully deinitialized.
Severity: Pending analysis
Last modification:
19/05/2024

CVE-2024-35886

Publication date:
19/05/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix infinite recursion in fib6_dump_done().<br /> <br /> syzkaller reported infinite recursive calls of fib6_dump_done() during<br /> netlink socket destruction. [1]<br /> <br /> From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then<br /> the response was generated. The following recvmmsg() resumed the dump<br /> for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due<br /> to the fault injection. [0]<br /> <br /> 12:01:34 executing program 3:<br /> r0 = socket$nl_route(0x10, 0x3, 0x0)<br /> sendmsg$nl_route(r0, ... snip ...)<br /> recvmmsg(r0, ... snip ...) (fail_nth: 8)<br /> <br /> Here, fib6_dump_done() was set to nlk_sk(sk)-&gt;cb.done, and the next call<br /> of inet6_dump_fib() set it to nlk_sk(sk)-&gt;cb.args[3]. syzkaller stopped<br /> receiving the response halfway through, and finally netlink_sock_destruct()<br /> called nlk_sk(sk)-&gt;cb.done().<br /> <br /> fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-&gt;cb.done() if it<br /> is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)-&gt;cb.done() by<br /> nlk_sk(sk)-&gt;cb.args[3], but it has the same function, not NULL, calling<br /> itself recursively and hitting the stack guard page.<br /> <br /> To avoid the issue, let&amp;#39;s set the destructor after kzalloc().<br /> <br /> [0]:<br /> FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 0<br /> CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:117)<br /> should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)<br /> should_failslab (mm/slub.c:3733)<br /> kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)<br /> inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)<br /> rtnl_dump_all (net/core/rtnetlink.c:4029)<br /> netlink_dump (net/netlink/af_netlink.c:2269)<br /> netlink_recvmsg (net/netlink/af_netlink.c:1988)<br /> ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)<br /> ___sys_recvmsg (net/socket.c:2846)<br /> do_recvmmsg (net/socket.c:2943)<br /> __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)<br /> <br /> [1]:<br /> BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)<br /> stack guard page: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events netlink_sock_destruct_work<br /> RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)<br /> Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff<br /> RSP: 0018:ffffc9000d980000 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3<br /> RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358<br /> RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000<br /> R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68<br /> FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> <br /> <br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> ...<br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))<br /> netlink_sock_destruct (net/netlink/af_netlink.c:401)<br /> __sk_destruct (net/core/sock.c:2177 (discriminator 2))<br /> sk_destruct (net/core/sock.c:2224)<br /> __sk_free (net/core/sock.c:2235)<br /> sk_free (net/core/sock.c:2246)<br /> process_one_work (kernel/workqueue.c:3259)<br /> worker_thread (kernel/workqueue.c:3329 kernel/workqueue.<br /> ---truncated---
Severity: Pending analysis
Last modification:
19/05/2024