Vulnerabilities

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 /> scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand()<br /> <br /> RIP: 0010:kmem_cache_free+0xfa/0x1b0<br /> Call Trace:<br /> qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx]<br /> scsi_queue_rq+0x5e2/0xa40<br /> __blk_mq_try_issue_directly+0x128/0x1d0<br /> blk_mq_request_issue_directly+0x4e/0xb0<br /> <br /> Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now<br /> allocated by upper layers. This fixes smatch warning of srb unintended<br /> free.

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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: adjust efx-&gt;xdp_tx_queue_count with the real number of initialized queues<br /> <br /> efx-&gt;xdp_tx_queue_count is initially initialized to num_possible_cpus() and is<br /> later used to allocate and traverse efx-&gt;xdp_tx_queues lookup array. However,<br /> we may end up not initializing all the array slots with real queues during<br /> probing. This results, for example, in a NULL pointer dereference, when running<br /> "# ethtool -S ", similar to below<br /> <br /> [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [2570283.681283][T4126959] #PF: supervisor read access in kernel mode<br /> [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page<br /> [2570283.710013][T4126959] PGD 0 P4D 0<br /> [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI<br /> [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1<br /> [2570283.752641][T4126959] Hardware name: <br /> [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc]<br /> [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b<br /> [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202<br /> [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018<br /> [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005<br /> [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f<br /> [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8<br /> [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c<br /> [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000<br /> [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0<br /> [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [2570283.997308][T4126959] PKRU: 55555554<br /> [2570284.007649][T4126959] Call Trace:<br /> [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830<br /> <br /> Fix this by adjusting efx-&gt;xdp_tx_queue_count after probing to reflect the true<br /> value of initialized slots in efx-&gt;xdp_tx_queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: farch: fix TX queue lookup in TX event handling<br /> <br /> We&amp;#39;re starting from a TXQ label, not a TXQ type, so<br /> efx_channel_get_tx_queue() is inappropriate (and could return NULL,<br /> leading to panics).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: farch: fix TX queue lookup in TX flush done handling<br /> <br /> We&amp;#39;re starting from a TXQ instance number (&amp;#39;qid&amp;#39;), not a TXQ type, so<br /> efx_get_tx_queue() is inappropriate (and could return NULL, leading<br /> to panics).