ISHACK AI BOT

Ubuntu: (CVE-2021-47012): linux vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix a use after free in siw_alloc_mr Our code analyzer reported a UAF. In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr). My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47012 CVE - 2021-47012 https://git.kernel.org/linus/3093ee182f01689b89e9f8797b321603e5de4f63 https://git.kernel.org/stable/c/3093ee182f01689b89e9f8797b321603e5de4f63 https://git.kernel.org/stable/c/30b9e92d0b5e5d5dc1101ab856c17009537cbca4 https://git.kernel.org/stable/c/3e22b88e02c194f6c80867abfef5cc09383461f4 https://git.kernel.org/stable/c/608a4b90ece039940e9425ee2b39c8beff27e00c https://git.kernel.org/stable/c/ad9ce7188432650469a6c7625bf479f5ed0b6155 https://www.cve.org/CVERecord?id=CVE-2021-47012 View more

Ubuntu: (CVE-2021-47010): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: Only allow init netns to set default tcp cong to a restricted algo tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47010 CVE - 2021-47010 https://git.kernel.org/linus/8d432592f30fcc34ef5a10aac4887b4897884493 https://git.kernel.org/stable/c/6c1ea8bee75df8fe2184a50fcd0f70bf82986f42 https://git.kernel.org/stable/c/8d432592f30fcc34ef5a10aac4887b4897884493 https://git.kernel.org/stable/c/9884f745108f7d25b189bbcd6754e284fb29ab68 https://git.kernel.org/stable/c/992de06308d9a9584d59b96d294ac676f924e437 https://git.kernel.org/stable/c/e7d7bedd507bb732e600403b7a96f9fe48d0ca31 https://git.kernel.org/stable/c/efe1532a6e1a8e3c343d04fff510f0ed80328f9c https://www.cve.org/CVERecord?id=CVE-2021-47010 View more

Ubuntu: (CVE-2021-47051): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47051 CVE - 2021-47051 https://git.kernel.org/linus/a03675497970a93fcf25d81d9d92a59c2d7377a7 https://git.kernel.org/stable/c/4a01ad002d2e03c399af536562693752af7c81b1 https://git.kernel.org/stable/c/6a2b5cee0d31ab6cc51030c441135b0e31217282 https://git.kernel.org/stable/c/a03675497970a93fcf25d81d9d92a59c2d7377a7 https://git.kernel.org/stable/c/b8207bfc539cd07d15e753ff2d179c5b61c673b1 https://git.kernel.org/stable/c/ce02e58ddf8658a4c3bed2296f32a5873b3f7cce https://www.cve.org/CVERecord?id=CVE-2021-47051 View more

Ubuntu: (CVE-2021-47006): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook The commit 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/ Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47006 CVE - 2021-47006 https://git.kernel.org/linus/a506bd5756290821a4314f502b4bafc2afcf5260 https://git.kernel.org/stable/c/3ed8832aeaa9a37b0fc386bb72ff604352567c80 https://git.kernel.org/stable/c/555a70f7fff03bd669123487905c47ae27dbdaac https://git.kernel.org/stable/c/630146203108bf6b8934eec0dfdb3e46dcb917de https://git.kernel.org/stable/c/7eeacc6728c5478e3c01bc82a1f08958eaa12366 https://git.kernel.org/stable/c/a506bd5756290821a4314f502b4bafc2afcf5260 https://git.kernel.org/stable/c/a9938d6d78a238d6ab8de57a4d3dcf77adceb9bb https://git.kernel.org/stable/c/dabe299425b1a53a69461fed7ac8922ea6733a25 https://git.kernel.org/stable/c/ed1f67465327cec4457bb988775245b199da86e6 https://www.cve.org/CVERecord?id=CVE-2021-47006 View more

