ISHACK AI BOT

Debian: CVE-2021-46996: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: Fix a memleak from userdata error path in new objects Release object name if userdata allocation fails. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46996 CVE - 2021-46996

Debian: CVE-2021-46976: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix crash in auto_retire The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this: 2021-04-24T18:03:53.804300Z WARNING kernel: [516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [516.876926] FS:0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [516.876928] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [516.876935]__active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [516.876939]process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [516.876941]worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [516.876944]kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [516.876946]? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [516.876948]? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [516.876950]ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-46976 CVE - 2021-46976

Debian: CVE-2021-47000: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47000 CVE - 2021-47000

Ubuntu: (CVE-2021-47034): linux vulnerability Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP:c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR:9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>CR: 44002884XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/[email protected]/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [<c000000000bf8e5c>] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O5.10.0-rc5-01360-gf878ccaf250a #1 NIP:c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR:900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>CR: 28008848XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LRftrace_bug+0x288/0x2e8 Call T ---truncated--- Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47034 CVE - 2021-47034 https://git.kernel.org/linus/b8b2f37cf632434456182e9002d63cbc4cccc50c https://git.kernel.org/stable/c/01ac203e2119d8922126886ddea309fb676f955f https://git.kernel.org/stable/c/73f9dccb29e4f82574bec2765c0090cdb0404301 https://git.kernel.org/stable/c/84c0762633f2a7ac8399e6b97d3b9bb8e6e1d50f https://git.kernel.org/stable/c/b3d5d0983388d6c4fb35f7d722556d5595f167a7 https://git.kernel.org/stable/c/b8b2f37cf632434456182e9002d63cbc4cccc50c https://git.kernel.org/stable/c/e40c52ee67b155ad59f59e73ea136d02685f0e0d https://www.cve.org/CVERecord?id=CVE-2021-47034 View more

Ubuntu: (Multiple Advisories) (CVE-2021-47001): Linux kernel vulnerabilities Severity 4 CVSS (AV:L/AC:M/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 12/19/2024 Added 12/18/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv(). Solution(s) ubuntu-upgrade-linux-image-5-4-0-1056-xilinx-zynqmp ubuntu-upgrade-linux-image-5-4-0-1084-ibm ubuntu-upgrade-linux-image-5-4-0-1097-bluefield ubuntu-upgrade-linux-image-5-4-0-1121-raspi ubuntu-upgrade-linux-image-5-4-0-1125-kvm ubuntu-upgrade-linux-image-5-4-0-1136-oracle ubuntu-upgrade-linux-image-5-4-0-1137-aws ubuntu-upgrade-linux-image-5-4-0-1141-gcp ubuntu-upgrade-linux-image-5-4-0-1142-azure ubuntu-upgrade-linux-image-5-4-0-204-generic ubuntu-upgrade-linux-image-5-4-0-204-generic-lpae ubuntu-upgrade-linux-image-5-4-0-204-lowlatency ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-20-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-lts-20-04 ubuntu-upgrade-linux-image-bluefield ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-20-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-hwe-18-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-ibm-lts-20-04 ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-hwe-18-04 ubuntu-upgrade-linux-image-oem ubuntu-upgrade-linux-image-oem-osp1 ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-lts-20-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-hwe-18-04 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-xilinx-zynqmp References https://attackerkb.com/topics/cve-2021-47001 CVE - 2021-47001 USN-7173-1 USN-7173-2 USN-7173-3 USN-7195-1 USN-7195-2

Ubuntu: (CVE-2021-47013): linux vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-47013 CVE - 2021-47013 https://git.kernel.org/linus/6d72e7c767acbbdd44ebc7d89c6690b405b32b57 https://git.kernel.org/stable/c/16d8c44be52e3650917736d45f5904384a9da834 https://git.kernel.org/stable/c/55fcdd1258faaecca74b91b88cc0921f9edd775d https://git.kernel.org/stable/c/6d72e7c767acbbdd44ebc7d89c6690b405b32b57 https://git.kernel.org/stable/c/8c06f34785068b87e2b560534c77c163d6c6dca7 https://git.kernel.org/stable/c/9dc373f74097edd0e35f3393d6248eda8d1ba99d https://git.kernel.org/stable/c/c7f75d11fe72913d2619f97b2334b083cd7bb955 https://git.kernel.org/stable/c/dc1b438a35773d030be0ee80d9c635c3e558a322 https://git.kernel.org/stable/c/e407495ba6788a67d1bd41714158c079e340879b https://www.cve.org/CVERecord?id=CVE-2021-47013 View more

Ubuntu: (CVE-2021-47014): linux-bluefield vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix wild memory access when clearing fragments while testing re-assembly/re-fragmentation using act_ct, it's possible to observe a crash like the following one: KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS:0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> inet_frag_destroy+0xa9/0x150 call_timer_fn+0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAG_CB(), and this causes those "wild" memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcf_ct_handle_fragments() returns -EINPROGRESS. Solution(s) ubuntu-upgrade-linux-bluefield References https://attackerkb.com/topics/cve-2021-47014 CVE - 2021-47014 https://git.kernel.org/linus/f77bd544a6bbe69aa50d9ed09f13494cf36ff806 https://git.kernel.org/stable/c/0648941f4c8bbf8b4b6c0b270889ae7aa769b921 https://git.kernel.org/stable/c/f77bd544a6bbe69aa50d9ed09f13494cf36ff806 https://www.cve.org/CVERecord?id=CVE-2021-47014

Ubuntu: (CVE-2021-46998): linux vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 References https://attackerkb.com/topics/cve-2021-46998 CVE - 2021-46998 https://git.kernel.org/linus/643001b47adc844ae33510c4bb93c236667008a3 https://git.kernel.org/stable/c/25a87b1f566b5eb2af2857a928f0e2310d900976 https://git.kernel.org/stable/c/643001b47adc844ae33510c4bb93c236667008a3 https://git.kernel.org/stable/c/6892396ebf04ea2c021d80e10f4075e014cd7cc3 https://git.kernel.org/stable/c/7afdd6aba95c8a526038e7abe283eeac3e4320f1 https://git.kernel.org/stable/c/d90529392aaf498dafa95d212295d64b2cea4e24 https://git.kernel.org/stable/c/f7f6f07774091a6ddd98500b85386c3c6afb30d3 https://www.cve.org/CVERecord?id=CVE-2021-46998 View more

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

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

Huawei EulerOS: CVE-2021-46998: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/17/2024 Added 07/17/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Solution(s) huawei-euleros-2_0_sp9-upgrade-kernel huawei-euleros-2_0_sp9-upgrade-kernel-tools huawei-euleros-2_0_sp9-upgrade-kernel-tools-libs huawei-euleros-2_0_sp9-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-46998 CVE - 2021-46998 EulerOS-SA-2024-1964

Oracle Linux: CVE-2021-47018: ELSA-2024-5101:kernel security update (IMPORTANT) (Multiple Advisories) Severity 1 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:P) Published 02/28/2024 Created 11/13/2024 Added 10/16/2024 Modified 11/29/2024 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. A flaw was found in the Linux kernel. The fixmap area that was defined for the PPC64 architecture was invalid. Solution(s) oracle-linux-upgrade-kernel References https://attackerkb.com/topics/cve-2021-47018 CVE - 2021-47018 ELSA-2024-5101

Huawei EulerOS: CVE-2021-47041: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 05/10/2024 Added 05/13/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: GI -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs lastenabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs lastenabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: GI 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-47041 CVE - 2021-47041 EulerOS-SA-2024-1592

Huawei EulerOS: CVE-2021-46998: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/16/2024 Added 07/16/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-46998 CVE - 2021-46998 EulerOS-SA-2024-1911

Amazon Linux 2023: CVE-2024-26458: Medium priority package update for krb5 Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 02/28/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. A memory leak flaw was found in krb5 in /krb5/src/lib/rpc/pmap_rmt.c. This issue can lead to a denial of service through memory exhaustion. Solution(s) amazon-linux-2023-upgrade-krb5-debuginfo amazon-linux-2023-upgrade-krb5-debugsource amazon-linux-2023-upgrade-krb5-devel amazon-linux-2023-upgrade-krb5-libs amazon-linux-2023-upgrade-krb5-libs-debuginfo amazon-linux-2023-upgrade-krb5-pkinit amazon-linux-2023-upgrade-krb5-pkinit-debuginfo amazon-linux-2023-upgrade-krb5-server amazon-linux-2023-upgrade-krb5-server-debuginfo amazon-linux-2023-upgrade-krb5-server-ldap amazon-linux-2023-upgrade-krb5-server-ldap-debuginfo amazon-linux-2023-upgrade-krb5-workstation amazon-linux-2023-upgrade-krb5-workstation-debuginfo amazon-linux-2023-upgrade-libkadm5 amazon-linux-2023-upgrade-libkadm5-debuginfo References https://attackerkb.com/topics/cve-2024-26458 CVE - 2024-26458 https://alas.aws.amazon.com/AL2023/ALAS-2024-586.html

Amazon Linux 2023: CVE-2024-26461: Medium priority package update for krb5 Severity 5 CVSS (AV:N/AC:H/Au:N/C:N/I:N/A:C) Published 02/28/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c. A memory leak flaw was found in krb5 in /krb5/src/lib/gssapi/krb5/k5sealv3.c. This issue can lead to a denial of service through memory exhaustion. Solution(s) amazon-linux-2023-upgrade-krb5-debuginfo amazon-linux-2023-upgrade-krb5-debugsource amazon-linux-2023-upgrade-krb5-devel amazon-linux-2023-upgrade-krb5-libs amazon-linux-2023-upgrade-krb5-libs-debuginfo amazon-linux-2023-upgrade-krb5-pkinit amazon-linux-2023-upgrade-krb5-pkinit-debuginfo amazon-linux-2023-upgrade-krb5-server amazon-linux-2023-upgrade-krb5-server-debuginfo amazon-linux-2023-upgrade-krb5-server-ldap amazon-linux-2023-upgrade-krb5-server-ldap-debuginfo amazon-linux-2023-upgrade-krb5-workstation amazon-linux-2023-upgrade-krb5-workstation-debuginfo amazon-linux-2023-upgrade-libkadm5 amazon-linux-2023-upgrade-libkadm5-debuginfo References https://attackerkb.com/topics/cve-2024-26461 CVE - 2024-26461 https://alas.aws.amazon.com/AL2023/ALAS-2024-586.html

Huawei EulerOS: CVE-2021-46984: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 07/16/2024 Added 07/16/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2021-46984 CVE - 2021-46984 EulerOS-SA-2024-1911

Amazon Linux 2023: CVE-2024-26462: Medium priority package update for krb5 Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 02/28/2024 Created 02/14/2025 Added 02/14/2025 Modified 02/14/2025 Description Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c. A memory leak flaw was found in krb5 in /krb5/src/kdc/ndr.c. This issue can lead to a denial of service through memory exhaustion. Solution(s) amazon-linux-2023-upgrade-krb5-debuginfo amazon-linux-2023-upgrade-krb5-debugsource amazon-linux-2023-upgrade-krb5-devel amazon-linux-2023-upgrade-krb5-libs amazon-linux-2023-upgrade-krb5-libs-debuginfo amazon-linux-2023-upgrade-krb5-pkinit amazon-linux-2023-upgrade-krb5-pkinit-debuginfo amazon-linux-2023-upgrade-krb5-server amazon-linux-2023-upgrade-krb5-server-debuginfo amazon-linux-2023-upgrade-krb5-server-ldap amazon-linux-2023-upgrade-krb5-server-ldap-debuginfo amazon-linux-2023-upgrade-krb5-workstation amazon-linux-2023-upgrade-krb5-workstation-debuginfo amazon-linux-2023-upgrade-libkadm5 amazon-linux-2023-upgrade-libkadm5-debuginfo References https://attackerkb.com/topics/cve-2024-26462 CVE - 2024-26462 https://alas.aws.amazon.com/AL2023/ALAS-2024-586.html

Red Hat: CVE-2023-6917: pcp: unsafe use of directories allows pcp to root privilege escalation (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:M/C:C/I:C/A:N) Published 02/28/2024 Created 05/01/2024 Added 05/01/2024 Modified 09/03/2024 Description A vulnerability has been identified in the Performance Co-Pilot (PCP) package, stemming from the mixed privilege levels utilized by systemd services associated with PCP. While certain services operate within the confines of limited PCP user/group privileges, others are granted full root privileges. This disparity in privilege levels poses a risk when privileged root processes interact with directories or directory trees owned by unprivileged PCP users. Specifically, this vulnerability may lead to the compromise of PCP user isolation and facilitate local PCP-to-root exploits, particularly through symlink attacks. These vulnerabilities underscore the importance of maintaining robust privilege separation mechanisms within PCP to mitigate the potential for unauthorized privilege escalation. Solution(s) redhat-upgrade-pcp redhat-upgrade-pcp-conf redhat-upgrade-pcp-debuginfo redhat-upgrade-pcp-debugsource redhat-upgrade-pcp-devel redhat-upgrade-pcp-devel-debuginfo redhat-upgrade-pcp-doc redhat-upgrade-pcp-export-pcp2elasticsearch redhat-upgrade-pcp-export-pcp2graphite redhat-upgrade-pcp-export-pcp2influxdb redhat-upgrade-pcp-export-pcp2json redhat-upgrade-pcp-export-pcp2spark redhat-upgrade-pcp-export-pcp2xml redhat-upgrade-pcp-export-pcp2zabbix redhat-upgrade-pcp-export-zabbix-agent redhat-upgrade-pcp-export-zabbix-agent-debuginfo redhat-upgrade-pcp-geolocate redhat-upgrade-pcp-gui redhat-upgrade-pcp-gui-debuginfo redhat-upgrade-pcp-import-collectl2pcp redhat-upgrade-pcp-import-collectl2pcp-debuginfo redhat-upgrade-pcp-import-ganglia2pcp redhat-upgrade-pcp-import-iostat2pcp redhat-upgrade-pcp-import-mrtg2pcp redhat-upgrade-pcp-import-sar2pcp redhat-upgrade-pcp-libs redhat-upgrade-pcp-libs-debuginfo redhat-upgrade-pcp-libs-devel redhat-upgrade-pcp-pmda-activemq redhat-upgrade-pcp-pmda-apache redhat-upgrade-pcp-pmda-apache-debuginfo redhat-upgrade-pcp-pmda-bash redhat-upgrade-pcp-pmda-bash-debuginfo redhat-upgrade-pcp-pmda-bcc redhat-upgrade-pcp-pmda-bind2 redhat-upgrade-pcp-pmda-bonding redhat-upgrade-pcp-pmda-bpf redhat-upgrade-pcp-pmda-bpf-debuginfo redhat-upgrade-pcp-pmda-bpftrace redhat-upgrade-pcp-pmda-cifs redhat-upgrade-pcp-pmda-cifs-debuginfo redhat-upgrade-pcp-pmda-cisco redhat-upgrade-pcp-pmda-cisco-debuginfo redhat-upgrade-pcp-pmda-dbping redhat-upgrade-pcp-pmda-denki redhat-upgrade-pcp-pmda-denki-debuginfo redhat-upgrade-pcp-pmda-dm redhat-upgrade-pcp-pmda-dm-debuginfo redhat-upgrade-pcp-pmda-docker redhat-upgrade-pcp-pmda-docker-debuginfo redhat-upgrade-pcp-pmda-ds389 redhat-upgrade-pcp-pmda-ds389log redhat-upgrade-pcp-pmda-elasticsearch redhat-upgrade-pcp-pmda-farm redhat-upgrade-pcp-pmda-farm-debuginfo redhat-upgrade-pcp-pmda-gfs2 redhat-upgrade-pcp-pmda-gfs2-debuginfo redhat-upgrade-pcp-pmda-gluster redhat-upgrade-pcp-pmda-gpfs redhat-upgrade-pcp-pmda-gpsd redhat-upgrade-pcp-pmda-hacluster redhat-upgrade-pcp-pmda-hacluster-debuginfo redhat-upgrade-pcp-pmda-haproxy redhat-upgrade-pcp-pmda-infiniband redhat-upgrade-pcp-pmda-infiniband-debuginfo redhat-upgrade-pcp-pmda-json redhat-upgrade-pcp-pmda-libvirt redhat-upgrade-pcp-pmda-lio redhat-upgrade-pcp-pmda-lmsensors redhat-upgrade-pcp-pmda-logger redhat-upgrade-pcp-pmda-logger-debuginfo redhat-upgrade-pcp-pmda-lustre redhat-upgrade-pcp-pmda-lustrecomm redhat-upgrade-pcp-pmda-lustrecomm-debuginfo redhat-upgrade-pcp-pmda-mailq redhat-upgrade-pcp-pmda-mailq-debuginfo redhat-upgrade-pcp-pmda-memcache redhat-upgrade-pcp-pmda-mic redhat-upgrade-pcp-pmda-mongodb redhat-upgrade-pcp-pmda-mounts redhat-upgrade-pcp-pmda-mounts-debuginfo redhat-upgrade-pcp-pmda-mssql redhat-upgrade-pcp-pmda-mysql redhat-upgrade-pcp-pmda-named redhat-upgrade-pcp-pmda-netcheck redhat-upgrade-pcp-pmda-netfilter redhat-upgrade-pcp-pmda-news redhat-upgrade-pcp-pmda-nfsclient redhat-upgrade-pcp-pmda-nginx redhat-upgrade-pcp-pmda-nvidia-gpu redhat-upgrade-pcp-pmda-nvidia-gpu-debuginfo redhat-upgrade-pcp-pmda-openmetrics redhat-upgrade-pcp-pmda-openvswitch redhat-upgrade-pcp-pmda-oracle redhat-upgrade-pcp-pmda-pdns redhat-upgrade-pcp-pmda-perfevent redhat-upgrade-pcp-pmda-perfevent-debuginfo redhat-upgrade-pcp-pmda-podman redhat-upgrade-pcp-pmda-podman-debuginfo redhat-upgrade-pcp-pmda-postfix redhat-upgrade-pcp-pmda-postgresql redhat-upgrade-pcp-pmda-rabbitmq redhat-upgrade-pcp-pmda-redis redhat-upgrade-pcp-pmda-resctrl redhat-upgrade-pcp-pmda-resctrl-debuginfo redhat-upgrade-pcp-pmda-roomtemp redhat-upgrade-pcp-pmda-roomtemp-debuginfo redhat-upgrade-pcp-pmda-rsyslog redhat-upgrade-pcp-pmda-samba redhat-upgrade-pcp-pmda-sendmail redhat-upgrade-pcp-pmda-sendmail-debuginfo redhat-upgrade-pcp-pmda-shping redhat-upgrade-pcp-pmda-shping-debuginfo redhat-upgrade-pcp-pmda-slurm redhat-upgrade-pcp-pmda-smart redhat-upgrade-pcp-pmda-smart-debuginfo redhat-upgrade-pcp-pmda-snmp redhat-upgrade-pcp-pmda-sockets redhat-upgrade-pcp-pmda-sockets-debuginfo redhat-upgrade-pcp-pmda-statsd redhat-upgrade-pcp-pmda-statsd-debuginfo redhat-upgrade-pcp-pmda-summary redhat-upgrade-pcp-pmda-summary-debuginfo redhat-upgrade-pcp-pmda-systemd redhat-upgrade-pcp-pmda-systemd-debuginfo redhat-upgrade-pcp-pmda-trace redhat-upgrade-pcp-pmda-trace-debuginfo redhat-upgrade-pcp-pmda-unbound redhat-upgrade-pcp-pmda-weblog redhat-upgrade-pcp-pmda-weblog-debuginfo redhat-upgrade-pcp-pmda-zimbra redhat-upgrade-pcp-pmda-zimbra-debuginfo redhat-upgrade-pcp-pmda-zswap redhat-upgrade-pcp-selinux redhat-upgrade-pcp-system-tools redhat-upgrade-pcp-system-tools-debuginfo redhat-upgrade-pcp-testsuite redhat-upgrade-pcp-testsuite-debuginfo redhat-upgrade-pcp-zeroconf redhat-upgrade-perl-pcp-logimport redhat-upgrade-perl-pcp-logimport-debuginfo redhat-upgrade-perl-pcp-logsummary redhat-upgrade-perl-pcp-mmv redhat-upgrade-perl-pcp-mmv-debuginfo redhat-upgrade-perl-pcp-pmda redhat-upgrade-perl-pcp-pmda-debuginfo redhat-upgrade-python3-pcp redhat-upgrade-python3-pcp-debuginfo References CVE-2023-6917 RHSA-2024:2213

Huawei EulerOS: CVE-2024-21886: xorg-x11-server security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 02/28/2024 Created 04/10/2024 Added 04/09/2024 Modified 10/09/2024 Description A heap buffer overflow flaw was found in the DisableDevice function in the X.Org server. This issue may lead to an application crash or, in some circumstances, remote code execution in SSH X11 forwarding environments. Solution(s) huawei-euleros-2_0_sp9-upgrade-xorg-x11-server-help References https://attackerkb.com/topics/cve-2024-21886 CVE - 2024-21886 EulerOS-SA-2024-1522

SUSE: CVE-2021-47014: SUSE Linux Security Advisory Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 08/16/2024 Added 08/09/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix wild memory access when clearing fragments while testing re-assembly/re-fragmentation using act_ct, it's possible to observe a crash like the following one: KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS:0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> inet_frag_destroy+0xa9/0x150 call_timer_fn+0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAG_CB(), and this causes those "wild" memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcf_ct_handle_fragments() returns -EINPROGRESS. Solution(s) suse-upgrade-kernel-64kb suse-upgrade-kernel-64kb-devel suse-upgrade-kernel-default suse-upgrade-kernel-default-base suse-upgrade-kernel-default-devel suse-upgrade-kernel-devel suse-upgrade-kernel-docs suse-upgrade-kernel-macros suse-upgrade-kernel-obs-build suse-upgrade-kernel-preempt suse-upgrade-kernel-preempt-devel suse-upgrade-kernel-source suse-upgrade-kernel-syms suse-upgrade-kernel-zfcpdump suse-upgrade-reiserfs-kmp-default References https://attackerkb.com/topics/cve-2021-47014 CVE - 2021-47014

Amazon Linux AMI 2: CVE-2021-47013: Security patch for kernel (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 02/28/2024 Created 05/28/2024 Added 05/28/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later. Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-4-14-238-182-421 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-47013 AL2/ALAS-2021-1685 AL2/ALASKERNEL-5.10-2022-002 AL2/ALASKERNEL-5.4-2022-004 CVE - 2021-47013

Amazon Linux AMI 2: CVE-2021-47035: Security patch for kernel (ALASKERNEL-5.10-2022-002) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 05/28/2024 Added 05/28/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2021-47035 AL2/ALASKERNEL-5.10-2022-002 CVE - 2021-47035

Debian: CVE-2020-36786: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: [next] staging: media: atomisp: fix memory leak of object flash In the case where the call to lm3554_platform_data_func returns an error there is a memory leak on the error return path of object flash.Fix this by adding an error return path that will free flash and rename labels fail2 to fail3 and fail1 to fail2. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36786 CVE - 2020-36786

Debian: CVE-2020-36778: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 02/28/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in xiic_xfer and xiic_i2c_remove. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2020-36778 CVE - 2020-36778