Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: physmap: physmap-bt1-rom: Fix unintentional stack access<br /> <br /> Cast &amp;data to (char *) in order to avoid unintentionally accessing<br /> the stack.<br /> <br /> Notice that data is of type u32, so any increment to &amp;data<br /> will be in the order of 4-byte chunks, and this piece of code<br /> is actually intended to be a byte offset.<br /> <br /> Addresses-Coverity-ID: 1497765 ("Out-of-bounds access")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: custom_method: fix potential use-after-free issue<br /> <br /> In cm_write(), buf is always freed when reaching the end of the<br /> function. If the requested count is less than table.length, the<br /> allocated buffer will be freed but subsequent calls to cm_write() will<br /> still try to access it.<br /> <br /> Remove the unconditional kfree(buf) at the end of the function and<br /> set the buf to NULL in the -EINVAL error path to match the rest of<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost-vdpa: fix vm_flags for virtqueue doorbell mapping<br /> <br /> The virtqueue doorbell is usually implemented via registeres but we<br /> don&amp;#39;t provide the necessary vma-&gt;flags like VM_PFNMAP. This may cause<br /> several issues e.g when userspace tries to map the doorbell via vhost<br /> IOTLB, kernel may panic due to the page is not backed by page<br /> structure. This patch fixes this by setting the necessary<br /> vm_flags. With this patch, try to map doorbell via IOTLB will fail<br /> with bad address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: fix zcard and zqueue hot-unplug memleak<br /> <br /> Tests with kvm and a kmemdebug kernel showed, that on hot unplug the<br /> zcard and zqueue structs for the unplugged card or queue are not<br /> properly freed because of a mismatch with get/put for the embedded<br /> kref counter.<br /> <br /> This fix now adjusts the handling of the kref counters. With init the<br /> kref counter starts with 1. This initial value needs to drop to zero<br /> with the unregister of the card or queue to trigger the release and<br /> free the object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: core: Fix invalid error returning in mhi_queue<br /> <br /> mhi_queue returns an error when the doorbell is not accessible in<br /> the current state. This can happen when the device is in non M0<br /> state, like M3, and needs to be waken-up prior ringing the DB. This<br /> case is managed earlier by triggering an asynchronous M3 exit via<br /> controller resume/suspend callbacks, that in turn will cause M0<br /> transition and DB update.<br /> <br /> So, since it&amp;#39;s not an error but just delaying of doorbell update, there<br /> is no reason to return an error.<br /> <br /> This also fixes a use after free error for skb case, indeed a caller<br /> queuing skb will try to free the skb if the queueing fails, but in<br /> that case queueing has been done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue<br /> <br /> A recent change created a dedicated workqueue for the state-change work<br /> with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags,<br /> but the state-change work (mhi_pm_st_worker) does not guarantee forward<br /> progress under memory pressure, and will even wait on various memory<br /> allocations when e.g. creating devices, loading firmware, etc... The<br /> work is then not part of a memory reclaim path...<br /> <br /> Moreover, this causes a warning in check_flush_dependency() since we end<br /> up in code that flushes a non-reclaim workqueue:<br /> <br /> [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog<br /> [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140<br /> [ 40.969733] Call Trace:<br /> [ 40.969740] __flush_work+0x97/0x1d0<br /> [ 40.969745] ? wake_up_process+0x15/0x20<br /> [ 40.969749] ? insert_work+0x70/0x80<br /> [ 40.969750] ? __queue_work+0x14a/0x3e0<br /> [ 40.969753] flush_work+0x10/0x20<br /> [ 40.969756] rollback_registered_many+0x1c9/0x510<br /> [ 40.969759] unregister_netdevice_queue+0x94/0x120<br /> [ 40.969761] unregister_netdev+0x1d/0x30<br /> [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net]<br /> [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi]<br /> [ 40.969776] device_release_driver_internal+0xf0/0x1d0<br /> [ 40.969778] device_release_driver+0x12/0x20<br /> [ 40.969782] bus_remove_device+0xe1/0x150<br /> [ 40.969786] device_del+0x17b/0x3e0<br /> [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi]<br /> [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi]<br /> [ 40.969799] device_for_each_child+0x5e/0xa0<br /> [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix unconditional security_locked_down() call<br /> <br /> Currently, the lockdown state is queried unconditionally, even though<br /> its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in<br /> attr.sample_type. While that doesn&amp;#39;t matter in case of the Lockdown LSM,<br /> it causes trouble with the SELinux&amp;#39;s lockdown hook implementation.<br /> <br /> SELinux implements the locked_down hook with a check whether the current<br /> task&amp;#39;s type has the corresponding "lockdown" class permission<br /> ("integrity" or "confidentiality") allowed in the policy. This means<br /> that calling the hook when the access control decision would be ignored<br /> generates a bogus permission check and audit record.<br /> <br /> Fix this by checking sample_type first and only calling the hook when<br /> its result would be honored.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix leaked dentry<br /> <br /> Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in<br /> ovl_lookup()"), overlayfs doesn&amp;#39;t put temporary dentry when there is a<br /> metacopy error, which leads to dentry leaks when shutting down the related<br /> superblock:<br /> <br /> overlayfs: refusing to follow metacopy origin for (/file0)<br /> ...<br /> BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay]<br /> ...<br /> WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d<br /> CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1<br /> ...<br /> RIP: 0010:umount_check.cold+0x107/0x14d<br /> ...<br /> Call Trace:<br /> d_walk+0x28c/0x950<br /> ? dentry_lru_isolate+0x2b0/0x2b0<br /> ? __kasan_slab_free+0x12/0x20<br /> do_one_tree+0x33/0x60<br /> shrink_dcache_for_umount+0x78/0x1d0<br /> generic_shutdown_super+0x70/0x440<br /> kill_anon_super+0x3e/0x70<br /> deactivate_locked_super+0xc4/0x160<br /> deactivate_super+0xfa/0x140<br /> cleanup_mnt+0x22e/0x370<br /> __cleanup_mnt+0x1a/0x30<br /> task_work_run+0x139/0x210<br /> do_exit+0xb0c/0x2820<br /> ? __kasan_check_read+0x1d/0x30<br /> ? find_held_lock+0x35/0x160<br /> ? lock_release+0x1b6/0x660<br /> ? mm_update_next_owner+0xa20/0xa20<br /> ? reacquire_held_locks+0x3f0/0x3f0<br /> ? __sanitizer_cov_trace_const_cmp4+0x22/0x30<br /> do_group_exit+0x135/0x380<br /> __do_sys_exit_group.isra.0+0x20/0x20<br /> __x64_sys_exit_group+0x3c/0x50<br /> do_syscall_64+0x45/0x70<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> ...<br /> VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day...<br /> <br /> This fix has been tested with a syzkaller reproducer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Avoid potential use after free in MHI send<br /> <br /> It is possible that the MHI ul_callback will be invoked immediately<br /> following the queueing of the skb for transmission, leading to the<br /> callback decrementing the refcount of the associated sk and freeing the<br /> skb.<br /> <br /> As such the dereference of skb and the increment of the sk refcount must<br /> happen before the skb is queued, to avoid the skb to be used after free<br /> and potentially the sk to drop its last refcount..

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix masking negation logic upon negative dst register<br /> <br /> The negation logic for the case where the off_reg is sitting in the<br /> dst register is not correct given then we cannot just invert the add<br /> to a sub or vice versa. As a fix, perform the final bitwise and-op<br /> unconditionally into AX from the off_reg, then move the pointer from<br /> the src to dst and finally use AX as the source for the original<br /> pointer arithmetic operation such that the inversion yields a correct<br /> result. The single non-AX mov in between is possible given constant<br /> blinding is retaining it as it&amp;#39;s not an immediate based operation.

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

The uAMQP is a C library for AMQP 1.0 communication to Azure Cloud Services. When processing an incorrect `AMQP_VALUE` failed state, may cause a double free problem. This may cause a RCE. Update submodule with commit 2ca42b6e4e098af2d17e487814a91d05f6ae4987.