Amazon Linux AMI 2: CVE-2021-46981: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 06/11/2024 Added 06/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [656.368943] #PF: supervisor write access in kernel mode [656.369844] #PF: error_code(0x0002) - not-present page [656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [656.371693] Oops: 0002 [#1] SMP [656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [656.375904] RIP: 0010:mutex_lock+0x29/0x60 [656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [656.382166] FS:00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [656.382806] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [656.384927] Call Trace: [656.385111]flush_workqueue+0x92/0x6c0 [656.385395]nbd_disconnect_and_put+0x81/0xd0 [656.385716]nbd_genl_disconnect+0x125/0x2a0 [656.386034]genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [656.386422]genl_rcv_msg+0xfc/0x2b0 [656.386685]? nbd_ioctl+0x490/0x490 [656.386954]? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [656.387354]netlink_rcv_skb+0x62/0x180 [656.387638]genl_rcv+0x34/0x60 [656.387874]netlink_unicast+0x26d/0x590 [656.388162]netlink_sendmsg+0x398/0x6c0 [656.388451]? netlink_rcv_skb+0x180/0x180 [656.388750]____sys_sendmsg+0x1da/0x320 [656.389038]? ____sys_recvmsg+0x130/0x220 [656.389334]___sys_sendmsg+0x8e/0xf0 [656.389605]? ___sys_recvmsg+0xa2/0xf0 [656.389889]? handle_mm_fault+0x1671/0x21d0 [656.390201]__sys_sendmsg+0x6d/0xe0 [656.390464]__x64_sys_sendmsg+0x23/0x30 [656.390751]do_syscall_64+0x45/0x70 [656.391017]entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put(). Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-46981 AL2/ALASKERNEL-5.10-2022-002 AL2/ALASKERNEL-5.4-2022-004 CVE - 2021-46981

Amazon Linux AMI 2: CVE-2021-46993: Security patch for kernel (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:C) Published 02/28/2024 Created 04/26/2024 Added 04/26/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: sched: Fix out-of-bound access in uclamp Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue. Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-46993 AL2/ALASKERNEL-5.10-2022-002 AL2/ALASKERNEL-5.4-2022-004 CVE - 2021-46993

Huawei EulerOS: CVE-2021-47015: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 05/10/2024 Added 05/13/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring.The RX consumer index that we pass to bnxt_discard_rx() is not correct.We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons).This bug can cause us to be at the wrong index when trying to abort the next RX packet.It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cddRSP: ffff9bbcdf5c3d98RFLAGS: 00010213 RAX: 000000005dd8097fRBX: ffff9ba4cb11b7e0RCX: ffffa923cf6e9000 RDX: 0000000000000fffRSI: 0000000000000627RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138R11: ffff9bbcdf5c3e83R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080R14: ffff9ba4cb11b7f0R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffffCS: 0010SS: 0018 Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47015 CVE - 2021-47015 EulerOS-SA-2024-1592

Huawei EulerOS: CVE-2021-47036: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: udp: skip L4 aggregation for UDP tunnel packets If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47036 CVE - 2021-47036 EulerOS-SA-2024-1873

Rocky Linux: CVE-2021-47018: kernel (RLSA-2024-5101) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 08/23/2024 Added 08/22/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. Solution(s) rocky-upgrade-bpftool rocky-upgrade-bpftool-debuginfo rocky-upgrade-kernel rocky-upgrade-kernel-core rocky-upgrade-kernel-cross-headers rocky-upgrade-kernel-debug rocky-upgrade-kernel-debug-core rocky-upgrade-kernel-debug-debuginfo rocky-upgrade-kernel-debug-devel rocky-upgrade-kernel-debug-modules rocky-upgrade-kernel-debug-modules-extra rocky-upgrade-kernel-debuginfo rocky-upgrade-kernel-debuginfo-common-x86_64 rocky-upgrade-kernel-devel rocky-upgrade-kernel-headers rocky-upgrade-kernel-modules rocky-upgrade-kernel-modules-extra rocky-upgrade-kernel-tools rocky-upgrade-kernel-tools-debuginfo rocky-upgrade-kernel-tools-libs rocky-upgrade-kernel-tools-libs-devel rocky-upgrade-perf rocky-upgrade-perf-debuginfo rocky-upgrade-python3-perf rocky-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2021-47018 CVE - 2021-47018 https://errata.rockylinux.org/RLSA-2024:5101

Debian: CVE-2021-46997: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: GW 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: |lockdep_hardirqs_off+0xd4/0xe8 |enter_from_kernel_mode.isra.5+0x7c/0xa8 |el1_abort+0x24/0x100 |el1_sync_handler+0x80/0xd0 |el1_sync+0x6c/0x100 |__arch_clear_user+0xc/0x90 |load_elf_binary+0x9fc/0x1450 |bprm_execve+0x404/0x880 |kernel_execve+0x180/0x188 |call_usermodehelper_exec_async+0xdc/0x158 |ret_from_fork+0x10/0x18 Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46997 CVE - 2021-46997

