CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47198 – scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine
https://notcve.org/view.php?id=CVE-2021-47198
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine An error is detected with the following report when unloading the driver: "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b" The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the flag is not cleared upon completion of the login. This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set to LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used as an rpi_ids array index. Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in lpfc_mbx_cmpl_fc_reg_login(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Fix use-after-free en la rutina lpfc_unreg_rpi() Se detecta un error con el siguiente reporte al descargar el driver: "KASAN: use-after-free en lpfc_unreg_rpi +0x1b1b" El NLP_REG_LOGIN_SEND nlp_flag está configurado en lpfc_reg_fab_ctrl_node(), pero el indicador no se borra al finalizar el inicio de sesión. Esto permite una segunda llamada a lpfc_unreg_rpi() para continuar con nlp_rpi configurado en LPFC_RPI_ALLOW_ERROR. Esto da como resultado un acceso de use after free cuando se usa como índice de matriz rpi_ids. • https://git.kernel.org/stable/c/dbebf865b3239595c1d4dba063b122862583b52a https://git.kernel.org/stable/c/79b20beccea3a3938a8500acef4e6b9d7c66142f • CWE-416: Use After Free •
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: 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 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47185 – tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
https://notcve.org/view.php?id=CVE-2021-47185
In the Linux kernel, the following vulnerability has been resolved: tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it. • https://git.kernel.org/stable/c/0380f643f3a7a61b0845cdc738959c2ad5735d61 https://git.kernel.org/stable/c/b1ffc16ec05ae40d82b6e373322d62e9d6b54fbc https://git.kernel.org/stable/c/4c1623651a0936ee197859824cdae6ebbd04d3ed https://git.kernel.org/stable/c/4f300f47dbcf9c3d4b2ea76c8554c8f360400725 https://git.kernel.org/stable/c/d491c84df5c469dd9621863b6a770b3428137063 https://git.kernel.org/stable/c/77e9fed33056f2a88eba9dd4d2d5412f0c7d1f41 https://git.kernel.org/stable/c/5c34486f04700f1ba04907231dce0cc2705c2d7d https://git.kernel.org/stable/c/3968ddcf05fb4b9409cd1859feb06a5b0 • CWE-1050: Excessive Platform Resource Consumption within a Loop •