Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sma1307: Add NULL check in sma1307_setting_loaded()<br /> <br /> All varibale allocated by kzalloc and devm_kzalloc could be NULL.<br /> Multiple pointer checks and their cleanup are added.<br /> <br /> This issue is found by our static analysis tool

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops<br /> <br /> Fix a kernel oops found while testing the stm32_pcie Endpoint driver<br /> with handling of PERST# deassertion:<br /> <br /> During EP initialization, pci_epf_test_alloc_space() allocates all BARs,<br /> which are further freed if epc_set_bar() fails (for instance, due to no<br /> free inbound window).<br /> <br /> However, when pci_epc_set_bar() fails, the error path:<br /> <br /> pci_epc_set_bar() -&gt;<br /> pci_epf_free_space()<br /> <br /> does not clear the previous assignment to epf_test-&gt;reg[bar].<br /> <br /> Then, if the host reboots, the PERST# deassertion restarts the BAR<br /> allocation sequence with the same allocation failure (no free inbound<br /> window), creating a double free situation since epf_test-&gt;reg[bar] was<br /> deallocated and is still non-NULL.<br /> <br /> Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space()<br /> invocations are symmetric, and as such, set epf_test-&gt;reg[bar] to NULL<br /> when memory is freed.<br /> <br /> [kwilczynski: commit log]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: iscsi: Fix timeout on deleted connection<br /> <br /> NOPIN response timer may expire on a deleted connection and crash with<br /> such logs:<br /> <br /> Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> NIP strlcpy+0x8/0xb0<br /> LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]<br /> Call Trace:<br /> iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod]<br /> call_timer_fn+0x58/0x1f0<br /> run_timer_softirq+0x740/0x860<br /> __do_softirq+0x16c/0x420<br /> irq_exit+0x188/0x1c0<br /> timer_interrupt+0x184/0x410<br /> <br /> That is because nopin response timer may be re-started on nopin timer<br /> expiration.<br /> <br /> Stop nopin timer before stopping the nopin response timer to be sure<br /> that no one of them will be re-started.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Check return value from memblock_phys_alloc_range()<br /> <br /> At least with CONFIG_PHYSICAL_START=0x100000, if there is

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libnvdimm/labels: Fix divide error in nd_label_data_init()<br /> <br /> If a faulty CXL memory device returns a broken zero LSA size in its<br /> memory device information (Identify Memory Device (Opcode 4000h), CXL<br /> spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm<br /> driver:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]<br /> <br /> Code and flow:<br /> <br /> 1) CXL Command 4000h returns LSA size = 0<br /> 2) config_size is assigned to zero LSA size (CXL pmem driver):<br /> <br /> drivers/cxl/pmem.c: .config_size = mds-&gt;lsa_size,<br /> <br /> 3) max_xfer is set to zero (nvdimm driver):<br /> <br /> drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-&gt;nsarea.max_xfer, config_size);<br /> <br /> 4) A subsequent DIV_ROUND_UP() causes a division by zero:<br /> <br /> drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */<br /> drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,<br /> drivers/nvdimm/label.c- config_size);<br /> <br /> Fix this by checking the config size parameter by extending an<br /> existing check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex<br /> <br /> The vhost-scsi completion path may access vq-&gt;log_base when vq-&gt;log_used is<br /> already set to false.<br /> <br /> vhost-thread QEMU-thread<br /> <br /> vhost_scsi_complete_cmd_work()<br /> -&gt; vhost_add_used()<br /> -&gt; vhost_add_used_n()<br /> if (unlikely(vq-&gt;log_used))<br /> QEMU disables vq-&gt;log_used<br /> via VHOST_SET_VRING_ADDR.<br /> mutex_lock(&amp;vq-&gt;mutex);<br /> vq-&gt;log_used = false now!<br /> mutex_unlock(&amp;vq-&gt;mutex);<br /> <br /> QEMU gfree(vq-&gt;log_base)<br /> log_used()<br /> -&gt; log_write(vq-&gt;log_base)<br /> <br /> Assuming the VMM is QEMU. The vq-&gt;log_base is from QEMU userpace and can be<br /> reclaimed via gfree(). As a result, this causes invalid memory writes to<br /> QEMU userspace.<br /> <br /> The control queue path has the same issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio: break and reset virtio devices on device_shutdown()<br /> <br /> Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory<br /> accesses during the hang.<br /> <br /> Invalid read at addr 0x102877002, size 2, region &amp;#39;(null)&amp;#39;, reason: rejected<br /> Invalid write at addr 0x102877A44, size 2, region &amp;#39;(null)&amp;#39;, reason: rejected<br /> ...<br /> <br /> It was traced down to virtio-console. Kexec works fine if virtio-console<br /> is not in use.<br /> <br /> The issue is that virtio-console continues to write to the MMIO even after<br /> underlying virtio-pci device is reset.<br /> <br /> Additionally, Eric noticed that IOMMUs are reset before devices, if<br /> devices are not reset on shutdown they continue to poke at guest memory<br /> and get errors from the IOMMU. Some devices get wedged then.<br /> <br /> The problem can be solved by breaking all virtio devices on virtio<br /> bus shutdown, then resetting them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rseq: Fix segfault on registration when rseq_cs is non-zero<br /> <br /> The rseq_cs field is documented as being set to 0 by user-space prior to<br /> registration, however this is not currently enforced by the kernel. This<br /> can result in a segfault on return to user-space if the value stored in<br /> the rseq_cs field doesn&amp;#39;t point to a valid struct rseq_cs.<br /> <br /> The correct solution to this would be to fail the rseq registration when<br /> the rseq_cs field is non-zero. However, some older versions of glibc<br /> will reuse the rseq area of previous threads without clearing the<br /> rseq_cs field and will also terminate the process if the rseq<br /> registration fails in a secondary thread. This wasn&amp;#39;t caught in testing<br /> because in this case the leftover rseq_cs does point to a valid struct<br /> rseq_cs.<br /> <br /> What we can do is clear the rseq_cs field on registration when it&amp;#39;s<br /> non-zero which will prevent segfaults on registration and won&amp;#39;t break<br /> the glibc versions that reuse rseq areas on thread creation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: lzo - Fix compression buffer overrun<br /> <br /> Unlike the decompression code, the compression code in LZO never<br /> checked for output overruns. It instead assumes that the caller<br /> always provides enough buffer space, disregarding the buffer length<br /> provided by the caller.<br /> <br /> Add a safe compression interface that checks for the end of buffer<br /> before each write. Use the safe interface in crypto/lzo.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix unconditional IO throttle caused by REQ_PREFLUSH<br /> <br /> When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush()<br /> generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC,<br /> which causes the flush_bio to be throttled by wbt_wait().<br /> <br /> An example from v5.4, similar problem also exists in upstream:<br /> <br /> crash&gt; bt 2091206<br /> PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0"<br /> #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8<br /> #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4<br /> #2 [ffff800084a2f880] schedule at ffff800040bfa4b4<br /> #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4<br /> #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc<br /> #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0<br /> #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254<br /> #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38<br /> #8 [ffff800084a2fa60] generic_make_request at ffff800040570138<br /> #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4<br /> #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]<br /> #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]<br /> #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]<br /> #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]<br /> #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]<br /> #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]<br /> #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08<br /> #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc<br /> #18 [ffff800084a2fe70] kthread at ffff800040118de4<br /> <br /> After commit 2def2845cc33 ("xfs: don&amp;#39;t allow log IO to be throttled"),<br /> the metadata submitted by xlog_write_iclog() should not be throttled.<br /> But due to the existence of the dm layer, throttling flush_bio indirectly<br /> causes the metadata bio to be throttled.<br /> <br /> Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes<br /> wbt_should_throttle() return false to avoid wbt_wait().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: Do not truncate file size<br /> <br /> &amp;#39;len&amp;#39; is used to store the result of i_size_read(), so making &amp;#39;len&amp;#39;<br /> a size_t results in truncation to 4GiB on 32-bit systems.