Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: Fix use-after-free with devm_spi_alloc_*<br /> <br /> We can&amp;#39;t rely on the contents of the devres list during<br /> spi_unregister_controller(), as the list is already torn down at the<br /> time we perform devres_find() for devm_spi_release_controller. This<br /> causes devices registered with devm_spi_alloc_{master,slave}() to be<br /> mistakenly identified as legacy, non-devm managed devices and have their<br /> reference counters decremented below 0.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174<br /> [] (refcount_warn_saturate) from [] (kobject_put+0x90/0x98)<br /> [] (kobject_put) from [] (put_device+0x20/0x24)<br /> r4:b6700140<br /> [] (put_device) from [] (devm_spi_release_controller+0x3c/0x40)<br /> [] (devm_spi_release_controller) from [] (release_nodes+0x84/0xc4)<br /> r5:b6700180 r4:b6700100<br /> [] (release_nodes) from [] (devres_release_all+0x5c/0x60)<br /> r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10<br /> [] (devres_release_all) from [] (__device_release_driver+0x144/0x1ec)<br /> r5:b117ad94 r4:b163dc10<br /> [] (__device_release_driver) from [] (device_driver_detach+0x84/0xa0)<br /> r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10<br /> [] (device_driver_detach) from [] (unbind_store+0xe4/0xf8)<br /> <br /> Instead, determine the devm allocation state as a flag on the<br /> controller which is guaranteed to be stable during cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: mvme147,mvme16x: Don&amp;#39;t wipe PCC timer config bits<br /> <br /> Don&amp;#39;t clear the timer 1 configuration bits when clearing the interrupt flag<br /> and counter overflow. As Michael reported, "This results in no timer<br /> interrupts being delivered after the first. Initialization then hangs<br /> in calibrate_delay as the jiffies counter is not updated."<br /> <br /> On mvme16x, enable the timer after requesting the irq, consistent with<br /> mvme147.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: stream: fix memory leak in stream config error path<br /> <br /> When stream config is failed, master runtime will release all<br /> slave runtime in the slave_rt_list, but slave runtime is not<br /> added to the list at this time. This patch frees slave runtime<br /> in the config error path to fix the memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: qcom: Put child node before return<br /> <br /> Put child node before return to fix potential reference count leak.<br /> Generally, the reference count of child is incremented and decremented<br /> automatically in the macro for_each_available_child_of_node() and should<br /> be decremented manually if the loop is broken in loop body.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: require write permissions for locking and badblock ioctls<br /> <br /> MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require<br /> write permission. Depending on the hardware MEMLOCK might even be<br /> write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK<br /> is always write-once.<br /> <br /> MEMSETBADBLOCK modifies the bad block table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init<br /> <br /> ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()<br /> before calling adf_iov_putmsg()-&gt;mutex_lock(vf2pf_lock), however the<br /> vf2pf_lock is initialized in adf_dev_init(), which can fail and when it<br /> fail, the vf2pf_lock is either not initialized or destroyed, a subsequent<br /> use of vf2pf_lock will cause issue.<br /> To fix this issue, only set this flag if adf_dev_init() returns 0.<br /> <br /> [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0<br /> [ 7.180345] Call Trace:<br /> [ 7.182576] mutex_lock+0xc9/0xd0<br /> [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat]<br /> [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat]<br /> [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat]<br /> [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ss - Fix memory leak of object d when dma_iv fails to map<br /> <br /> In the case where the dma_iv mapping fails, the return error path leaks<br /> the memory allocated to object d. Fix this by adding a new error return<br /> label and jumping to this to ensure d is free&amp;#39;d before the return.<br /> <br /> Addresses-Coverity: ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap: set debugfs_name to NULL after it is freed<br /> <br /> There is a upstream commit cffa4b2122f5("regmap:debugfs:<br /> Fix a memory leak when calling regmap_attach_dev") that<br /> adds a if condition when create name for debugfs_name.<br /> With below function invoking logical, debugfs_name is<br /> freed in regmap_debugfs_exit(), but it is not created again<br /> because of the if condition introduced by above commit.<br /> regmap_reinit_cache()<br /> regmap_debugfs_exit()<br /> ...<br /> regmap_debugfs_init()<br /> So, set debugfs_name to NULL after it is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ss - fix result memory leak on error path<br /> <br /> This patch fixes a memory leak on an error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Stop looking for coalesced MMIO zones if the bus is destroyed<br /> <br /> Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev()<br /> fails to allocate memory for the new instance of the bus. If it can&amp;#39;t<br /> instantiate a new bus, unregister_dev() destroys all devices _except_ the<br /> target device. But, it doesn&amp;#39;t tell the caller that it obliterated the<br /> bus and invoked the destructor for all devices that were on the bus. In<br /> the coalesced MMIO case, this can result in a deleted list entry<br /> dereference due to attempting to continue iterating on coalesced_zones<br /> after future entries (in the walk) have been deleted.<br /> <br /> Opportunistically add curly braces to the for-loop, which encompasses<br /> many lines but sneaks by without braces due to the guts being a single<br /> if statement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Destroy I/O bus devices on unregister failure _after_ sync&amp;#39;ing SRCU<br /> <br /> If allocating a new instance of an I/O bus fails when unregistering a<br /> device, wait to destroy the device until after all readers are guaranteed<br /> to see the new null bus. Destroying devices before the bus is nullified<br /> could lead to use-after-free since readers expect the devices on their<br /> reference of the bus to remain valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Use online_vcpus, not created_vcpus, to iterate over vCPUs<br /> <br /> Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting<br /> VMSAs for SEV, which effectively switches to use online_vcpus instead of<br /> created_vcpus. This fixes a possible null-pointer dereference as<br /> created_vcpus does not guarantee a vCPU exists, since it is updated at<br /> the very beginning of KVM_CREATE_VCPU. created_vcpus exists to allow the<br /> bulk of vCPU creation to run in parallel, while still correctly<br /> restricting the max number of max vCPUs.