Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid1: properly indicate failure when ending a failed write request<br /> <br /> This patch addresses a data corruption bug in raid1 arrays using bitmaps.<br /> Without this fix, the bitmap bits for the failed I/O end up being cleared.<br /> <br /> Since we are in the failure leg of raid1_end_write_request, the request<br /> either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: efi: Use local variable for calculating final log size<br /> <br /> When tpm_read_log_efi is called multiple times, which happens when<br /> one loads and unloads a TPM2 driver multiple times, then the global<br /> variable efi_tpm_final_log_size will at some point become a negative<br /> number due to the subtraction of final_events_preboot_size occurring<br /> each time. Use a local variable to avoid this integer underflow.<br /> <br /> The following issue is now resolved:<br /> <br /> Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy]<br /> Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20<br /> Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4<br /> Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206<br /> Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f<br /> Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d<br /> Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073<br /> Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5<br /> Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018<br /> Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000<br /> Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0<br /> Mar 8 15:35:12 hibinst kernel: Call Trace:<br /> Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7<br /> Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0<br /> Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260<br /> Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy]<br /> Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370<br /> Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0<br /> Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds<br /> <br /> Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused<br /> by a garbage timeout (retrans) mount option being passed to nfs mount,<br /> in this case from syzkaller.<br /> <br /> If the protocol is XPRT_TRANSPORT_UDP, then &amp;#39;retrans&amp;#39; is a shift<br /> value for a 64-bit long integer, so &amp;#39;retrans&amp;#39; cannot be &gt;= 64.<br /> If it is &gt;= 64, fail the mount and return an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: GTDT: Don&amp;#39;t corrupt interrupt mappings on watchdow probe failure<br /> <br /> When failing the driver probe because of invalid firmware properties,<br /> the GTDT driver unmaps the interrupt that it mapped earlier.<br /> <br /> However, it never checks whether the mapping of the interrupt actially<br /> succeeded. Even more, should the firmware report an illegal interrupt<br /> number that overlaps with the GIC SGI range, this can result in an<br /> IPI being unmapped, and subsequent fireworks (as reported by Dann<br /> Frazier).<br /> <br /> Rework the driver to have a slightly saner behaviour and actually<br /> check whether the interrupt has been mapped before unmapping things.