CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47194 – cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
https://notcve.org/view.php?id=CVE-2021-47194
In the Linux kernel, the following vulnerability has been resolved: cfg80211: call cfg80211_stop_ap when switch from P2P_GO type If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cfg80211: llame a cfg80211_stop_ap cuando cambie del tipo P2P_GO. Si las herramientas del espacio de usuario cambian de NL80211_IFTYPE_P2P_GO a NL80211_IFTYPE_ADHOC mediante send_msg(NL80211_CMD_SET_INTERFACE), no llama a la limpieza cfg80211_ stop_ap(), esto lleva a la inicialización de datos en uso. Por ejemplo, esta ruta reinicia sdata->assigned_chanctx_list mientras todavía es un elemento de la lista asignada_vifs y corrompe esa lista vinculada. • https://git.kernel.org/stable/c/ac800140c20e7ae51117e71289065bedd4930fc2 https://git.kernel.org/stable/c/8f06bb8c216bcd172394f61e557727e691b4cb24 https://git.kernel.org/stable/c/0738cdb636c21ab552eaecf905efa4a6070e3ebc https://git.kernel.org/stable/c/4e458abbb4a523f1413bfe15c079cf4e24c15b21 https://git.kernel.org/stable/c/b8a045e2a9b234cfbc06cf36923886164358ddec https://git.kernel.org/stable/c/52affc201fc22a1ab9a59ef0ed641a9adfcb8d13 https://git.kernel.org/stable/c/7b97b5776daa0b39dbdadfea176f9cc0646d4a66 https://git.kernel.org/stable/c/5a9b671c8d74a3e1b999e7a0c7f366079 • CWE-665: Improper Initialization •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47193 – scsi: pm80xx: Fix memory leak during rmmod
https://notcve.org/view.php?id=CVE-2021-47193
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Fix memory leak during rmmod Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: pm80xx: se corrigió la pérdida de memoria durante rmmod, el controlador no pudo liberar toda la memoria asignada. Esto puede provocar una pérdida de memoria durante la eliminación del controlador. Se debe liberar correctamente la memoria cuando se retire el módulo. • https://git.kernel.org/stable/c/269a4311b15f68d24e816f43f123888f241ed13d https://git.kernel.org/stable/c/51e6ed83bb4ade7c360551fa4ae55c4eacea354b • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47191 – scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()
https://notcve.org/view.php?id=CVE-2021-47191
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix out-of-bound read in resp_readcap16() The following warning was observed running syzkaller: [ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in; [ 3813.830724] program syz-executor not setting count and/or reply_len properly [ 3813.836956] ================================================================== [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0 [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549 [ 3813.846612] Call Trace: [ 3813.846995] dump_stack+0x108/0x15f [ 3813.847524] print_address_description+0xa5/0x372 [ 3813.848243] kasan_report.cold+0x236/0x2a8 [ 3813.849439] check_memory_region+0x240/0x270 [ 3813.850094] memcpy+0x30/0x80 [ 3813.850553] sg_copy_buffer+0x157/0x1e0 [ 3813.853032] sg_copy_from_buffer+0x13/0x20 [ 3813.853660] fill_from_dev_buffer+0x135/0x370 [ 3813.854329] resp_readcap16+0x1ac/0x280 [ 3813.856917] schedule_resp+0x41f/0x1630 [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0 [ 3813.862699] scsi_dispatch_cmd+0x330/0x950 [ 3813.863329] scsi_request_fn+0xd8e/0x1710 [ 3813.863946] __blk_run_queue+0x10b/0x230 [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400 [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420 [ 3813.871637] sg_write+0x6c8/0xef0 [ 3813.878853] __vfs_write+0xe4/0x800 [ 3813.883487] vfs_write+0x17b/0x530 [ 3813.884008] ksys_write+0x103/0x270 [ 3813.886268] __x64_sys_write+0x77/0xc0 [ 3813.886841] do_syscall_64+0x106/0x360 [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This issue can be reproduced with the following syzkaller log: r0 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x26e1, 0x0) r1 = syz_open_procfs(0xffffffffffffffff, &(0x7f0000000000)='fd/3\x00') open_by_handle_at(r1, &(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000) r2 = syz_open_dev$sg(&(0x7f0000000000), 0x0, 0x40782) write$binfmt_aout(r2, &(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126) In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This leads to OOB in sg_copy_buffer(). To solve this issue, define alloc_len as u32. • https://git.kernel.org/stable/c/3e20cb072679bdb47747ccc8bee3233a4cf0765a https://git.kernel.org/stable/c/5b8bed6464ad6653586e30df046185fd816ad999 https://git.kernel.org/stable/c/4e3ace0051e7e504b55d239daab8789dd89b863c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47188 – scsi: ufs: core: Improve SCSI abort handling
https://notcve.org/view.php?id=CVE-2021-47188
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Improve SCSI abort handling The following has been observed on a test setup: WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c Call trace: ufshcd_queuecommand+0x468/0x65c scsi_send_eh_cmnd+0x224/0x6a0 scsi_eh_test_devices+0x248/0x418 scsi_eh_ready_devs+0xc34/0xe58 scsi_error_handler+0x204/0x80c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 That warning is triggered by the following statement: WARN_ON(lrbp->cmd); Fix this warning by clearing lrbp->cmd from the abort handler. • https://git.kernel.org/stable/c/7a3e97b0dc4bbac2ba7803564ab0057722689921 https://git.kernel.org/stable/c/c36baca06efa833adaefba61f45fefdc49b6d070 https://git.kernel.org/stable/c/3ff1f6b6ba6f97f50862aa50e79959cc8ddc2566 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47187 – arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency
https://notcve.org/view.php?id=CVE-2021-47187
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency The entry/exit latency and minimum residency in state for the idle states of MSM8998 were ..bad: first of all, for all of them the timings were written for CPU sleep but the min-residency-us param was miscalculated (supposedly, while porting this from downstream); Then, the power collapse states are setting PC on both the CPU cluster *and* the L2 cache, which have different timings: in the specific case of L2 the times are higher so these ones should be taken into account instead of the CPU ones. This parameter misconfiguration was not giving particular issues because on MSM8998 there was no CPU scaling at all, so cluster/L2 power collapse was rarely (if ever) hit. When CPU scaling is enabled, though, the wrong timings will produce SoC unstability shown to the user as random, apparently error-less, sudden reboots and/or lockups. This set of parameters are stabilizing the SoC when CPU scaling is ON and when power collapse is frequently hit. • https://git.kernel.org/stable/c/a14d7038ea201c5526375becfc43b9ba281b1e82 https://git.kernel.org/stable/c/e52fecdd0c142b95c720683885b06ee3f0e065c8 https://git.kernel.org/stable/c/118c826ef8b43efe0fda8faf419673707ee8c5e5 https://git.kernel.org/stable/c/3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50 •