ISHACK AI BOT 发布的所有帖子
-
Google Chrome Vulnerability: CVE-2024-6777 Use after free in Navigation
Google Chrome Vulnerability: CVE-2024-6777 Use after free in Navigation Severity 7 CVSS (AV:N/AC:M/Au:N/C:N/I:N/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Use after free in Navigation in Google Chrome prior to 126.0.6478.182 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6777 CVE - 2024-6777
-
Google Chrome Vulnerability: CVE-2024-6772 Inappropriate implementation in V8
Google Chrome Vulnerability: CVE-2024-6772 Inappropriate implementation in V8 Severity 9 CVSS (AV:N/AC:M/Au:N/C:C/I:C/A:C) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description Inappropriate implementation in V8 in Google Chrome prior to 126.0.6478.182 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High) Solution(s) google-chrome-upgrade-latest References https://attackerkb.com/topics/cve-2024-6772 CVE - 2024-6772
-
SUSE: CVE-2024-36137: SUSE Linux Security Advisory
SUSE: CVE-2024-36137: SUSE Linux Security Advisory Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/17/2024 Created 07/19/2024 Added 07/18/2024 Modified 07/23/2024 Description This CVE is addressed in the SUSE advisories SUSE-SU-2024:2543-1, SUSE-SU-2024:2574-1, CVE-2024-36137. Solution(s) suse-upgrade-corepack20 suse-upgrade-nodejs20 suse-upgrade-nodejs20-devel suse-upgrade-nodejs20-docs suse-upgrade-npm20 References https://attackerkb.com/topics/cve-2024-36137 CVE - 2024-36137 SUSE-SU-2024:2543-1 SUSE-SU-2024:2574-1
-
Amazon Linux AMI 2: CVE-2024-41009: Security patch for kernel (Multiple Advisories)
Amazon Linux AMI 2: CVE-2024-41009: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/17/2024 Created 08/29/2024 Added 08/28/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. 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-5-10-223-211-872 amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-164-108-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-41009 AL2/ALASKERNEL-5.10-2024-066 AL2/ALASKERNEL-5.15-2024-050 CVE - 2024-41009
-
Huawei EulerOS: CVE-2024-41009: kernel security update
Huawei EulerOS: CVE-2024-41009: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/17/2024 Created 10/10/2024 Added 10/09/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-41009 CVE - 2024-41009 EulerOS-SA-2024-2544
-
OS X update for AppSandbox (CVE-2023-42925)
OS X update for AppSandbox (CVE-2023-42925) Severity 2 CVSS (AV:L/AC:L/Au:S/C:P/I:N/A:N) Published 07/17/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description The issue was addressed with improved restriction of data container access. This issue is fixed in iOS 17 and iPadOS 17, macOS Sonoma 14. An app may be able to access Notes attachments. Solution(s) apple-osx-upgrade-14 References https://attackerkb.com/topics/cve-2023-42925 CVE - 2023-42925 https://support.apple.com/kb/HT213940
-
Amazon Linux 2023: CVE-2024-41009: Medium priority package update for kernel (Multiple Advisories)
Amazon Linux 2023: CVE-2024-41009: Medium priority package update for kernel (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 07/17/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 overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. 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-97-104-177 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-41009 CVE - 2024-41009 https://alas.aws.amazon.com/AL2023/ALAS-2024-665.html https://alas.aws.amazon.com/AL2023/ALAS-2024-714.html
-
VMware Photon OS: CVE-2024-21135
VMware Photon OS: CVE-2024-21135 Severity 6 CVSS (AV:N/AC:L/Au:M/C:N/I:N/A:C) Published 07/16/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).Supported versions that are affected are 8.0.36 and prior and8.3.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-21135 CVE - 2024-21135
-
Huawei EulerOS: CVE-2022-48843: kernel security update
Huawei EulerOS: CVE-2022-48843: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. 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-2022-48843 CVE - 2022-48843 EulerOS-SA-2024-2441
-
VMware Photon OS: CVE-2024-21142
VMware Photon OS: CVE-2024-21142 Severity 6 CVSS (AV:N/AC:L/Au:M/C:N/I:N/A:C) Published 07/16/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).Supported versions that are affected are 8.0.37 and prior and8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-21142 CVE - 2024-21142
-
Huawei EulerOS: CVE-2022-48775: kernel security update
Huawei EulerOS: CVE-2022-48775: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add(): If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). 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-2022-48775 CVE - 2022-48775 EulerOS-SA-2024-2441
-
VMware Photon OS: CVE-2024-21171
VMware Photon OS: CVE-2024-21171 Severity 7 CVSS (AV:N/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).Supported versions that are affected are 8.0.37 and prior and8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-21171 CVE - 2024-21171
-
VMware Photon OS: CVE-2024-21176
VMware Photon OS: CVE-2024-21176 Severity 5 CVSS (AV:N/AC:H/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).Supported versions that are affected are 8.4.0 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.3 (Availability impacts).CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-21176 CVE - 2024-21176
-
Huawei EulerOS: CVE-2022-48789: kernel security update
Huawei EulerOS: CVE-2022-48789: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/16/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. 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-2022-48789 CVE - 2022-48789 EulerOS-SA-2024-2441
-
VMware Photon OS: CVE-2024-21125
VMware Photon OS: CVE-2024-21125 Severity 6 CVSS (AV:N/AC:L/Au:M/C:N/I:N/A:C) Published 07/16/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS).Supported versions that are affected are 8.0.37 and prior and8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-21125 CVE - 2024-21125
-
VMware Photon OS: CVE-2024-21179
VMware Photon OS: CVE-2024-21179 Severity 6 CVSS (AV:N/AC:L/Au:M/C:N/I:N/A:C) Published 07/16/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).Supported versions that are affected are 8.0.37 and prior and8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-21179 CVE - 2024-21179
-
Amazon Linux AMI 2: CVE-2022-48796: Security patch for kernel (ALASKERNEL-5.10-2022-011)
Amazon Linux AMI 2: CVE-2022-48796: Security patch for kernel (ALASKERNEL-5.10-2022-011) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/16/2024 Created 08/03/2024 Added 08/02/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu: Fix potential use-after-free during probe Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free. BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function. 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-5-10-102-99-473 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-2022-48796 AL2/ALASKERNEL-5.10-2022-011 CVE - 2022-48796
-
Amazon Linux AMI 2: CVE-2022-48865: Security patch for kernel (ALASKERNEL-5.10-2022-012)
Amazon Linux AMI 2: CVE-2022-48865: Security patch for kernel (ALASKERNEL-5.10-2022-012) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: tipc: fix kernel panic when enabling bearer When enabling a bearer on a node, a kernel panic is observed: [4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc] ... [4.520030] Call Trace: [4.520689]<IRQ> [4.521236]tipc_link_build_proto_msg+0x375/0x750 [tipc] [4.522654]tipc_link_build_state_msg+0x48/0xc0 [tipc] [4.524034]__tipc_node_link_up+0xd7/0x290 [tipc] [4.525292]tipc_rcv+0x5da/0x730 [tipc] [4.526346]? __netif_receive_skb_core+0xb7/0xfc0 [4.527601]tipc_l2_rcv_msg+0x5e/0x90 [tipc] [4.528737]__netif_receive_skb_list_core+0x20b/0x260 [4.530068]netif_receive_skb_list_internal+0x1bf/0x2e0 [4.531450]? dev_gro_receive+0x4c2/0x680 [4.532512]napi_complete_done+0x6f/0x180 [4.533570]virtnet_poll+0x29c/0x42e [virtio_net] ... The node in question is receiving activate messages in another thread after changing bearer status to allow message sending/ receiving in current thread: thread 1 |thread 2 -------- |-------- | tipc_enable_bearer()| test_and_set_bit_lock() | tipc_bearer_xmit_skb()| | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc();| ... | } | Monitoring pointer in thread 2 is dereferenced before monitoring data is allocated in thread 1. This causes kernel panic. This commit fixes it by allocating the monitoring data before enabling the bearer to receive messages. 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-5-10-106-102-504 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-2022-48865 AL2/ALASKERNEL-5.10-2022-012 CVE - 2022-48865
-
Huawei EulerOS: CVE-2024-6655: gtk3 security update
Huawei EulerOS: CVE-2024-6655: gtk3 security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/16/2024 Created 11/06/2024 Added 11/05/2024 Modified 11/05/2024 Description A flaw was found in the GTK library. Under certain conditions, it is possible for a library to be injected into a GTK application from the current working directory. Solution(s) huawei-euleros-2_0_sp12-upgrade-gtk3 huawei-euleros-2_0_sp12-upgrade-gtk3-devel huawei-euleros-2_0_sp12-upgrade-gtk3-help References https://attackerkb.com/topics/cve-2024-6655 CVE - 2024-6655 EulerOS-SA-2024-2800
-
Amazon Linux AMI 2: CVE-2022-48813: Security patch for kernel (ALASKERNEL-5.10-2022-011)
Amazon Linux AMI 2: CVE-2022-48813: Security patch for kernel (ALASKERNEL-5.10-2022-011) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/16/2024 Created 08/29/2024 Added 08/28/2024 Modified 08/28/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Felix VSC9959 switch is a PCI device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the felix switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The felix driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc_size() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. 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-5-10-102-99-473 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-2022-48813 AL2/ALASKERNEL-5.10-2022-011 CVE - 2022-48813
-
Amazon Linux AMI 2: CVE-2022-48843: Security patch for kernel (Multiple Advisories)
Amazon Linux AMI 2: CVE-2022-48843: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 08/29/2024 Added 08/28/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. 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-5-10-109-104-500 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-2022-48843 AL2/ALASKERNEL-5.10-2022-013 AL2/ALASKERNEL-5.4-2022-024 CVE - 2022-48843
-
Amazon Linux AMI 2: CVE-2022-48815: Security patch for kernel (ALASKERNEL-5.10-2022-011)
Amazon Linux AMI 2: CVE-2022-48815: Security patch for kernel (ALASKERNEL-5.10-2022-011) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 07/16/2024 Created 12/13/2024 Added 12/12/2024 Modified 12/12/2024 Description In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. 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-5-10-102-99-473 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-2022-48815 AL2/ALASKERNEL-5.10-2022-011 CVE - 2022-48815
-
Amazon Linux AMI 2: CVE-2022-48850: Security patch for kernel (Multiple Advisories)
Amazon Linux AMI 2: CVE-2022-48850: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 12/13/2024 Added 12/12/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net-sysfs: add check for netdevice being present to speed_show When bringing down the netdevice or system shutdown, a panic can be triggered while accessing the sysfs path because the device is already removed. [755.549084] mlx5_core 0000:12:00.1: Shutdown was called [756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649TASK: ffff8924108f2100CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acbRSP: ffff89240e1a3968RFLAGS: 00010046 RAX: 0000000000000246RBX: ffff89243d874100RCX: 0000000000001000 RDX: 0000000000000000RSI: 0000000000000246RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4R11: ffffffff8edde9fdR12: 00000000000080d0 R13: ffff89243d874090R14: ffff89243d874080R15: 0000000000000000 ORIG_RAX: ffffffffffffffffCS: 0010SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5(__LINK_STATE_START| __LINK_STATE_NOCARRIER) To prevent this scenario, we also make sure that the netdevice is present. 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-273-207-502 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-106-102-504 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-2022-48850 AL2/ALAS-2022-1768 AL2/ALASKERNEL-5.10-2022-012 AL2/ALASKERNEL-5.4-2022-024 CVE - 2022-48850
-
Amazon Linux AMI 2: CVE-2022-48804: Security patch for kernel (Multiple Advisories)
Amazon Linux AMI 2: CVE-2022-48804: Security patch for kernel (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 07/16/2024 Created 08/20/2024 Added 08/19/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. 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-268-205-500 amazon-linux-ami-2-upgrade-kernel-livepatch-5-10-102-99-473 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-2022-48804 AL2/ALAS-2022-1761 AL2/ALASKERNEL-5.10-2022-011 AL2/ALASKERNEL-5.4-2022-023 CVE - 2022-48804
-
Amazon Linux AMI 2: CVE-2022-48788: Security patch for kernel (Multiple Advisories)
Amazon Linux AMI 2: CVE-2022-48788: Security patch for kernel (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 07/16/2024 Created 08/29/2024 Added 08/28/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. 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-5-10-102-99-473 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-2022-48788 AL2/ALASKERNEL-5.10-2022-011 AL2/ALASKERNEL-5.4-2022-023 CVE - 2022-48788