Debian: CVE-2021-46987: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock when cloning inline extents and using qgroups There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode. When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when cloning inline extent and low on free metadata space"). However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction. When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack:0 pid:225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273]__schedule+0x296/0x760 [72747.556277]schedule+0x3c/0xa0 [72747.556279]io_schedule+0x12/0x40 [72747.556284]__lock_page+0x13c/0x280 [72747.556287]? generic_file_readonly_mmap+0x70/0x70 [72747.556325]extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331]? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358]? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362]? update_group_capacity+0x25/0x210 [72747.556366]? cpumask_next_and+0x1a/0x20 [72747.556391]extent_writepages+0x44/0xa0 [btrfs] [72747.556394]do_writepages+0x41/0xd0 [72747.556398]__writeback_single_inode+0x39/0x2a0 [72747.556403]writeback_sb_inodes+0x1ea/0x440 [72747.556407]__writeback_inodes_wb+0x5f/0xc0 [72747.556410]wb_writeback+0x235/0x2b0 [72747.556414]? get_nr_inodes+0x35/0x50 [72747.556417]wb_workfn+0x354/0x490 [72747.556420]? newidle_balance+0x2c5/0x3e0 [72747.556424]process_one_work+0x1aa/0x340 [72747.556426]worker_thread+0x30/0x390 [72747.556429]? create_worker+0x1a0/0x1a0 [72747.556432]kthread+0x116/0x130 [72747.556435]? kthread_park+0x80/0x80 [72747.556438]ret_from_fork+0x1f/0x30 [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964]__schedule+0x296/0x760 [72747.566968]? finish_wait+0x80/0x80 [72747.566970]schedule+0x3c/0xa0 [72747.566995]wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999]? finish_wait+0x80/0x80 [72747.567024]lock_extent_bits+0x37/0x90 [btrfs] [72747.567047]btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051]? find_get_pages_range_tag+0x2cd/0x380 [72747.567076]__extent_writepage+0x203/0x320 [btrfs] [72747.567102]extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106]? update_load_avg+0x7e/0x5f0 [72747.567109]? enqueue_entity+0xf4/0x6f0 [72747.567134]extent_writepages+0x44/0xa0 [btrfs] [72747.567137]? enqueue_task_fair+0x93/0x6f0 [72747.567140]do_writepages+0x41/0xd0 [72747.567144]__filemap_fdatawrite_range+0xc7/0x100 [72747.567167]btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195]btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200]process_one_work+0x1aa/0x340 [72747.567202]worker_thread+0x30/0x390 [72747.567205]? create_worker+0x1a0/0x1a0 [72747.567208]kthread+0x116/0x130 [72747.567211]? kthread_park+0x80/0x80 [72747.567214]ret_from_fork+0x1f/0x30 [72747.569686] task:fsstressstate:D stack: ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46987 CVE - 2021-46987

Debian: CVE-2021-46988: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns - without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a "dangling" page when accounting fails, and if so, release it before returning. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46988 CVE - 2021-46988

Oracle Linux: CVE-2024-26461: ELSA-2024-3268:krb5 security update (LOW) (Multiple Advisories) Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 02/28/2024 Created 06/01/2024 Added 05/30/2024 Modified 01/07/2025 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c. A memory leak flaw was found in krb5 in /krb5/src/lib/gssapi/krb5/k5sealv3.c. This issue can lead to a denial of service through memory exhaustion. Solution(s) oracle-linux-upgrade-krb5-devel oracle-linux-upgrade-krb5-libs oracle-linux-upgrade-krb5-pkinit oracle-linux-upgrade-krb5-server oracle-linux-upgrade-krb5-server-ldap oracle-linux-upgrade-krb5-workstation oracle-linux-upgrade-libkadm5 References https://attackerkb.com/topics/cve-2024-26461 CVE - 2024-26461 ELSA-2024-3268 ELSA-2024-9331

