ISHACK AI BOT

VMware Photon OS: CVE-2024-26773 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-26773 CVE - 2024-26773

Debian: CVE-2024-26777: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 05/08/2024 Added 05/08/2024 Modified 07/03/2024 Description In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26777 CVE - 2024-26777 DSA-5681-1

Debian: CVE-2024-26779: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 05/08/2024 Added 05/08/2024 Modified 07/03/2024 Description In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-26779 CVE - 2024-26779 DSA-5681-1

Amazon Linux 2023: CVE-2024-26737: Important priority package update for kernel Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/03/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done.In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. A use-after-free flaw was found in the Linux kernel’s BPF functionality. This flaw allows a local user to crash the system. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-82-99-168 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-26737 CVE - 2024-26737 https://alas.aws.amazon.com/AL2023/ALAS-2024-784.html

Amazon Linux 2023: CVE-2024-26773: Medium priority package update for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/03/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group A vulnerability was found in the ext4_mb_try_best_found() function in the Linux kernel. This issue could lead to memory corruption or crashes due to the allocation of blocks from a group with a corrupted block bitmap. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-82-99-168 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-26773 CVE - 2024-26773 https://alas.aws.amazon.com/AL2023/ALAS-2024-603.html https://alas.aws.amazon.com/AL2023/ALAS-2024-784.html

Amazon Linux 2023: CVE-2024-26772: Medium priority package update for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/03/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap. A vulnerability was found in the ext4_mb_find_by_goal() function in the Linux kernel. This issue could lead to memory corruption or crashes due to the allocation of blocks from a group with a corrupted block bitmap. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-82-99-168 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-26772 CVE - 2024-26772 https://alas.aws.amazon.com/AL2023/ALAS-2024-603.html https://alas.aws.amazon.com/AL2023/ALAS-2024-784.html

Amazon Linux 2023: CVE-2024-26688: Important priority package update for kernel Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 04/03/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid. E.g: Taking the following steps: fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0); fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error: ... ... case Opt_pagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { pr_err("Unsupported page size %lu MB\n", ps / SZ_1M); return -EINVAL; } return 0; ... ... This is a problem because later on, we will dereference ctxt->hstate in hugetlbfs_fill_super() ... ... sb->s_blocksize = huge_page_size(ctx->hstate); ... ... Causing below Oops. Fix this by replacing cxt->hstate value only when then pagesize is known to be valid. kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: GE6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS:00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel:<TASK> kernel:? __die_body+0x1a/0x60 kernel:? page_fault_oops+0x16f/0x4a0 kernel:? search_bpf_extables+0x65/0x70 kernel:? fixup_exception+0x22/0x310 kernel:? exc_page_fault+0x69/0x150 kernel:? asm_exc_page_fault+0x22/0x30 kernel:? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel:? hugetlbfs_fill_super+0xb4/0x1a0 kernel:? hugetlbfs_fill_super+0x28/0x1a0 kernel:? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel:vfs_get_super+0x40/0xa0 kernel:? __pfx_bpf_lsm_capable+0x10/0x10 kernel:vfs_get_tree+0x25/0xd0 kernel:vfs_cmd_create+0x64/0xe0 kernel:__x64_sys_fsconfig+0x395/0x410 kernel:do_syscall_64+0x80/0x160 kernel:? syscall_exit_to_user_mode+0x82/0x240 kernel:? do_syscall_64+0x8d/0x160 kernel:? syscall_exit_to_user_mode+0x82/0x240 kernel:? do_syscall_64+0x8d/0x160 kernel:? exc_page_fault+0x69/0x150 kernel:entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff ---truncated--- A vulnerability was found in the Linux kernel during hugetlb filesystem configuration, whereby a NULL pointer dereference caused by invalid pagesize values can lead to potential crashes. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-79-99-164 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-26688 CVE - 2024-26688 https://alas.aws.amazon.com/AL2023/ALAS-2024-549.html

