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-2021-46970

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue<br /> <br /> A recent change created a dedicated workqueue for the state-change work<br /> with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,<br /> but the state-change work (mhi_pm_st_worker) does not guarantee forward<br /> progress under memory pressure, and will even wait on various memory<br /> allocations when e.g. creating devices, loading firmware, etc... The<br /> work is then not part of a memory reclaim path...<br /> <br /> Moreover, this causes a warning in check_flush_dependency() since we end<br /> up in code that flushes a non-reclaim workqueue:<br /> <br /> [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog<br /> [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140<br /> [ 40.969733] Call Trace:<br /> [ 40.969740] __flush_work+0x97/0x1d0<br /> [ 40.969745] ? wake_up_process+0x15/0x20<br /> [ 40.969749] ? insert_work+0x70/0x80<br /> [ 40.969750] ? __queue_work+0x14a/0x3e0<br /> [ 40.969753] flush_work+0x10/0x20<br /> [ 40.969756] rollback_registered_many+0x1c9/0x510<br /> [ 40.969759] unregister_netdevice_queue+0x94/0x120<br /> [ 40.969761] unregister_netdev+0x1d/0x30<br /> [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]<br /> [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]<br /> [ 40.969776] device_release_driver_internal+0xf0/0x1d0<br /> [ 40.969778] device_release_driver+0x12/0x20<br /> [ 40.969782] bus_remove_device+0xe1/0x150<br /> [ 40.969786] device_del+0x17b/0x3e0<br /> [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]<br /> [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]<br /> [ 40.969799] device_for_each_child+0x5e/0xa0<br /> [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46972

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix leaked dentry<br /> <br /> Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in<br /> ovl_lookup()"), overlayfs doesn&amp;#39;t put temporary dentry when there is a<br /> metacopy error, which leads to dentry leaks when shutting down the related<br /> superblock:<br /> <br /> overlayfs: refusing to follow metacopy origin for (/file0)<br /> ...<br /> BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay]<br /> ...<br /> WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d<br /> CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1<br /> ...<br /> RIP: 0010:umount_check.cold+0x107/0x14d<br /> ...<br /> Call Trace:<br /> d_walk+0x28c/0x950<br /> ? dentry_lru_isolate+0x2b0/0x2b0<br /> ? __kasan_slab_free+0x12/0x20<br /> do_one_tree+0x33/0x60<br /> shrink_dcache_for_umount+0x78/0x1d0<br /> generic_shutdown_super+0x70/0x440<br /> kill_anon_super+0x3e/0x70<br /> deactivate_locked_super+0xc4/0x160<br /> deactivate_super+0xfa/0x140<br /> cleanup_mnt+0x22e/0x370<br /> __cleanup_mnt+0x1a/0x30<br /> task_work_run+0x139/0x210<br /> do_exit+0xb0c/0x2820<br /> ? __kasan_check_read+0x1d/0x30<br /> ? find_held_lock+0x35/0x160<br /> ? lock_release+0x1b6/0x660<br /> ? mm_update_next_owner+0xa20/0xa20<br /> ? reacquire_held_locks+0x3f0/0x3f0<br /> ? __sanitizer_cov_trace_const_cmp4+0x22/0x30<br /> do_group_exit+0x135/0x380<br /> __do_sys_exit_group.isra.0+0x20/0x20<br /> __x64_sys_exit_group+0x3c/0x50<br /> do_syscall_64+0x45/0x70<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> ...<br /> VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day...<br /> <br /> This fix has been tested with a syzkaller reproducer.
Severity: Pending analysis
Last modification:
27/02/2024

botón arriba