ISHACK AI BOT

Amazon Linux AMI 2: CVE-2021-47119: Security patch for kernel (ALASKERNEL-5.10-2022-002) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 03/15/2024 Created 08/03/2024 Added 08/02/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_fill_super Buffer head references must be released before calling kill_bdev(); otherwise the buffer head (and its page referenced by b_data) will not be freed by kill_bdev, and subsequently that bh will be leaked. If blocksizes differ, sb_set_blocksize() will kill current buffers and page cache by using kill_bdev(). And then super block will be reread again but using correct blocksize this time. sb_set_blocksize() didn't fully free superblock page and buffer head, and being busy, they were not freed and instead leaked. This can easily be reproduced by calling an infinite loop of: systemctl start <ext4_on_lvm>.mount, and systemctl stop <ext4_on_lvm>.mount ... since systemd creates a cgroup for each slice which it mounts, and the bh leak get amplified by a dying memory cgroup that also never gets freed, and memory consumption is much more easily noticed. 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-47119 AL2/ALASKERNEL-5.10-2022-002 CVE - 2021-47119

Microsoft Edge Chromium: CVE-2024-26163 Severity 4 CVSS (AV:N/AC:M/Au:N/C:N/I:P/A:N) Published 03/15/2024 Created 03/16/2024 Added 03/15/2024 Modified 01/28/2025 Description Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability Solution(s) microsoft-edge-upgrade-latest References https://attackerkb.com/topics/cve-2024-26163 CVE - 2024-26163 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26163

Ubuntu: (CVE-2021-47112): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Teardown PV features on boot CPU as well Various PV features (Async PF, PV EOI, steal time) work through memory shared with hypervisor and when we restore from hibernation we must properly teardown all these features to make sure hypervisor doesn't write to stale locations after we jump to the previously hibernated kernel (which can try to place anything there). For secondary CPUs the job is already done by kvm_cpu_down_prepare(), register syscore ops to do the same for boot CPU. 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-47112 CVE - 2021-47112 https://git.kernel.org/linus/8b79feffeca28c5459458fe78676b081e87c93a4 https://git.kernel.org/stable/c/38b858da1c58ad46519a257764e059e663b59ff2 https://git.kernel.org/stable/c/7620a669111b52f224d006dea9e1e688e2d62c54 https://git.kernel.org/stable/c/8b79feffeca28c5459458fe78676b081e87c93a4 https://git.kernel.org/stable/c/d1629b5b925de9b27979e929dae7fcb766daf6b6 https://www.cve.org/CVERecord?id=CVE-2021-47112 View more