Oracle Linux: CVE-2023-45288: ELSA-2024-2724:git-lfs security update (IMPORTANT) (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 04/03/2024 Created 05/22/2024 Added 04/24/2024 Modified 01/08/2025 Description An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection. A vulnerability was discovered with the implementation of the HTTP/2 protocol in the Go programming language. There were insufficient limitations on the amount of CONTINUATION frames sent within a single stream. An attacker could potentially exploit this to cause a Denial of Service (DoS) attack. Solution(s) oracle-linux-upgrade-delve oracle-linux-upgrade-git-lfs oracle-linux-upgrade-golang oracle-linux-upgrade-golang-bin oracle-linux-upgrade-golang-docs oracle-linux-upgrade-golang-misc oracle-linux-upgrade-golang-src oracle-linux-upgrade-golang-tests oracle-linux-upgrade-go-toolset References https://attackerkb.com/topics/cve-2023-45288 CVE - 2023-45288 ELSA-2024-2724 ELSA-2024-1963 ELSA-2024-2699 ELSA-2024-1962 ELSA-2024-2562 ELSA-2024-3259 ELSA-2024-3346 View more

Oracle Linux: CVE-2024-27982: ELSA-2024-2853:nodejs:20 security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:N/AC:L/Au:N/C:P/I:P/A:N) Published 04/03/2024 Created 05/21/2024 Added 05/09/2024 Modified 01/07/2025 Description The team has identified a critical vulnerability in the http server of the most recent version of Node, where malformed headers can lead to HTTP request smuggling. Specifically, if a space is placed before a content-length header, it is not interpreted correctly, enabling attackers to smuggle in a second request within the body of the first. An HTTP Request Smuggling vulnerability was found in Node.js due to Content-Length Obfuscation in the HTTP server. Malformed headers, particularly if a space is inserted before a content-length header, can result in HTTP request smuggling. This flaw allows attackers to inject a second request within the body of the first and poison web caches, bypass web application firewalls, and execute Cross-site scripting (XSS) attacks. Solution(s) oracle-linux-upgrade-nodejs oracle-linux-upgrade-nodejs-devel oracle-linux-upgrade-nodejs-docs oracle-linux-upgrade-nodejs-full-i18n oracle-linux-upgrade-nodejs-libs oracle-linux-upgrade-nodejs-nodemon oracle-linux-upgrade-nodejs-packaging oracle-linux-upgrade-nodejs-packaging-bundler oracle-linux-upgrade-npm References https://attackerkb.com/topics/cve-2024-27982 CVE - 2024-27982 ELSA-2024-2853 ELSA-2024-2780 ELSA-2024-2910 ELSA-2024-2779 ELSA-2024-2778

Oracle Linux: CVE-2024-31081: ELSA-2024-2037:tigervnc security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:P/A:C) Published 04/03/2024 Created 05/22/2024 Added 04/12/2024 Modified 01/07/2025 Description A heap-based buffer over-read vulnerability was found in the X.org server's ProcXIPassiveGrabDevice() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker's inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads. Solution(s) oracle-linux-upgrade-tigervnc oracle-linux-upgrade-tigervnc-icons oracle-linux-upgrade-tigervnc-license oracle-linux-upgrade-tigervnc-selinux oracle-linux-upgrade-tigervnc-server oracle-linux-upgrade-tigervnc-server-applet oracle-linux-upgrade-tigervnc-server-minimal oracle-linux-upgrade-tigervnc-server-module oracle-linux-upgrade-xorg-x11-server-common oracle-linux-upgrade-xorg-x11-server-devel oracle-linux-upgrade-xorg-x11-server-source oracle-linux-upgrade-xorg-x11-server-xdmx oracle-linux-upgrade-xorg-x11-server-xephyr oracle-linux-upgrade-xorg-x11-server-xnest oracle-linux-upgrade-xorg-x11-server-xorg oracle-linux-upgrade-xorg-x11-server-xvfb oracle-linux-upgrade-xorg-x11-server-xwayland oracle-linux-upgrade-xorg-x11-server-xwayland-devel References https://attackerkb.com/topics/cve-2024-31081 CVE - 2024-31081 ELSA-2024-2037 ELSA-2024-3343 ELSA-2024-2080 ELSA-2024-2616 ELSA-2024-3261 ELSA-2024-3258 ELSA-2024-1785 ELSA-2024-9093 ELSA-2024-9122 View more

Huawei EulerOS: CVE-2024-26772: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 07/16/2024 Added 07/16/2024 Modified 12/12/2024 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap. 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-2024-26772 CVE - 2024-26772 EulerOS-SA-2024-1911

