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

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails<br /> <br /> When loading a device-mapper table for a request-based mapped device,<br /> and the allocation/initialization of the blk_mq_tag_set for the device<br /> fails, a following device remove will cause a double free.<br /> <br /> E.g. (dmesg):<br /> device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device<br /> device-mapper: ioctl: unable to set up device queue for new table.<br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 0305e098835de000 TEID: 0305e098835de803<br /> Fault in home space mode while using kernel ASCE.<br /> AS:000000025efe0007 R3:0000000000000024<br /> Oops: 0038 ilc:3 [#1] SMP<br /> Modules linked in: ... lots of modules ...<br /> Supported: Yes, External<br /> CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3<br /> Hardware name: IBM 8561 T01 7I2 (LPAR)<br /> Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000<br /> 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000<br /> 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640<br /> 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8<br /> Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8<br /> 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58<br /> #000000025e368ec4: e3b010000008 ag %r11,0(%r1)<br /> &gt;000000025e368eca: e310b0080004 lg %r1,8(%r11)<br /> 000000025e368ed0: a7110001 tmll %r1,1<br /> 000000025e368ed4: a7740129 brc 7,25e369126<br /> 000000025e368ed8: e320b0080004 lg %r2,8(%r11)<br /> 000000025e368ede: b904001b lgr %r1,%r11<br /> Call Trace:<br /> [] kfree+0x42/0x330<br /> [] blk_mq_free_tag_set+0x72/0xb8<br /> [] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]<br /> [] free_dev+0x52/0xd0 [dm_mod]<br /> [] __dm_destroy+0x150/0x1d0 [dm_mod]<br /> [] dev_remove+0x162/0x1c0 [dm_mod]<br /> [] ctl_ioctl+0x198/0x478 [dm_mod]<br /> [] dm_ctl_ioctl+0x22/0x38 [dm_mod]<br /> [] ksys_ioctl+0xbe/0xe0<br /> [] __s390x_sys_ioctl+0x2a/0x40<br /> [] system_call+0xd8/0x2c8<br /> Last Breaking-Event-Address:<br /> [] blk_mq_free_tag_set+0x6c/0xb8<br /> Kernel panic - not syncing: Fatal exception: panic_on_oops<br /> <br /> When allocation/initialization of the blk_mq_tag_set fails in<br /> dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer<br /> is not reset to NULL; so when dev_remove() later gets into<br /> dm_mq_cleanup_mapped_device() it sees the pointer and tries to<br /> uninitialize and free it again.<br /> <br /> Fix this by setting the pointer to NULL in dm_mq_init_request_queue()<br /> error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46939

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Restructure trace_clock_global() to never block<br /> <br /> It was reported that a fix to the ring buffer recursion detection would<br /> cause a hung machine when performing suspend / resume testing. The<br /> following backtrace was extracted from debugging that case:<br /> <br /> Call Trace:<br /> trace_clock_global+0x91/0xa0<br /> __rb_reserve_next+0x237/0x460<br /> ring_buffer_lock_reserve+0x12a/0x3f0<br /> trace_buffer_lock_reserve+0x10/0x50<br /> __trace_graph_return+0x1f/0x80<br /> trace_graph_return+0xb7/0xf0<br /> ? trace_clock_global+0x91/0xa0<br /> ftrace_return_to_handler+0x8b/0xf0<br /> ? pv_hash+0xa0/0xa0<br /> return_to_handler+0x15/0x30<br /> ? ftrace_graph_caller+0xa0/0xa0<br /> ? trace_clock_global+0x91/0xa0<br /> ? __rb_reserve_next+0x237/0x460<br /> ? ring_buffer_lock_reserve+0x12a/0x3f0<br /> ? trace_event_buffer_lock_reserve+0x3c/0x120<br /> ? trace_event_buffer_reserve+0x6b/0xc0<br /> ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0<br /> ? dpm_run_callback+0x3b/0xc0<br /> ? pm_ops_is_empty+0x50/0x50<br /> ? platform_get_irq_byname_optional+0x90/0x90<br /> ? trace_device_pm_callback_start+0x82/0xd0<br /> ? dpm_run_callback+0x49/0xc0<br /> <br /> With the following RIP:<br /> <br /> RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200<br /> <br /> Since the fix to the recursion detection would allow a single recursion to<br /> happen while tracing, this lead to the trace_clock_global() taking a spin<br /> lock and then trying to take it again:<br /> <br /> ring_buffer_lock_reserve() {<br /> trace_clock_global() {<br /> arch_spin_lock() {<br /> queued_spin_lock_slowpath() {<br /> /* lock taken */<br /> (something else gets traced by function graph tracer)<br /> ring_buffer_lock_reserve() {<br /> trace_clock_global() {<br /> arch_spin_lock() {<br /> queued_spin_lock_slowpath() {<br /> /* DEAD LOCK! */<br /> <br /> Tracing should *never* block, as it can lead to strange lockups like the<br /> above.<br /> <br /> Restructure the trace_clock_global() code to instead of simply taking a<br /> lock to update the recorded "prev_time" simply use it, as two events<br /> happening on two different CPUs that calls this at the same time, really<br /> doesn&amp;#39;t matter which one goes first. Use a trylock to grab the lock for<br /> updating the prev_time, and if it fails, simply try again the next time.<br /> If it failed to be taken, that means something else is already updating<br /> it.<br /> <br /> <br /> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
Severity: Pending analysis
Last modification:
27/02/2024

CVE-2021-46941

Publication date:
27/02/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: core: Do core softreset when switch mode<br /> <br /> <br /> According to the programming guide, to switch mode for DRD controller,<br /> the driver needs to do the following.<br /> <br /> To switch from device to host:<br /> 1. Reset controller with GCTL.CoreSoftReset<br /> 2. Set GCTL.PrtCapDir(host mode)<br /> 3. Reset the host with USBCMD.HCRESET<br /> 4. Then follow up with the initializing host registers sequence<br /> <br /> To switch from host to device:<br /> 1. Reset controller with GCTL.CoreSoftReset<br /> 2. Set GCTL.PrtCapDir(device mode)<br /> 3. Reset the device with DCTL.CSftRst<br /> 4. Then follow up with the initializing registers sequence<br /> <br /> Currently we&amp;#39;re missing step 1) to do GCTL.CoreSoftReset and step 3) of<br /> switching from host to device. John Stult reported a lockup issue seen<br /> with HiKey960 platform without these steps[1]. Similar issue is observed<br /> with Ferry&amp;#39;s testing platform[2].<br /> <br /> So, apply the required steps along with some fixes to Yu Chen&amp;#39;s and John<br /> Stultz&amp;#39;s version. The main fixes to their versions are the missing wait<br /> for clocks synchronization before clearing GCTL.CoreSoftReset and only<br /> apply DCTL.CSftRst when switching from host to device.<br /> <br /> [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/<br /> [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
Severity: Pending analysis
Last modification:
27/02/2024

botón arriba