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-2023-52582

Publication date:
02/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Only call folio_start_fscache() one time for each folio<br /> <br /> If a network filesystem using netfs implements a clamp_length()<br /> function, it can set subrequest lengths smaller than a page size.<br /> <br /> When we loop through the folios in netfs_rreq_unlock_folios() to<br /> set any folios to be written back, we need to make sure we only<br /> call folio_start_fscache() once for each folio.<br /> <br /> Otherwise, this simple testcase:<br /> <br /> mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs<br /> dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1<br /> 1+0 records in<br /> 1+0 records out<br /> 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s<br /> echo 3 &gt; /proc/sys/vm/drop_caches<br /> cat /mnt/nfs/file.bin &gt; /dev/null<br /> <br /> will trigger an oops similar to the following:<br /> <br /> page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/netfs.h:44!<br /> ...<br /> CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5<br /> ...<br /> RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]<br /> ...<br /> Call Trace:<br /> netfs_rreq_assess+0x497/0x660 [netfs]<br /> netfs_subreq_terminated+0x32b/0x610 [netfs]<br /> nfs_netfs_read_completion+0x14e/0x1a0 [nfs]<br /> nfs_read_completion+0x2f9/0x330 [nfs]<br /> rpc_free_task+0x72/0xa0 [sunrpc]<br /> rpc_async_release+0x46/0x70 [sunrpc]<br /> process_one_work+0x3bd/0x710<br /> worker_thread+0x89/0x610<br /> kthread+0x181/0x1c0<br /> ret_from_fork+0x29/0x50
Severity: Pending analysis
Last modification:
02/03/2024

CVE-2023-52521

Publication date:
02/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Annotate bpf_long_memcpy with data_race<br /> <br /> syzbot reported a data race splat between two processes trying to<br /> update the same BPF map value via syscall on different CPUs:<br /> <br /> BUG: KCSAN: data-race in bpf_percpu_array_update / bpf_percpu_array_update<br /> <br /> write to 0xffffe8fffe7425d8 of 8 bytes by task 8257 on cpu 1:<br /> bpf_long_memcpy include/linux/bpf.h:428 [inline]<br /> bpf_obj_memcpy include/linux/bpf.h:441 [inline]<br /> copy_map_value_long include/linux/bpf.h:464 [inline]<br /> bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380<br /> bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749<br /> bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648<br /> __sys_bpf+0x28a/0x780<br /> __do_sys_bpf kernel/bpf/syscall.c:5241 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5239 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> write to 0xffffe8fffe7425d8 of 8 bytes by task 8268 on cpu 0:<br /> bpf_long_memcpy include/linux/bpf.h:428 [inline]<br /> bpf_obj_memcpy include/linux/bpf.h:441 [inline]<br /> copy_map_value_long include/linux/bpf.h:464 [inline]<br /> bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380<br /> bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749<br /> bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648<br /> __sys_bpf+0x28a/0x780<br /> __do_sys_bpf kernel/bpf/syscall.c:5241 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5239 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x0000000000000000 -&gt; 0xfffffff000002788<br /> <br /> The bpf_long_memcpy is used with 8-byte aligned pointers, power-of-8 size<br /> and forced to use long read/writes to try to atomically copy long counters.<br /> It is best-effort only and no barriers are here since it _will_ race with<br /> concurrent updates from BPF programs. The bpf_long_memcpy() is called from<br /> bpf(2) syscall. Marco suggested that the best way to make this known to<br /> KCSAN would be to use data_race() annotation.
Severity: Pending analysis
Last modification:
02/03/2024

CVE-2023-52523