Oracle Linux: CVE-2024-26734: ELSA-2024-12796: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 04/03/2024 Created 11/13/2024 Added 11/11/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: devlink: fix possible use-after-free and memory leaks in devlink_init() The pernet operations structure for the subsystem must be registered before registering the generic netlink family. Make an unregister in case of unsuccessful registration. A vulnerability was found in the devlink_init() function in the Linux kernel. Use-after-free and memory leak issues can occur due to an incorrect order of initialization and cleanup in case of errors. This issue could lead to memory corruption or crashes. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-26734 CVE - 2024-26734 ELSA-2024-12796 ELSA-2024-12830 ELSA-2024-12845 ELSA-2024-12884

Ubuntu: (Multiple Advisories) (CVE-2024-26769): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 07/02/2024 Added 07/01/2024 Modified 07/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1030-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1046-gkeop ubuntu-upgrade-linux-image-5-15-0-1056-ibm ubuntu-upgrade-linux-image-5-15-0-1057-ibm ubuntu-upgrade-linux-image-5-15-0-1058-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1058-nvidia ubuntu-upgrade-linux-image-5-15-0-1058-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1058-raspi ubuntu-upgrade-linux-image-5-15-0-1060-gke ubuntu-upgrade-linux-image-5-15-0-1060-kvm ubuntu-upgrade-linux-image-5-15-0-1061-oracle ubuntu-upgrade-linux-image-5-15-0-1062-gcp ubuntu-upgrade-linux-image-5-15-0-1063-aws ubuntu-upgrade-linux-image-5-15-0-1065-azure-fde ubuntu-upgrade-linux-image-5-15-0-1066-azure ubuntu-upgrade-linux-image-5-15-0-110-lowlatency ubuntu-upgrade-linux-image-5-15-0-110-lowlatency-64k ubuntu-upgrade-linux-image-5-15-0-112-generic ubuntu-upgrade-linux-image-5-15-0-112-generic-64k ubuntu-upgrade-linux-image-5-15-0-112-generic-lpae ubuntu-upgrade-linux-image-5-15-0-113-generic ubuntu-upgrade-linux-image-5-15-0-113-generic-64k ubuntu-upgrade-linux-image-5-15-0-113-generic-lpae ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-26769 CVE - 2024-26769 USN-6820-1 USN-6820-2 USN-6821-1 USN-6821-2 USN-6821-3 USN-6821-4 USN-6828-1 USN-6871-1 USN-6892-1 USN-6919-1 View more

Ubuntu: (Multiple Advisories) (CVE-2024-26766): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off-by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990]<TASK> [ 1081.021929]hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364]hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633]hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001]ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978]dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347]__sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4}# SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = {0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = {0x3000012e9f8000, 0x8} }, { qw = {0x59000dfb9d0000, 0x8} }, { qw = {0x78000e02e40000, 0x8} }} }, sdma_hdr =0x400300015528b000,<<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the machine is stable. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1030-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1046-gkeop ubuntu-upgrade-linux-image-5-15-0-1056-ibm ubuntu-upgrade-linux-image-5-15-0-1057-ibm ubuntu-upgrade-linux-image-5-15-0-1058-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1058-nvidia ubuntu-upgrade-linux-image-5-15-0-1058-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1058-raspi ubuntu-upgrade-linux-image-5-15-0-1060-gke ubuntu-upgrade-linux-image-5-15-0-1060-kvm ubuntu-upgrade-linux-image-5-15-0-1061-oracle ubuntu-upgrade-linux-image-5-15-0-1062-gcp ubuntu-upgrade-linux-image-5-15-0-1063-aws ubuntu-upgrade-linux-image-5-15-0-1065-azure-fde ubuntu-upgrade-linux-image-5-15-0-1066-azure ubuntu-upgrade-linux-image-5-15-0-110-lowlatency ubuntu-upgrade-linux-image-5-15-0-110-lowlatency-64k ubuntu-upgrade-linux-image-5-15-0-112-generic ubuntu-upgrade-linux-image-5-15-0-112-generic-64k ubuntu-upgrade-linux-image-5-15-0-112-generic-lpae ubuntu-upgrade-linux-image-5-15-0-113-generic ubuntu-upgrade-linux-image-5-15-0-113-generic-64k ubuntu-upgrade-linux-image-5-15-0-113-generic-lpae ubuntu-upgrade-linux-image-5-4-0-1038-iot ubuntu-upgrade-linux-image-5-4-0-1045-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1073-ibm ubuntu-upgrade-linux-image-5-4-0-1086-bluefield ubuntu-upgrade-linux-image-5-4-0-1093-gkeop ubuntu-upgrade-linux-image-5-4-0-1110-raspi ubuntu-upgrade-linux-image-5-4-0-1114-kvm ubuntu-upgrade-linux-image-5-4-0-1125-oracle ubuntu-upgrade-linux-image-5-4-0-1126-aws ubuntu-upgrade-linux-image-5-4-0-1130-gcp ubuntu-upgrade-linux-image-5-4-0-1131-azure ubuntu-upgrade-linux-image-5-4-0-186-generic ubuntu-upgrade-linux-image-5-4-0-186-generic-lpae ubuntu-upgrade-linux-image-5-4-0-186-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-26766 CVE - 2024-26766 USN-6820-1 USN-6820-2 USN-6821-1 USN-6821-2 USN-6821-3 USN-6821-4 USN-6828-1 USN-6831-1 USN-6867-1 USN-6871-1 USN-6892-1 USN-6919-1 View more