Ubuntu: (Multiple Advisories) (CVE-2021-47118): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 11/21/2024 Added 11/19/2024 Modified 01/07/2025 Description In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid.Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid().As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early.As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g.when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`. Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff ---truncated--- Solution(s) ubuntu-upgrade-linux-image-4-4-0-1139-aws ubuntu-upgrade-linux-image-4-4-0-1140-kvm ubuntu-upgrade-linux-image-4-4-0-1177-aws ubuntu-upgrade-linux-image-4-4-0-262-generic ubuntu-upgrade-linux-image-4-4-0-262-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-lts-xenial ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-lts-xenial ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-lts-xenial References https://attackerkb.com/topics/cve-2021-47118 CVE - 2021-47118 USN-7183-1 USN-7184-1 https://git.kernel.org/linus/0711f0d7050b9e07c44bc159bbc64ac0a1022c7f https://git.kernel.org/stable/c/0711f0d7050b9e07c44bc159bbc64ac0a1022c7f https://git.kernel.org/stable/c/2cd6eedfa6344f5ef5c3dac3aee57a39b5b46dff https://git.kernel.org/stable/c/4dbd8808a591b49b717862e6e0081bcf14a87788 https://git.kernel.org/stable/c/7178be006d495ffb741c329012da289b62dddfe6 https://git.kernel.org/stable/c/764c2e892d1fe895392aff62fb353fdce43bb529 https://git.kernel.org/stable/c/b8ff869f20152fbe66b6c2e2715d26a2f9897cca https://git.kernel.org/stable/c/d106f05432e60f9f62d456ef017687f5c73cb414 https://git.kernel.org/stable/c/f86c80515a8a3703e0ca2e56deb50fc2879c5ea4 https://www.cve.org/CVERecord?id=CVE-2021-47118 View more

Ubuntu: (CVE-2021-47114): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption by fallocate When fallocate punches holes out of inode size, if original isize is in the middle of last cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time isize is not yet updated to match the new size, if writeback is kicked in, it will invoke ocfs2_writepage()->block_write_full_page() where the pages out of inode size will be dropped.That will cause file corruption.Fix this by zero out eof blocks when extending the inode size. Running the following command with qemu-image 4.2.1 can get a corrupted coverted image file easily. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv The usage of fallocate in qemu is like this, it first punches holes out of inode size, then extend the inode size. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0 v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-fsdevel/[email protected]/T/ 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-47114 CVE - 2021-47114 https://git.kernel.org/linus/6bba4471f0cc1296fe3c2089b9e52442d3074b2e https://git.kernel.org/stable/c/0a31dd6fd2f4e7db538fb6eb1f06973d81f8dd3b https://git.kernel.org/stable/c/33e03adafb29eedae1bae9cdb50c1385279fcf65 https://git.kernel.org/stable/c/624fa7baa3788dc9e57840ba5b94bc22b03cda57 https://git.kernel.org/stable/c/6bba4471f0cc1296fe3c2089b9e52442d3074b2e https://git.kernel.org/stable/c/a1700479524bb9cb5e8ae720236a6fabd003acae https://git.kernel.org/stable/c/c8d5faee46242c3f33b8a71a4d7d52214785bfcc https://git.kernel.org/stable/c/cc2edb99ea606a45182b5ea38cc8f4e583aa0774 https://git.kernel.org/stable/c/cec4e857ffaa8c447f51cd8ab4e72350077b6770 https://www.cve.org/CVERecord?id=CVE-2021-47114 View more

Oracle Linux: CVE-2021-47118: ELSA-2024-12606: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:M/C:N/I:N/A:C) Published 03/15/2024 Created 06/07/2024 Added 06/06/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task&apos;s struct pid.Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid().As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task&apos;s struct pid early.As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g.when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 (&quot;[PATCH] replace cad_pid by a struct pid&quot;) from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task&apos;s struct pid when we assign it to `cad_pid`. Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff ---truncated--- Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2021-47118 CVE - 2021-47118 ELSA-2024-12606 ELSA-2024-3618

Alpine Linux: CVE-2024-2193: Vulnerability in Multiple Components Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 04/09/2024 Added 03/26/2024 Modified 10/01/2024 Description A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. Solution(s) alpine-linux-upgrade-xen References https://attackerkb.com/topics/cve-2024-2193 CVE - 2024-2193 https://security.alpinelinux.org/vuln/CVE-2024-2193

Debian: CVE-2021-47114: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption by fallocate When fallocate punches holes out of inode size, if original isize is in the middle of last cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time isize is not yet updated to match the new size, if writeback is kicked in, it will invoke ocfs2_writepage()->block_write_full_page() where the pages out of inode size will be dropped.That will cause file corruption.Fix this by zero out eof blocks when extending the inode size. Running the following command with qemu-image 4.2.1 can get a corrupted coverted image file easily. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv The usage of fallocate in qemu is like this, it first punches holes out of inode size, then extend the inode size. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0 v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-fsdevel/[email protected]/T/ Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47114 CVE - 2021-47114

Debian: CVE-2021-47131: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix use-after-free after the TLS device goes down and up When a netdev with active TLS offload goes down, tls_device_down is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context. This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode. On the TX side tls_sw_fallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets. The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tls_dev_resync after tls_dev_del). A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback mode. It's used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resync_async, which is allocated and freed by the driver). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47131 CVE - 2021-47131

Debian: CVE-2021-47134: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: efi/fdt: fix panic when no valid fdt found setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no valid fdt found then initial_boot_params will be null. So we should stop further fdt processing here. I encountered this issue on risc-v. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47134 CVE - 2021-47134

Huawei EulerOS: CVE-2021-47131: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 07/23/2024 Added 07/23/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix use-after-free after the TLS device goes down and up When a netdev with active TLS offload goes down, tls_device_down is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context. This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode. On the TX side tls_sw_fallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets. The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tls_dev_resync after tls_dev_del). A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback mode. It's used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resync_async, which is allocated and freed by the driver). Solution(s) huawei-euleros-2_0_sp8-upgrade-bpftool huawei-euleros-2_0_sp8-upgrade-kernel huawei-euleros-2_0_sp8-upgrade-kernel-devel huawei-euleros-2_0_sp8-upgrade-kernel-headers huawei-euleros-2_0_sp8-upgrade-kernel-tools huawei-euleros-2_0_sp8-upgrade-kernel-tools-libs huawei-euleros-2_0_sp8-upgrade-perf huawei-euleros-2_0_sp8-upgrade-python-perf huawei-euleros-2_0_sp8-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47131 CVE - 2021-47131 EulerOS-SA-2024-2476

SUSE: CVE-2021-47130: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: nvmet: fix freeing unallocated p2pmem In case p2p device was found but the p2p pool is empty, the nvme target is still trying to free the sgl from the p2p pool instead of the regular sgl pool and causing a crash (BUG() is called). Instead, assign the p2p_dev for the request only if it was allocated from p2p pool. This is the crash that was caused: [Sun May 30 19:13:53 2021] ------------[ cut here ]------------ [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518! [Sun May 30 19:13:53 2021] invalid opcode: 0000 [#1] SMP PTI ... [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518! ... [Sun May 30 19:13:53 2021] RIP: 0010:gen_pool_free_owner+0xa8/0xb0 ... [Sun May 30 19:13:53 2021] Call Trace: [Sun May 30 19:13:53 2021] ------------[ cut here ]------------ [Sun May 30 19:13:53 2021]pci_free_p2pmem+0x2b/0x70 [Sun May 30 19:13:53 2021]pci_p2pmem_free_sgl+0x4f/0x80 [Sun May 30 19:13:53 2021]nvmet_req_free_sgls+0x1e/0x80 [nvmet] [Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518! [Sun May 30 19:13:53 2021]nvmet_rdma_release_rsp+0x4e/0x1f0 [nvmet_rdma] [Sun May 30 19:13:53 2021]nvmet_rdma_send_done+0x1c/0x60 [nvmet_rdma] 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-47130 CVE - 2021-47130

Debian: CVE-2024-23944: zookeeper -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. Solution(s) debian-upgrade-zookeeper References https://attackerkb.com/topics/cve-2024-23944 CVE - 2024-23944

Debian: CVE-2024-2193: xen -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 12/31/2024 Added 12/30/2024 Modified 12/30/2024 Description A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. Solution(s) debian-upgrade-xen References https://attackerkb.com/topics/cve-2024-2193 CVE - 2024-2193 DSA-5836-1

Debian: CVE-2021-47124: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: io_uring: fix link timeout refs WARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] io_put_req fs/io_uring.c:2140 [inline] io_queue_linked_timeout fs/io_uring.c:6300 [inline] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [inline] io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [inline] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() should put only one reference of the linked timeout request, however in case of racing with the master request's completion first io_req_complete() puts one and then io_put_req_deferred() is called. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47124 CVE - 2021-47124

Debian: CVE-2021-47128: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: bpf, lockdown, audit: Fix buggy SELinux lockdown permission checks Commit 59438b46471a ("security,lockdown,selinux: implement SELinux lockdown") added an implementation of the locked_down LSM hook to SELinux, with the aim to restrict which domains are allowed to perform operations that would breach lockdown. This is indirectly also getting audit subsystem involved to report events. The latter is problematic, as reported by Ondrej and Serhei, since it can bring down the whole system via audit: 1) The audit events that are triggered due to calls to security_locked_down() can OOM kill a machine, see below details [0]. 2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit() when trying to wake up kauditd, for example, when using trace_sched_switch() tracepoint, see details in [1]. Triggering this was not via some hypothetical corner case, but with existing tools like runqlat & runqslower from bcc, for example, which make use of this tracepoint. Rough call sequence goes like: rq_lock(rq) -> -------------------------+ trace_sched_switch() -> | bpf_prog_xyz() -> +-> deadlock selinux_lockdown() -> | audit_log_end() ->| wake_up_interruptible() ->| try_to_wake_up() -> | rq_lock(rq) --------------+ What's worse is that the intention of 59438b46471a to further restrict lockdown settings for specific applications in respect to the global lockdown policy is completely broken for BPF. The SELinux policy rule for the current lockdown check looks something like this: allow <who> <who> : lockdown { <reason> }; However, this doesn't match with the 'current' task where the security_locked_down() is executed, example: httpd does a syscall. There is a tracing program attached to the syscall which triggers a BPF program to run, which ends up doing a bpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does the permission check against 'current', that is, httpd in this example. httpd has literally zero relation to this tracing program, and it would be nonsensical having to write an SELinux policy rule against httpd to let the tracing helper pass. The policy in this case needs to be against the entity that is installing the BPF program. For example, if bpftrace would generate a histogram of syscall counts by user space application: bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' bpftrace would then go and generate a BPF program from this internally. One way of doing it [for the sake of the example] could be to call bpf_get_current_task() helper and then access current->comm via one of bpf_probe_read_kernel{,_str}() helpers. So the program itself has nothing to do with httpd or any other random app doing a syscall here. The BPF program _explicitly initiated_ the lockdown check. The allow/deny policy belongs in the context of bpftrace: meaning, you want to grant bpftrace access to use these helpers, but other tracers on the system like my_random_tracer _not_. Therefore fix all three issues at the same time by taking a completely different approach for the security_locked_down() hook, that is, move the check into the program verification phase where we actually retrieve the BPF func proto. This also reliably gets the task (current) that is trying to install the BPF tracing program, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since we're moving this out of the BPF helper's fast-path which can be called several millions of times per second. The check is then also in line with other security_locked_down() hooks in the system where the enforcement is performed at open/load time, for example, open_kcore() for /proc/kcore access or module_sig_check() for module signatures just to pick f ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47128 CVE - 2021-47128

Amazon Linux AMI 2: CVE-2021-47129: Security patch for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 08/03/2024 Added 08/02/2024 Modified 08/02/2024 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: skip expectations for confirmed conntrack nft_ct_expect_obj_eval() calls nf_ct_ext_add() for a confirmed conntrack entry. However, nf_ct_ext_add() can only be called for !nf_ct_is_confirmed(). [ 1825.349056] WARNING: CPU: 0 PID: 1279 at net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351493] Code: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd <0f> 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00 [ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202 [ 1825.351790] RAX: 000000000000000e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887 [ 1825.351881] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88814f578440 [ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447 [ 1825.352060] R10: ffffed1029eaf088 R11: 0000000000000001 R12: ffff88814f578440 [ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20 [ 1825.352240] FS:00007f992261c900(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000 [ 1825.352343] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1825.352417] CR2: 000056070a4d1158 CR3: 000000015efe0000 CR4: 0000000000350ee0 [ 1825.352508] Call Trace: [ 1825.352544]nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack] [ 1825.352641]nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct] [ 1825.352716]nft_do_chain+0x232/0x850 [nf_tables] Add the ct helper extension only for unconfirmed conntrack. Skip rule evaluation if the ct helper extension does not exist. Thus, you can only create expectations from the first packet. It should be possible to remove this limitation by adding a new action to attach a generic ct helper to the first packet. Then, use this ct helper extension from follow up packets to create the ct expectation. While at it, add a missing check to skip the template conntrack too and remove check for IPCT_UNTRACK which is implicit to !ct. 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-47129 AL2/ALASKERNEL-5.10-2022-002 AL2/ALASKERNEL-5.4-2022-004 CVE - 2021-47129

F5 Networks: CVE-2024-2193: K000139682: Speculative race conditions vulnerability CVE-2024-2193 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 05/22/2024 Added 05/22/2024 Modified 12/05/2024 Description A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. Solution(s) f5-big-ip-upgrade-latest References https://attackerkb.com/topics/cve-2024-2193 CVE - 2024-2193 https://my.f5.com/manage/s/article/K000139682

Ubuntu: (CVE-2021-47129): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: skip expectations for confirmed conntrack nft_ct_expect_obj_eval() calls nf_ct_ext_add() for a confirmed conntrack entry. However, nf_ct_ext_add() can only be called for !nf_ct_is_confirmed(). [ 1825.349056] WARNING: CPU: 0 PID: 1279 at net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x1a0 [nf_conntrack] [ 1825.351493] Code: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd <0f> 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00 [ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202 [ 1825.351790] RAX: 000000000000000e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887 [ 1825.351881] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88814f578440 [ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447 [ 1825.352060] R10: ffffed1029eaf088 R11: 0000000000000001 R12: ffff88814f578440 [ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20 [ 1825.352240] FS:00007f992261c900(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000 [ 1825.352343] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1825.352417] CR2: 000056070a4d1158 CR3: 000000015efe0000 CR4: 0000000000350ee0 [ 1825.352508] Call Trace: [ 1825.352544]nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack] [ 1825.352641]nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct] [ 1825.352716]nft_do_chain+0x232/0x850 [nf_tables] Add the ct helper extension only for unconfirmed conntrack. Skip rule evaluation if the ct helper extension does not exist. Thus, you can only create expectations from the first packet. It should be possible to remove this limitation by adding a new action to attach a generic ct helper to the first packet. Then, use this ct helper extension from follow up packets to create the ct expectation. While at it, add a missing check to skip the template conntrack too and remove check for IPCT_UNTRACK which is implicit to !ct. 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-47129 CVE - 2021-47129 https://git.kernel.org/linus/1710eb913bdcda3917f44d383c32de6bdabfc836 https://git.kernel.org/stable/c/1710eb913bdcda3917f44d383c32de6bdabfc836 https://git.kernel.org/stable/c/2c0e6b35b88a961127066a1028bce9c727cbc3e5 https://git.kernel.org/stable/c/5f3429c05e4028a0e241afdad856dd15dec2ffb9 https://git.kernel.org/stable/c/da8d31e80ff425f5a65dab7060d5c4aba749e562 https://www.cve.org/CVERecord?id=CVE-2021-47129 View more

SUSE: CVE-2021-47131: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/tls: Fix use-after-free after the TLS device goes down and up When a netdev with active TLS offload goes down, tls_device_down is called to stop the offload and tear down the TLS context. However, the socket stays alive, and it still points to the TLS context, which is now deallocated. If a netdev goes up, while the connection is still active, and the data flow resumes after a number of TCP retransmissions, it will lead to a use-after-free of the TLS context. This commit addresses this bug by keeping the context alive until its normal destruction, and implements the necessary fallbacks, so that the connection can resume in software (non-offloaded) kTLS mode. On the TX side tls_sw_fallback is used to encrypt all packets. The RX side already has all the necessary fallbacks, because receiving non-decrypted packets is supported. The thing needed on the RX side is to block resync requests, which are normally produced after receiving non-decrypted packets. The necessary synchronization is implemented for a graceful teardown: first the fallbacks are deployed, then the driver resources are released (it used to be possible to have a tls_dev_resync after tls_dev_del). A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback mode. It's used to skip the RX resync logic completely, as it becomes useless, and some objects may be released (for example, resync_async, which is allocated and freed by the driver). Solution(s) suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-man suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure 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-source-azure suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47131 CVE - 2021-47131

SUSE: CVE-2021-47118: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 08/16/2024 Added 08/09/2024 Modified 08/09/2024 Description In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid.Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid().As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early.As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g.when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`. Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff ---truncated--- Solution(s) suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-azure suse-upgrade-kernel-azure-base suse-upgrade-kernel-azure-devel suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-default-extra suse-upgrade-kernel-default-man suse-upgrade-kernel-devel suse-upgrade-kernel-devel-azure 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-source-azure suse-upgrade-kernel-syms suse-upgrade-kernel-syms-azure suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47118 CVE - 2021-47118

