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 •
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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47184 – i40e: Fix NULL ptr dereference on VSI filter sync
https://notcve.org/view.php?id=CVE-2021-47184
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL ptr dereference on VSI filter sync Remove the reason of null pointer dereference in sync VSI filters. Added new I40E_VSI_RELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops. • https://git.kernel.org/stable/c/41c445ff0f482bb6e6b72dcee9e598e20575f743 https://git.kernel.org/stable/c/78f2a9e831f9610e3655a0be5e675e1aa2472089 https://git.kernel.org/stable/c/87c421ab4a43433cb009fea44bbbc77f46913e1d https://git.kernel.org/stable/c/c30162da91327e4cdf7cd03079f096bb3654738c https://git.kernel.org/stable/c/f866513ead4370402428ef724b03c3312295c178 https://git.kernel.org/stable/c/e91e8427a1e1633a0261e3bb0201c836ac5b3890 https://git.kernel.org/stable/c/37d9e304acd903a445df8208b8a13d707902dea6 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47183 – scsi: lpfc: Fix link down processing to address NULL pointer dereference
https://notcve.org/view.php?id=CVE-2021-47183
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix link down processing to address NULL pointer dereference If an FC link down transition while PLOGIs are outstanding to fabric well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload requests may hang with repeated "2878" log messages. The Link down processing results in ABTS requests for outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The Abort request is stalled waiting for the link to come up. • https://git.kernel.org/stable/c/28de48a7cea495ab48082d9ff4ef63f7cb4e563a https://git.kernel.org/stable/c/1854f53ccd88ad4e7568ddfafafffe71f1ceb0a6 •