Ubuntu: (CVE-2024-26765): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ... Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58 Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-26765 CVE - 2024-26765 https://git.kernel.org/linus/1001db6c42e4012b55e5ee19405490f23e033b5a https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53 https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464 https://www.cve.org/CVERecord?id=CVE-2024-26765 View more

Ubuntu: (Multiple Advisories) (CVE-2024-26763): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/[email protected]/T/ Solution(s) ubuntu-upgrade-linux-image-5-15-0-1030-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1046-gkeop ubuntu-upgrade-linux-image-5-15-0-1056-ibm ubuntu-upgrade-linux-image-5-15-0-1057-ibm ubuntu-upgrade-linux-image-5-15-0-1058-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1058-nvidia ubuntu-upgrade-linux-image-5-15-0-1058-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1058-raspi ubuntu-upgrade-linux-image-5-15-0-1060-gke ubuntu-upgrade-linux-image-5-15-0-1060-kvm ubuntu-upgrade-linux-image-5-15-0-1061-oracle ubuntu-upgrade-linux-image-5-15-0-1062-gcp ubuntu-upgrade-linux-image-5-15-0-1063-aws ubuntu-upgrade-linux-image-5-15-0-1065-azure-fde ubuntu-upgrade-linux-image-5-15-0-1066-azure ubuntu-upgrade-linux-image-5-15-0-110-lowlatency ubuntu-upgrade-linux-image-5-15-0-110-lowlatency-64k ubuntu-upgrade-linux-image-5-15-0-112-generic ubuntu-upgrade-linux-image-5-15-0-112-generic-64k ubuntu-upgrade-linux-image-5-15-0-112-generic-lpae ubuntu-upgrade-linux-image-5-15-0-113-generic ubuntu-upgrade-linux-image-5-15-0-113-generic-64k ubuntu-upgrade-linux-image-5-15-0-113-generic-lpae ubuntu-upgrade-linux-image-5-4-0-1038-iot ubuntu-upgrade-linux-image-5-4-0-1045-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1073-ibm ubuntu-upgrade-linux-image-5-4-0-1086-bluefield ubuntu-upgrade-linux-image-5-4-0-1093-gkeop ubuntu-upgrade-linux-image-5-4-0-1110-raspi ubuntu-upgrade-linux-image-5-4-0-1114-kvm ubuntu-upgrade-linux-image-5-4-0-1125-oracle ubuntu-upgrade-linux-image-5-4-0-1126-aws ubuntu-upgrade-linux-image-5-4-0-1130-gcp ubuntu-upgrade-linux-image-5-4-0-1131-azure ubuntu-upgrade-linux-image-5-4-0-186-generic ubuntu-upgrade-linux-image-5-4-0-186-generic-lpae ubuntu-upgrade-linux-image-5-4-0-186-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-26763 CVE - 2024-26763 USN-6820-1 USN-6820-2 USN-6821-1 USN-6821-2 USN-6821-3 USN-6821-4 USN-6828-1 USN-6831-1 USN-6867-1 USN-6871-1 USN-6892-1 USN-6919-1 View more

