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 (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 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 or Newsletters 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-2022-49945

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (gpio-fan) Fix array out of bounds access<br /> <br /> The driver does not check if the cooling state passed to<br /> gpio_fan_set_cur_state() exceeds the maximum cooling state as<br /> stored in fan_data-&gt;num_speeds. Since the cooling state is later<br /> used as an array index in set_fan_speed(), an array out of bounds<br /> access can occur.<br /> This can be exploited by setting the state of the thermal cooling device<br /> to arbitrary values, causing for example a kernel oops when unavailable<br /> memory is accessed this way.<br /> <br /> Example kernel oops:<br /> [ 807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064<br /> [ 807.987369] Mem abort info:<br /> [ 807.987398] ESR = 0x96000005<br /> [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 807.987477] SET = 0, FnV = 0<br /> [ 807.987507] EA = 0, S1PTW = 0<br /> [ 807.987536] FSC = 0x05: level 1 translation fault<br /> [ 807.987570] Data abort info:<br /> [ 807.987763] ISV = 0, ISS = 0x00000005<br /> [ 807.987801] CM = 0, WnR = 0<br /> [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000<br /> [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP<br /> [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6<br /> [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575<br /> [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)<br /> [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]<br /> [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]<br /> [ 807.988691] sp : ffffffc008cf3bd0<br /> [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000<br /> [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920<br /> [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c<br /> [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000<br /> [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70<br /> [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c<br /> [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009<br /> [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8<br /> [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060<br /> [ 807.989084] Call trace:<br /> [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan]<br /> [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]<br /> [ 807.989199] cur_state_store+0x84/0xd0<br /> [ 807.989221] dev_attr_store+0x20/0x38<br /> [ 807.989262] sysfs_kf_write+0x4c/0x60<br /> [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0<br /> [ 807.989298] new_sync_write+0x10c/0x190<br /> [ 807.989315] vfs_write+0x254/0x378<br /> [ 807.989362] ksys_write+0x70/0xf8<br /> [ 807.989379] __arm64_sys_write+0x24/0x30<br /> [ 807.989424] invoke_syscall+0x4c/0x110<br /> [ 807.989442] el0_svc_common.constprop.3+0xfc/0x120<br /> [ 807.989458] do_el0_svc+0x2c/0x90<br /> [ 807.989473] el0_svc+0x24/0x60<br /> [ 807.989544] el0t_64_sync_handler+0x90/0xb8<br /> [ 807.989558] el0t_64_sync+0x1a0/0x1a4<br /> [ 807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)<br /> [ 807.989627] ---[ end t<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49946

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: bcm: rpi: Prevent out-of-bounds access<br /> <br /> The while loop in raspberrypi_discover_clocks() relies on the assumption<br /> that the id of the last clock element is zero. Because this data comes<br /> from the Videocore firmware and it doesn&amp;#39;t guarantuee such a behavior<br /> this could lead to out-of-bounds access. So fix this by providing<br /> a sentinel element.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49947

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix alloc-&gt;vma_vm_mm null-ptr dereference<br /> <br /> Syzbot reported a couple issues introduced by commit 44e602b4e52f<br /> ("binder_alloc: add missing mmap_lock calls when using the VMA"), in<br /> which we attempt to acquire the mmap_lock when alloc-&gt;vma_vm_mm has not<br /> been initialized yet.<br /> <br /> This can happen if a binder_proc receives a transaction without having<br /> previously called mmap() to setup the binder_proc-&gt;alloc space in [1].<br /> Also, a similar issue occurs via binder_alloc_print_pages() when we try<br /> to dump the debugfs binder stats file in [2].<br /> <br /> Sample of syzbot&amp;#39;s crash report:<br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]<br /> CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0<br /> syz-executor229[3755] cmdline: ./syz-executor2294415195<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022<br /> RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923<br /> [...]<br /> Call Trace:<br /> <br /> lock_acquire kernel/locking/lockdep.c:5666 [inline]<br /> lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631<br /> down_read+0x98/0x450 kernel/locking/rwsem.c:1499<br /> mmap_read_lock include/linux/mmap_lock.h:117 [inline]<br /> binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline]<br /> binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593<br /> binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199<br /> binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986<br /> binder_ioctl_write_read drivers/android/binder.c:5036 [inline]<br /> binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> ==================================================================<br /> <br /> Fix these issues by setting up alloc-&gt;vma_vm_mm pointer during open()<br /> and caching directly from current-&gt;mm. This guarantees we have a valid<br /> reference to take the mmap_lock during scenarios described above.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459<br /> [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49948

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: Clear selection before changing the font<br /> <br /> When changing the console font with ioctl(KDFONTOP) the new font size<br /> can be bigger than the previous font. A previous selection may thus now<br /> be outside of the new screen size and thus trigger out-of-bounds<br /> accesses to graphics memory if the selection is removed in<br /> vc_do_resize().<br /> <br /> Prevent such out-of-memory accesses by dropping the selection before the<br /> various con_font_set() console handlers are called.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49949

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: Fix memory leak in firmware upload<br /> <br /> In the case of firmware-upload, an instance of struct fw_upload is<br /> allocated in firmware_upload_register(). This data needs to be freed<br /> in fw_dev_release(). Create a new fw_upload_free() function in<br /> sysfs_upload.c to handle the firmware-upload specific memory frees<br /> and incorporate the missing kfree call for the fw_upload structure.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49935

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/dma-resv: check if the new fence is really later<br /> <br /> Previously when we added a fence to a dma_resv object we always<br /> assumed the the newer than all the existing fences.<br /> <br /> With Jason&amp;#39;s work to add an UAPI to explicit export/import that&amp;#39;s not<br /> necessary the case any more. So without this check we would allow<br /> userspace to force the kernel into an use after free error.<br /> <br /> Since the change is very small and defensive it&amp;#39;s probably a good<br /> idea to backport this to stable kernels as well just in case others<br /> are using the dma_resv object in the same way.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49936

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Prevent nested device-reset calls<br /> <br /> Automatic kernel fuzzing revealed a recursive locking violation in<br /> usb-storage:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 5.18.0 #3 Not tainted<br /> --------------------------------------------<br /> kworker/1:3/1205 is trying to acquire lock:<br /> ffff888018638db8 (&amp;us_interface_key[i]){+.+.}-{3:3}, at:<br /> usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230<br /> <br /> but task is already holding lock:<br /> ffff888018638db8 (&amp;us_interface_key[i]){+.+.}-{3:3}, at:<br /> usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230<br /> <br /> ...<br /> <br /> stack backtrace:<br /> CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_deadlock_bug kernel/locking/lockdep.c:2988 [inline]<br /> check_deadlock kernel/locking/lockdep.c:3031 [inline]<br /> validate_chain kernel/locking/lockdep.c:3816 [inline]<br /> __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053<br /> lock_acquire kernel/locking/lockdep.c:5665 [inline]<br /> lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630<br /> __mutex_lock_common kernel/locking/mutex.c:603 [inline]<br /> __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747<br /> usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230<br /> usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109<br /> r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622<br /> usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458<br /> device_remove drivers/base/dd.c:545 [inline]<br /> device_remove+0x11f/0x170 drivers/base/dd.c:537<br /> __device_release_driver drivers/base/dd.c:1222 [inline]<br /> device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248<br /> usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627<br /> usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118<br /> usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114<br /> <br /> This turned out not to be an error in usb-storage but rather a nested<br /> device reset attempt. That is, as the rtl8712 driver was being<br /> unbound from a composite device in preparation for an unrelated USB<br /> reset (that driver does not have pre_reset or post_reset callbacks),<br /> its -&gt;remove routine called usb_reset_device() -- thus nesting one<br /> reset call within another.<br /> <br /> Performing a reset as part of disconnect processing is a questionable<br /> practice at best. However, the bug report points out that the USB<br /> core does not have any protection against nested resets. Adding a<br /> reset_in_progress flag and testing it will prevent such errors in the<br /> future.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49937

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mceusb: Use new usb_control_msg_*() routines<br /> <br /> Automatic kernel fuzzing led to a WARN about invalid pipe direction in<br /> the mceusb driver:<br /> <br /> ------------[ cut here ]------------<br /> usb 6-1: BOGUS control dir, pipe 80000380 doesn&amp;#39;t match bRequestType 40<br /> WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410<br /> usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410<br /> Modules linked in:<br /> CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410<br /> Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8<br /> 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 0b<br /> e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41<br /> RSP: 0018:ffffc900032becf0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000<br /> RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90<br /> RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000<br /> R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000<br /> R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500<br /> FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58<br /> usb_internal_control_msg drivers/usb/core/message.c:102 [inline]<br /> usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153<br /> mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]<br /> mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807<br /> <br /> The reason for the warning is clear enough; the driver sends an<br /> unusual read request on endpoint 0 but does not set the USB_DIR_IN bit<br /> in the bRequestType field.<br /> <br /> More importantly, the whole situation can be avoided and the driver<br /> simplified by converting it over to the relatively new<br /> usb_control_msg_recv() and usb_control_msg_send() routines. That&amp;#39;s<br /> what this fix does.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49938

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix small mempool leak in SMB2_negotiate()<br /> <br /> In some cases of failure (dialect mismatches) in SMB2_negotiate(), after<br /> the request is sent, the checks would return -EIO when they should be<br /> rather setting rc = -EIO and jumping to neg_exit to free the response<br /> buffer from mempool.
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49939

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix UAF of ref-&gt;proc caused by race condition<br /> <br /> A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the<br /> reference for a node. In this case, the target proc normally releases<br /> the failed reference upon close as expected. However, if the target is<br /> dying in parallel the call will race with binder_deferred_release(), so<br /> the target could have released all of its references by now leaving the<br /> cleanup of the new failed reference unhandled.<br /> <br /> The transaction then ends and the target proc gets released making the<br /> ref-&gt;proc now a dangling pointer. Later on, ref-&gt;node is closed and we<br /> attempt to take spin_lock(&amp;ref-&gt;proc-&gt;inner_lock), which leads to the<br /> use-after-free bug reported below. Let&amp;#39;s fix this by cleaning up the<br /> failed reference on the spot instead of relying on the target to do so.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150<br /> Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590<br /> <br /> CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: events binder_deferred_func<br /> Call trace:<br /> dump_backtrace.part.0+0x1d0/0x1e0<br /> show_stack+0x18/0x70<br /> dump_stack_lvl+0x68/0x84<br /> print_report+0x2e4/0x61c<br /> kasan_report+0xa4/0x110<br /> kasan_check_range+0xfc/0x1a4<br /> __kasan_check_write+0x3c/0x50<br /> _raw_spin_lock+0xa8/0x150<br /> binder_deferred_func+0x5e0/0x9b0<br /> process_one_work+0x38c/0x5f0<br /> worker_thread+0x9c/0x694<br /> kthread+0x188/0x190<br /> ret_from_fork+0x10/0x20
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49940

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: n_gsm: add sanity check for gsm-&gt;receive in gsm_receive_buf()<br /> <br /> A null pointer dereference can happen when attempting to access the<br /> "gsm-&gt;receive()" function in gsmld_receive_buf(). Currently, the code<br /> assumes that gsm-&gt;recieve is only called after MUX activation.<br /> Since the gsmld_receive_buf() function can be accessed without the need to<br /> initialize the MUX, the gsm-&gt;receive() function will not be set and a<br /> NULL pointer dereference will occur.<br /> <br /> Fix this by avoiding the call to "gsm-&gt;receive()" in case the function is<br /> not initialized by adding a sanity check.<br /> <br /> Call Trace:<br /> <br /> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861<br /> tiocsti drivers/tty/tty_io.c:2293 [inline]<br /> tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025

CVE-2022-49934

Publication date:
18/06/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: Fix UAF in ieee80211_scan_rx()<br /> <br /> ieee80211_scan_rx() tries to access scan_req-&gt;flags after a<br /> null check, but a UAF is observed when the scan is completed<br /> and __ieee80211_scan_completed() executes, which then calls<br /> cfg80211_scan_done() leading to the freeing of scan_req.<br /> <br /> Since scan_req is rcu_dereference()&amp;#39;d, prevent the racing in<br /> __ieee80211_scan_completed() by ensuring that from mac80211&amp;#39;s<br /> POV it is no longer accessed from an RCU read critical section<br /> before we call cfg80211_scan_done().
Severity CVSS v4.0: Pending analysis
Last modification:
18/06/2025