Ubuntu: (CVE-2021-47117): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553]ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975]ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368]ext4_find_extent+0x300/0x330 [ext4] [130747.335759]ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179]ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567]ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995]ext4_readpage+0x54/0x100 [ext4] [130747.337359]generic_file_buffered_read+0x410/0xae8 [130747.337767]generic_file_read_iter+0x114/0x190 [130747.338152]ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556]__vfs_read+0x11c/0x188 [130747.338851]vfs_read+0x94/0x150 [130747.339110]ksys_read+0x74/0xf0 This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable).Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)." 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-47117 CVE - 2021-47117 https://git.kernel.org/linus/082cd4ec240b8734a82a89ffb890216ac98fec68 https://git.kernel.org/stable/c/082cd4ec240b8734a82a89ffb890216ac98fec68 https://git.kernel.org/stable/c/48105dc98c9ca35af418746277b087cb2bc6df7c https://git.kernel.org/stable/c/569496aa3776eea1ff0d49d0174ac1b7e861e107 https://git.kernel.org/stable/c/5b3a9a2be59478b013a430ac57b0f3d65471b071 https://git.kernel.org/stable/c/920697b004e49cb026e2e15fe91be065bf0741b7 https://git.kernel.org/stable/c/d3b668b96ad3192c0581a248ae2f596cd054792a https://git.kernel.org/stable/c/d8116743ef5432336289256b2f7c117299213eb9 https://git.kernel.org/stable/c/e33bafad30d34cfa5e9787cb099cab05e2677fcb https://www.cve.org/CVERecord?id=CVE-2021-47117 View more