Publication date:
02/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets<br /> <br /> With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages<br /> sent from one TCP socket (s1) to actually egress from another TCP<br /> socket (s2):<br /> <br /> tcp_bpf_sendmsg(s1) // = sk_prot-&gt;sendmsg<br /> tcp_bpf_send_verdict(s1) // __SK_REDIRECT case<br /> tcp_bpf_sendmsg_redir(s2)<br /> tcp_bpf_push_locked(s2)<br /> tcp_bpf_push(s2)<br /> tcp_rate_check_app_limited(s2) // expects tcp_sock<br /> tcp_sendmsg_locked(s2) // ditto<br /> <br /> There is a hard-coded assumption in the call-chain, that the egress<br /> socket (s2) is a TCP socket.<br /> <br /> However in commit 122e6c79efe1 ("sock_map: Update sock type checks for<br /> UDP") we have enabled redirects to non-TCP sockets. This was done for the<br /> sake of BPF sk_skb programs. There was no indention to support sk_msg<br /> send-to-egress use case.<br /> <br /> As a result, attempts to send-to-egress through a non-TCP socket lead to a<br /> crash due to invalid downcast from sock to tcp_sock:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000002f<br /> ...<br /> Call Trace:<br /> <br /> ? show_regs+0x60/0x70<br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x80/0x160<br /> ? do_user_addr_fault+0x2d7/0x800<br /> ? rcu_is_watching+0x11/0x50<br /> ? exc_page_fault+0x70/0x1c0<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? tcp_tso_segs+0x14/0xa0<br /> tcp_write_xmit+0x67/0xce0<br /> __tcp_push_pending_frames+0x32/0xf0<br /> tcp_push+0x107/0x140<br /> tcp_sendmsg_locked+0x99f/0xbb0<br /> tcp_bpf_push+0x19d/0x3a0<br /> tcp_bpf_sendmsg_redir+0x55/0xd0<br /> tcp_bpf_send_verdict+0x407/0x550<br /> tcp_bpf_sendmsg+0x1a1/0x390<br /> inet_sendmsg+0x6a/0x70<br /> sock_sendmsg+0x9d/0xc0<br /> ? sockfd_lookup_light+0x12/0x80<br /> __sys_sendto+0x10e/0x160<br /> ? syscall_enter_from_user_mode+0x20/0x60<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> ? lockdep_hardirqs_on+0x82/0x110<br /> __x64_sys_sendto+0x1f/0x30<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg<br /> program to prevent the crash. When attempted, user will receive an EACCES<br /> error from send/sendto/sendmsg() syscall.
Severity: Pending analysis
Last modification:
02/03/2024

CVE-2023-52527

Publication date:
02/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()<br /> <br /> Including the transhdrlen in length is a problem when the packet is<br /> partially filled (e.g. something like send(MSG_MORE) happened previously)<br /> when appending to an IPv4 or IPv6 packet as we don&amp;#39;t want to repeat the<br /> transport header or account for it twice. This can happen under some<br /> circumstances, such as splicing into an L2TP socket.<br /> <br /> The symptom observed is a warning in __ip6_append_data():<br /> <br /> WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800<br /> <br /> that occurs when MSG_SPLICE_PAGES is used to append more data to an already<br /> partially occupied skbuff. The warning occurs when &amp;#39;copy&amp;#39; is larger than<br /> the amount of data in the message iterator. This is because the requested<br /> length includes the transport header length when it shouldn&amp;#39;t. This can be<br /> triggered by, for example:<br /> <br /> sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);<br /> bind(sfd, ...); // ::1<br /> connect(sfd, ...); // ::1 port 7<br /> send(sfd, buffer, 4100, MSG_MORE);<br /> sendfile(sfd, dfd, NULL, 1024);<br /> <br /> Fix this by only adding transhdrlen into the length if the write queue is<br /> empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.<br /> <br /> l2tp_ip_sendmsg() looks like it won&amp;#39;t suffer from this problem as it builds<br /> the UDP packet itself.
Severity: Pending analysis
Last modification:
02/03/2024

CVE-2023-52528

Publication date:
02/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg<br /> <br /> syzbot reported the following uninit-value access issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x21c/0x280 lib/dump_stack.c:118<br /> kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121<br /> __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737<br /> usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032<br /> usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241<br /> usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554<br /> hub_port_connect drivers/usb/core/hub.c:5208 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]<br /> port_event drivers/usb/core/hub.c:5494 [inline]<br /> hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576<br /> process_one_work+0x1688/0x2140 kernel/workqueue.c:2269<br /> worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415<br /> kthread+0x551/0x590 kernel/kthread.c:292<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293<br /> <br /> Local variable ----buf.i87@smsc75xx_bind created at:<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> <br /> This issue is caused because usbnet_read_cmd() reads less bytes than requested<br /> (zero byte in the reproducer). In this case, &amp;#39;buf&amp;#39; is not properly filled.<br /> <br /> This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads<br /> less bytes than requested.
Severity: Pending analysis
Last modification:
02/03/2024

Go top