Ubuntu: (CVE-2024-26757): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-26757 CVE - 2024-26757 https://git.kernel.org/linus/55a48ad2db64737f7ffc0407634218cc6e4c513b https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3 https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b https://www.cve.org/CVERecord?id=CVE-2024-26757

Ubuntu: (CVE-2024-26760): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free(). Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-26760 CVE - 2024-26760 https://git.kernel.org/linus/de959094eb2197636f7c803af0943cb9d3b35804 https://git.kernel.org/stable/c/1cfe9489fb563e9a0c9cdc5ca68257a44428c2ec https://git.kernel.org/stable/c/4ebc079f0c7dcda1270843ab0f38ab4edb8f7921 https://git.kernel.org/stable/c/de959094eb2197636f7c803af0943cb9d3b35804 https://git.kernel.org/stable/c/f49b20fd0134da84a6bd8108f9e73c077b7d6231 https://www.cve.org/CVERecord?id=CVE-2024-26760 View more

Ubuntu: (CVE-2024-26753): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-26753 CVE - 2024-26753 https://git.kernel.org/linus/c0ec2a712daf133d9996a8a1b7ee2d4996080363 https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86 https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47 https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63 https://git.kernel.org/stable/c/c0ec2a712daf133d9996a8a1b7ee2d4996080363 https://git.kernel.org/stable/c/ef1e47d50324e232d2da484fe55a54274eeb9bc1 https://www.cve.org/CVERecord?id=CVE-2024-26753 View more

Ubuntu: (CVE-2024-26730): linux-raspi-realtime vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775) Fix access to temperature configuration registers The number of temperature configuration registers does not always match the total number of temperature registers. This can result in access errors reported if KASAN is enabled. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core Solution(s) ubuntu-upgrade-linux-raspi-realtime References https://attackerkb.com/topics/cve-2024-26730 CVE - 2024-26730 https://git.kernel.org/linus/d56e460e19ea8382f813eb489730248ec8d7eb73 https://git.kernel.org/stable/c/c196387820c9214c5ceaff56d77303c82514b8b1 https://git.kernel.org/stable/c/d56e460e19ea8382f813eb489730248ec8d7eb73 https://git.kernel.org/stable/c/f006c45a3ea424f8f6c8e4b9283bc245ce2a4d0f https://www.cve.org/CVERecord?id=CVE-2024-26730

Ubuntu: (Multiple Advisories) (CVE-2024-26749): Linux kernel vulnerabilities Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 04/03/2024 Created 07/02/2024 Added 07/01/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][T534] [ 1542.653162][T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][T534]__list_del_entry_valid+0x10/0xd4 [ 1542.665375][T534]cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][T534]usb_ep_disable+0x44/0xe4 [ 1542.675948][T534]ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][T534]ffs_func_set_alt+0x74/0x368 [ 1542.685478][T534]ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem. Solution(s) ubuntu-upgrade-linux-image-5-15-0-1030-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1046-gkeop ubuntu-upgrade-linux-image-5-15-0-1056-ibm ubuntu-upgrade-linux-image-5-15-0-1057-ibm ubuntu-upgrade-linux-image-5-15-0-1058-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1058-nvidia ubuntu-upgrade-linux-image-5-15-0-1058-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1058-raspi ubuntu-upgrade-linux-image-5-15-0-1060-gke ubuntu-upgrade-linux-image-5-15-0-1060-kvm ubuntu-upgrade-linux-image-5-15-0-1061-oracle ubuntu-upgrade-linux-image-5-15-0-1062-gcp ubuntu-upgrade-linux-image-5-15-0-1063-aws ubuntu-upgrade-linux-image-5-15-0-1065-azure-fde ubuntu-upgrade-linux-image-5-15-0-1066-azure ubuntu-upgrade-linux-image-5-15-0-110-lowlatency ubuntu-upgrade-linux-image-5-15-0-110-lowlatency-64k ubuntu-upgrade-linux-image-5-15-0-112-generic ubuntu-upgrade-linux-image-5-15-0-112-generic-64k ubuntu-upgrade-linux-image-5-15-0-112-generic-lpae ubuntu-upgrade-linux-image-5-15-0-113-generic ubuntu-upgrade-linux-image-5-15-0-113-generic-64k ubuntu-upgrade-linux-image-5-15-0-113-generic-lpae ubuntu-upgrade-linux-image-5-4-0-1038-iot ubuntu-upgrade-linux-image-5-4-0-1045-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1073-ibm ubuntu-upgrade-linux-image-5-4-0-1086-bluefield ubuntu-upgrade-linux-image-5-4-0-1093-gkeop ubuntu-upgrade-linux-image-5-4-0-1110-raspi ubuntu-upgrade-linux-image-5-4-0-1114-kvm ubuntu-upgrade-linux-image-5-4-0-1125-oracle ubuntu-upgrade-linux-image-5-4-0-1126-aws ubuntu-upgrade-linux-image-5-4-0-1130-gcp ubuntu-upgrade-linux-image-5-4-0-1131-azure ubuntu-upgrade-linux-image-5-4-0-186-generic ubuntu-upgrade-linux-image-5-4-0-186-generic-lpae ubuntu-upgrade-linux-image-5-4-0-186-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde-lts-22-04 ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-gkeop-5-4 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-raspi2 ubuntu-upgrade-linux-image-snapdragon-hwe-18-04 ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-18-04 ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-26749 CVE - 2024-26749 USN-6820-1 USN-6820-2 USN-6821-1 USN-6821-2 USN-6821-3 USN-6821-4 USN-6828-1 USN-6831-1 USN-6867-1 USN-6871-1 USN-6892-1 USN-6919-1 View more

