Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix shared sqpoll cancellation hangs<br /> <br /> [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds.<br /> [ 736.982897] Call Trace:<br /> [ 736.982901] schedule+0x68/0xe0<br /> [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110<br /> [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30<br /> [ 736.982911] io_run_task_work_head+0x28/0x50<br /> [ 736.982913] io_sq_thread+0x4e3/0x720<br /> <br /> We call io_uring_cancel_sqpoll() one by one for each ctx either in<br /> sq_thread() itself or via task works, and it&amp;#39;s intended to cancel all<br /> requests of a specified context. However the function uses per-task<br /> counters to track the number of inflight requests, so it counts more<br /> requests than available via currect io_uring ctx and goes to sleep for<br /> them to appear (e.g. from IRQ), that will never happen.<br /> <br /> Cancel a bit more than before, i.e. all ctxs that share sqpoll<br /> and continue to use shared counters. Don&amp;#39;t forget that we should not<br /> remove ctx from the list before running that task_work sqpoll-cancel,<br /> otherwise the function wouldn&amp;#39;t be able to find the context and will<br /> hang.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: staging/intel-ipu3: Fix set_fmt error handling<br /> <br /> If there in an error during a set_fmt, do not overwrite the previous<br /> sizes with the invalid config.<br /> <br /> Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and<br /> causing the following OOPs<br /> <br /> [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes)<br /> [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0<br /> [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: staging/intel-ipu3: Fix memory leak in imu_fmt<br /> <br /> We are losing the reference to an allocated memory if try. Change the<br /> order of the check to avoid that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: always panic when errors=panic is specified<br /> <br /> Before commit 014c9caa29d3 ("ext4: make ext4_abort() use<br /> __ext4_error()"), the following series of commands would trigger a<br /> panic:<br /> <br /> 1. mount /dev/sda -o ro,errors=panic test<br /> 2. mount /dev/sda -o remount,abort test<br /> <br /> After commit 014c9caa29d3, remounting a file system using the test<br /> mount option "abort" will no longer trigger a panic. This commit will<br /> restore the behaviour immediately before commit 014c9caa29d3.<br /> (However, note that the Linux kernel&amp;#39;s behavior has not been<br /> consistent; some previous kernel versions, including 5.4 and 4.19<br /> similarly did not panic after using the mount option "abort".)<br /> <br /> This also makes a change to long-standing behaviour; namely, the<br /> following series commands will now cause a panic, when previously it<br /> did not:<br /> <br /> 1. mount /dev/sda -o ro,errors=panic test<br /> 2. echo test &gt; /sys/fs/ext4/sda/trigger_fs_error<br /> <br /> However, this makes ext4&amp;#39;s behaviour much more consistent, so this is<br /> a good thing.

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