Amazon Linux AMI 2: CVE-2021-47111: Security patch for kernel (ALASKERNEL-5.10-2022-002) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 08/03/2024 Added 08/02/2024 Modified 08/02/2024 Description In the Linux kernel, the following vulnerability has been resolved: xen-netback: take a reference to the RX task thread Do this in order to prevent the task from being freed if the thread returns (which can be triggered by the frontend) before the call to kthread_stop done as part of the backend tear down. Not taking the reference will lead to a use-after-free in that scenario. Such reference was taken before but dropped as part of the rework done in 2ac061ce97f4. Reintroduce the reference taking and add a comment this time explaining why it's needed. This is XSA-374 / CVE-2021-28691. 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-47111 AL2/ALASKERNEL-5.10-2022-002 CVE - 2021-47111

Amazon Linux AMI 2: CVE-2024-2193: Security patch for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 04/02/2024 Added 04/01/2024 Modified 05/01/2024 Description A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths. 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-livepatch-4-14-336-257-568 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-210-201-852 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-149-99-161 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-2024-2193 AL2/ALAS-2024-2525 AL2/ALASKERNEL-5.10-2024-053 AL2/ALASKERNEL-5.15-2024-039 AL2/ALASKERNEL-5.4-2024-062 CVE - 2024-2193

Amazon Linux AMI 2: CVE-2021-47117: Security patch for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 03/15/2024 Created 08/03/2024 Added 08/02/2024 Modified 08/02/2024 Description In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553]ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975]ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368]ext4_find_extent+0x300/0x330 [ext4] [130747.335759]ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179]ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567]ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995]ext4_readpage+0x54/0x100 [ext4] [130747.337359]generic_file_buffered_read+0x410/0xae8 [130747.337767]generic_file_read_iter+0x114/0x190 [130747.338152]ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556]__vfs_read+0x11c/0x188 [130747.338851]vfs_read+0x94/0x150 [130747.339110]ksys_read+0x74/0xf0 This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable).Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)." 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-livepatch-4-14-238-182-421 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-47117 AL2/ALAS-2021-1685 AL2/ALASKERNEL-5.10-2022-002 AL2/ALASKERNEL-5.4-2022-004 CVE - 2021-47117