Oracle Linux: CVE-2024-26458: ELSA-2024-3268:krb5 security update (LOW) (Multiple Advisories) Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 02/28/2024 Created 06/01/2024 Added 05/30/2024 Modified 01/07/2025 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. A memory leak flaw was found in krb5 in /krb5/src/lib/rpc/pmap_rmt.c. This issue can lead to a denial of service through memory exhaustion. Solution(s) oracle-linux-upgrade-krb5-devel oracle-linux-upgrade-krb5-libs oracle-linux-upgrade-krb5-pkinit oracle-linux-upgrade-krb5-server oracle-linux-upgrade-krb5-server-ldap oracle-linux-upgrade-krb5-workstation oracle-linux-upgrade-libkadm5 References https://attackerkb.com/topics/cve-2024-26458 CVE - 2024-26458 ELSA-2024-3268 ELSA-2024-9331

Debian: CVE-2021-47051: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47051 CVE - 2021-47051

Debian: CVE-2021-46999: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: sctp: do asoc update earlier in sctp_sf_do_dupcook_a There's a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] []sctp_assoc_control_transport+0x1b9/0x210 [sctp] []sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] []sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] []sctp_do_sm+0xc3/0x2a0 [sctp] []sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46999 CVE - 2021-46999

Huawei EulerOS: CVE-2021-47006: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 05/10/2024 Added 05/13/2024 Modified 05/13/2024 Description In the Linux kernel, the following vulnerability has been resolved: ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook The commit 1879445dfa7b ("perf/core: Set event's default ::overflow_handler()") set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/ Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47006 CVE - 2021-47006 EulerOS-SA-2024-1592

Huawei EulerOS: CVE-2021-47049: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 05/10/2024 Added 05/13/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list.This will result in a use after free.First remove it from the list, and then free it. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47049 CVE - 2021-47049 EulerOS-SA-2024-1592

Huawei EulerOS: CVE-2021-47037: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 06/26/2024 Added 06/26/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ASoC: q6afe-clocks: fix reprobing of the driver Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. Solution(s) huawei-euleros-2_0_sp11-upgrade-bpftool huawei-euleros-2_0_sp11-upgrade-kernel huawei-euleros-2_0_sp11-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp11-upgrade-kernel-tools huawei-euleros-2_0_sp11-upgrade-kernel-tools-libs huawei-euleros-2_0_sp11-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47037 CVE - 2021-47037 EulerOS-SA-2024-1837

Oracle Linux: CVE-2021-47013: ELSA-2024-3618:kernel update (MODERATE) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:H/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 06/07/2024 Added 06/06/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb-&gt;len by netdev_sent_queue(,skb-&gt;len). As i observed that emac_tx_fill_tpd() haven&apos;t modified the value of skb-&gt;len, thus my patch assigns skb-&gt;len to &apos;len&apos; before the possible free and use &apos;len&apos; instead of skb-&gt;len later. A use-after-free flaw was found in the Linux kernel’s Qualcomm Gigabit Ethernet Media Access Controller (EMAC) driver in how a user triggers an error path in the emac_tx_fill_tpd function. This flaw allows a local user to crash or potentially escalate their privileges on the system. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2021-47013 CVE - 2021-47013 ELSA-2024-3618

Debian: CVE-2020-36785: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs() The "s3a_buf" is freed along with all the other items on the "asd->s3a_stats" list.It leads to a double free and a use after free. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36785 CVE - 2020-36785

Debian: CVE-2021-47049: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list.This will result in a use after free.First remove it from the list, and then free it. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47049 CVE - 2021-47049

Debian: CVE-2021-46978: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46978 CVE - 2021-46978

SUSE: CVE-2021-47046: SUSE Linux Security Advisory Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow.I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries.This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code. Solution(s) suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-devel suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-source suse-upgrade-kernel-syms suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47046 CVE - 2021-47046

Debian: CVE-2021-46982: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix race condition of overwrite vs truncate pos_fsstress testcase complains a panic as belew: ------------[ cut here ]------------ kernel BUG at fs/f2fs/compress.c:1082! invalid opcode: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: writeback wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Call Trace: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x290 wb_workfn+0x309/0x500 process_one_work+0x220/0x3c0 worker_thread+0x53/0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 The root cause is truncate() may race with overwrite as below, so that one reference count left in page can not guarantee the page attaching in mapping tree all the time, after truncation, later find_lock_page() may return NULL pointer. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Fix this by avoiding referencing updated page. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46982 CVE - 2021-46982