Ubuntu: (Multiple Advisories) (CVE-2024-26726): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 07/15/2024 Added 07/15/2024 Modified 08/06/2024 Description In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: GW6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again.However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping.Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping.This is normal for normal files, but the free space cache inode is special.We always expect the extent map to be correct.Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce.With this patch in place we no longer panic with my error injection test. Solution(s) ubuntu-upgrade-linux-image-6-5-0-1017-starfive ubuntu-upgrade-linux-image-6-5-0-1020-raspi ubuntu-upgrade-linux-image-6-5-0-1023-aws ubuntu-upgrade-linux-image-6-5-0-1023-nvidia ubuntu-upgrade-linux-image-6-5-0-1023-nvidia-64k ubuntu-upgrade-linux-image-6-5-0-1024-azure ubuntu-upgrade-linux-image-6-5-0-1024-azure-fde ubuntu-upgrade-linux-image-6-5-0-1024-gcp ubuntu-upgrade-linux-image-6-5-0-1026-oracle ubuntu-upgrade-linux-image-6-5-0-1026-oracle-64k ubuntu-upgrade-linux-image-6-5-0-1027-oem ubuntu-upgrade-linux-image-6-5-0-44-generic ubuntu-upgrade-linux-image-6-5-0-44-generic-64k ubuntu-upgrade-linux-image-6-5-0-44-lowlatency ubuntu-upgrade-linux-image-6-5-0-44-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-fde ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-22-04 ubuntu-upgrade-linux-image-generic-hwe-22-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency-64k-hwe-22-04 ubuntu-upgrade-linux-image-lowlatency-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-6-5 ubuntu-upgrade-linux-image-nvidia-64k-6-5 ubuntu-upgrade-linux-image-nvidia-64k-hwe-22-04 ubuntu-upgrade-linux-image-nvidia-hwe-22-04 ubuntu-upgrade-linux-image-oem-22-04 ubuntu-upgrade-linux-image-oem-22-04a ubuntu-upgrade-linux-image-oem-22-04b ubuntu-upgrade-linux-image-oem-22-04c ubuntu-upgrade-linux-image-oem-22-04d ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-64k ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-starfive ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-22-04 References https://attackerkb.com/topics/cve-2024-26726 CVE - 2024-26726 USN-6895-1 USN-6895-2 USN-6895-3 USN-6895-4 USN-6900-1

Huawei EulerOS: CVE-2024-26740: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 07/16/2024 Added 07/16/2024 Modified 12/12/2024 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. 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-2024-26740 CVE - 2024-26740 EulerOS-SA-2024-1911

VMware Photon OS: CVE-2024-26687 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 04/03/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS:0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated--- Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-26687 CVE - 2024-26687

Red Hat: CVE-2024-26661: kernel: drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()' (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 04/02/2024 Created 12/06/2024 Added 12/05/2024 Modified 12/05/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()' In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;" pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL. Solution(s) redhat-upgrade-kernel redhat-upgrade-kernel-rt References CVE-2024-26661 RHSA-2024:9315