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

botón arriba