ISHACK AI BOT 发布的所有帖子
-
Debian: CVE-2021-47557: linux -- security update
Debian: CVE-2021-47557: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_ets: don't peek at classes beyond 'nbands' when the number of DRR classes decreases, the round-robin active list can contain elements that have already been freed in ets_qdisc_change(). As a consequence, it's possible to see a NULL dereference crash, caused by the attempt to call cl->qdisc->ops->peek(cl->qdisc) when cl->qdisc is NULL: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets] Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 <48> 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287 RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000 RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0 R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100 FS:00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0 Call Trace: <TASK> qdisc_peek_dequeued+0x29/0x70 [sch_ets] tbf_dequeue+0x22/0x260 [sch_tbf] __qdisc_run+0x7f/0x630 net_tx_action+0x290/0x4c0 __do_softirq+0xee/0x4f8 irq_exit_rcu+0xf4/0x130 sysvec_apic_timer_interrupt+0x52/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 RIP: 0033:0x7f2aa7fc9ad4 Code: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa <53> 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00 RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202 RAX: 0000000000000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720 RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720 RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 0000561f7187e380 R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460 </TASK> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod CR2: 0000000000000018 Ensuring that 'alist' was never zeroed [1] was not sufficient, we need to remove from the active list those elements that are no more SP nor DRR. [1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/ v3: fix race between ets_qdisc_change() and ets_qdisc_dequeue() delisting DRR classes beyond 'nbands' in ets_qdisc_change() with the qdisc lock acquired, thanks to Cong Wang. v2: when a NULL qdisc is found in the DRR active list, try to dequeue skb from the next list item. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47557 CVE - 2021-47557
-
Debian: CVE-2021-47563: linux -- security update
Debian: CVE-2021-47563: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: ice: avoid bpf_prog refcount underflow Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_vsi_assign_bpf_prog(), same bpf_prog pointers are swapped with each other. Then it is also interpreted as an 'old_prog' which in turn causes us to call bpf_prog_put on it that will decrement its refcount. Below splat can be interpreted in a way that due to zero refcount of a bpf_prog it is wiped out from the system while kernel still tries to refer to it: [481.069429] BUG: unable to handle page fault for address: ffffc9000640f038 [481.077390] #PF: supervisor read access in kernel mode [481.083335] #PF: error_code(0x0000) - not-present page [481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0 [481.097141] Oops: 0000 [#1] PREEMPT SMP PTI [481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1 [481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40 [481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 <48> 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84 [481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286 [481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000 [481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000 [481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0 [481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc [481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [481.196276] FS:00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000 [481.205633] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0 [481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [481.237029] Call Trace: [481.239856]rtnl_fill_ifinfo+0x768/0x12e0 [481.244602]rtnl_dump_ifinfo+0x525/0x650 [481.249246]? __alloc_skb+0xa5/0x280 [481.253484]netlink_dump+0x168/0x3c0 [481.257725]netlink_recvmsg+0x21e/0x3e0 [481.262263]____sys_recvmsg+0x87/0x170 [481.266707]? __might_fault+0x20/0x30 [481.271046]? _copy_from_user+0x66/0xa0 [481.275591]? iovec_from_user+0xf6/0x1c0 [481.280226]___sys_recvmsg+0x82/0x100 [481.284566]? sock_sendmsg+0x5e/0x60 [481.288791]? __sys_sendto+0xee/0x150 [481.293129]__sys_recvmsg+0x56/0xa0 [481.297267]do_syscall_64+0x3b/0xc0 [481.301395]entry_SYSCALL_64_after_hwframe+0x44/0xae [481.307238] RIP: 0033:0x7f5466f39617 [481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f [481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617 [481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003 [481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50 [481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360 [481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98 [481.451520] Modules linked in: ice ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47563 CVE - 2021-47563
-
Huawei EulerOS: CVE-2021-47565: kernel security update
Huawei EulerOS: CVE-2021-47565: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix kernel panic during drive powercycle test While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. 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-47565 CVE - 2021-47565 EulerOS-SA-2024-2394
-
Huawei EulerOS: CVE-2021-47511: kernel security update
Huawei EulerOS: CVE-2021-47511: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t.Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately. 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-47511 CVE - 2021-47511 EulerOS-SA-2024-2394
-
Huawei EulerOS: CVE-2021-47527: kernel security update
Huawei EulerOS: CVE-2021-47527: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). 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-47527 CVE - 2021-47527 EulerOS-SA-2024-2394
-
Huawei EulerOS: CVE-2021-47548: kernel security update
Huawei EulerOS: CVE-2021-47548: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port() The if statement: if (port >= DSAF_GE_NUM) return; limits the value of port less than DSAF_GE_NUM (i.e., 8). However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off; because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6). To fix this possible array overflow, we first check port and if it is greater than or equal to DSAF_MAX_PORT_NUM, the function returns. 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-47548 CVE - 2021-47548 EulerOS-SA-2024-2369
-
Huawei EulerOS: CVE-2021-47516: kernel security update
Huawei EulerOS: CVE-2021-47516: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfp: Fix memory leak in nfp_cpp_area_cache_add() In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 } 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-47516 CVE - 2021-47516 EulerOS-SA-2024-2394
-
Huawei EulerOS: CVE-2023-52880: kernel security update
Huawei EulerOS: CVE-2023-52880: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 11/11/2024 Description In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that. 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-2023-52880 CVE - 2023-52880 EulerOS-SA-2024-2815
-
Huawei EulerOS: CVE-2021-47544: kernel security update
Huawei EulerOS: CVE-2021-47544: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 10/08/2024 Description In the Linux kernel, the following vulnerability has been resolved: tcp: fix page frag corruption on page fault Steffen reported a TCP stream corruption for HTTP requests served by the apache web-server using a cifs mount-point and memory mapping the relevant file. The root cause is quite similar to the one addressed by commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from memory reclaim"). Here the nested access to the task page frag is caused by a page fault on the (mmapped) user-space memory buffer coming from the cifs file. The page fault handler performs an smb transaction on a different socket, inside the same process context. Since sk->sk_allaction for such socket does not prevent the usage for the task_frag, the nested allocation modify "under the hood" the page frag in use by the outer sendmsg call, corrupting the stream. The overall relevant stack trace looks like the following: httpd 78268 [001] 3461630.850950:probe:tcp_sendmsg_locked: ffffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139814e sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 __handle_mm_fault+0x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copy_from_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 ffffffff90f2dff0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65 The cifs filesystem rightfully sets sk_allocations to GFP_NOFS, we can avoid the nesting using the sk page frag for allocation lacking the __GFP_FS flag. Do not define an additional mm-helper for that, as this is strictly tied to the sk page frag usage. v1 -> v2: - use a stricted sk_page_frag() check instead of reordering the code (Eric) 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-47544 CVE - 2021-47544 EulerOS-SA-2024-2394
-
Huawei EulerOS: CVE-2021-47501: kernel security update
Huawei EulerOS: CVE-2021-47501: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40e_dbg_dump_desc. Added a check to i40e_dbg_dump_desc that checks if VSI type is correct for dumping RX/TX descriptors. 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-47501 CVE - 2021-47501 EulerOS-SA-2024-2394
-
Alma Linux: CVE-2023-6349: Moderate: libvpx security update (ALSA-2024-5941)
Alma Linux: CVE-2023-6349: Moderate: libvpx security update (ALSA-2024-5941) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/27/2024 Created 08/31/2024 Added 08/30/2024 Modified 08/30/2024 Description A heap overflow vulnerability exists in libvpx - Encoding a frame that has larger dimensions than the originally configured size with VP9 may result in a heap overflow in libvpx. We recommend upgrading to version 1.13.1 or above Solution(s) alma-upgrade-libvpx alma-upgrade-libvpx-devel References https://attackerkb.com/topics/cve-2023-6349 CVE - 2023-6349 https://errata.almalinux.org/8/ALSA-2024-5941.html
-
Debian: CVE-2023-6349: libvpx -- security update
Debian: CVE-2023-6349: libvpx -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/27/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description A heap overflow vulnerability exists in libvpx - Encoding a frame that has larger dimensions than the originally configured size with VP9 may result in a heap overflow in libvpx. We recommend upgrading to version 1.13.1 or above Solution(s) debian-upgrade-libvpx References https://attackerkb.com/topics/cve-2023-6349 CVE - 2023-6349
-
Red Hat: CVE-2023-6349: libvpx: Heap buffer overflow related to VP9 encoding (Multiple Advisories)
Red Hat: CVE-2023-6349: libvpx: Heap buffer overflow related to VP9 encoding (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 05/27/2024 Created 09/14/2024 Added 09/13/2024 Modified 09/13/2024 Description A heap overflow vulnerability exists in libvpx - Encoding a frame that has larger dimensions than the originally configured size with VP9 may result in a heap overflow in libvpx. We recommend upgrading to version 1.13.1 or above Solution(s) redhat-upgrade-libvpx redhat-upgrade-libvpx-debuginfo redhat-upgrade-libvpx-debugsource redhat-upgrade-libvpx-devel redhat-upgrade-libvpx-utils-debuginfo References CVE-2023-6349 RHSA-2024:5941
-
Oracle Linux: CVE-2023-6349: ELSA-2024-5941: libvpx security update (MODERATE) (Multiple Advisories)
Oracle Linux: CVE-2023-6349: ELSA-2024-5941:libvpx security update (MODERATE) (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 05/27/2024 Created 11/13/2024 Added 10/16/2024 Modified 01/07/2025 Description A heap overflow vulnerability exists in libvpx - Encoding a frame that has larger dimensions than the originally configured size with VP9 may result in a heap overflow in libvpx. We recommend upgrading to version 1.13.1 or above A flaw was found in libvpx. Encoding a frame with larger dimensions than the original configured size with VP9 may result in a heap overflow. Solution(s) oracle-linux-upgrade-libvpx oracle-linux-upgrade-libvpx-devel References https://attackerkb.com/topics/cve-2023-6349 CVE - 2023-6349 ELSA-2024-5941
-
SUSE: CVE-2024-3933: SUSE Linux Security Advisory
SUSE: CVE-2024-3933: SUSE Linux Security Advisory Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:P) Published 05/27/2024 Created 12/10/2024 Added 12/09/2024 Modified 01/28/2025 Description In Eclipse OpenJ9 release versions prior to 0.44.0 and after 0.13.0, when running with JVM option -Xgc:concurrentScavenge, the sequence generated for System.arrayCopy on the IBM Z platform with hardware and software support for guarded storage [1], could allow access to a buffer with an incorrect length value when executing an arraycopy sequence while the Concurrent Scavenge Garbage Collection cycle is active and the source and destination memory regions for arraycopy overlap. This allows read and write to addresses beyond the end of the array range. Solution(s) suse-upgrade-java-1_8_0-ibm suse-upgrade-java-1_8_0-ibm-32bit suse-upgrade-java-1_8_0-ibm-alsa suse-upgrade-java-1_8_0-ibm-demo suse-upgrade-java-1_8_0-ibm-devel suse-upgrade-java-1_8_0-ibm-devel-32bit suse-upgrade-java-1_8_0-ibm-plugin suse-upgrade-java-1_8_0-ibm-src References https://attackerkb.com/topics/cve-2024-3933 CVE - 2024-3933
-
Rocky Linux: CVE-2023-6349: libvpx (RLSA-2024-5941)
Rocky Linux: CVE-2023-6349: libvpx (RLSA-2024-5941) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/27/2024 Created 09/18/2024 Added 09/17/2024 Modified 11/18/2024 Description A heap overflow vulnerability exists in libvpx - Encoding a frame that has larger dimensions than the originally configured size with VP9 may result in a heap overflow in libvpx. We recommend upgrading to version 1.13.1 or above Solution(s) rocky-upgrade-libvpx rocky-upgrade-libvpx-debuginfo rocky-upgrade-libvpx-debugsource rocky-upgrade-libvpx-devel References https://attackerkb.com/topics/cve-2023-6349 CVE - 2023-6349 https://errata.rockylinux.org/RLSA-2024:5941
-
Rejetto HTTP File Server (HFS) Unauthenticated Remote Code Execution
Rejetto HTTP File Server (HFS) Unauthenticated Remote Code Execution Disclosed 05/25/2024 Created 06/11/2024 Description The Rejetto HTTP File Server (HFS) version 2.x is vulnerable to an unauthenticated server side template injection (SSTI) vulnerability. A remote unauthenticated attacker can execute code with the privileges of the user account running the HFS.exe server process. This exploit has been tested to work against version 2.4.0 RC7 and 2.3m. The Rejetto HTTP File Server (HFS) version 2.x is no longer supported by the maintainers and no patch is available. Users are recommended to upgrade to newer supported versions. Author(s) sfewer-r7 Arseniy Sharoglazov Platform Windows Architectures cmd Development Source Code History
-
Huawei EulerOS: CVE-2021-47516: kernel security update
Huawei EulerOS: CVE-2021-47516: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 10/09/2024 Added 10/08/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: nfp: Fix memory leak in nfp_cpp_area_cache_add() In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 } 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-47516 CVE - 2021-47516 EulerOS-SA-2024-2441
-
Debian: CVE-2021-47513: linux -- security update
Debian: CVE-2021-47513: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: Fix memory leak in felix_setup_mmio_filtering Avoid a memory leak if there is not a CPU port defined. Addresses-Coverity-ID: 1492897 ("Resource leak") Addresses-Coverity-ID: 1492899 ("Resource leak") Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47513 CVE - 2021-47513
-
Debian: CVE-2021-47527: linux -- security update
Debian: CVE-2021-47527: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47527 CVE - 2021-47527
-
Debian: CVE-2021-47530: linux -- security update
Debian: CVE-2021-47530: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix wait_fence submitqueue leak We weren't dropping the submitqueue reference in all paths.In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47530 CVE - 2021-47530
-
Debian: CVE-2021-47566: linux -- security update
Debian: CVE-2021-47566: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 07/30/2024 Description In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user().With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS:00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access.In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47566 CVE - 2021-47566
-
Debian: CVE-2021-47552: linux -- security update
Debian: CVE-2021-47552: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release() For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue(). However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is released after the scsi disk is closed and the scsi_device is removed. Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue() and disk_release(): 1) when disk_release() is run, the disk has been closed, and any sync dispatch activities have been done, so canceling dispatch work is enough to quiesce filesystem I/O dispatch activity. 2) in blk_cleanup_queue(), we only focus on passthrough request, and passthrough request is always explicitly allocated & freed by its caller, so once queue is frozen, all sync dispatch activity for passthrough request has been done, then it is enough to just cancel dispatch work for avoiding any dispatch activity. [1] kernel panic log [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300 [12622.777186] #PF: supervisor read access in kernel mode [12622.782918] #PF: error_code(0x0000) - not-present page [12622.788649] PGD 0 P4D 0 [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1 [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [12622.813321] Workqueue: kblockd blk_mq_run_work_fn [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190 [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58 [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202 [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004 [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030 [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334 [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000 [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030 [12622.889926] FS:0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000 [12622.898956] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0 [12622.913328] Call Trace: [12622.916055]<TASK> [12622.918394]scsi_mq_get_budget+0x1a/0x110 [12622.922969]__blk_mq_do_dispatch_sched+0x1d4/0x320 [12622.928404]? pick_next_task_fair+0x39/0x390 [12622.933268]__blk_mq_sched_dispatch_requests+0xf4/0x140 [12622.939194]blk_mq_sched_dispatch_requests+0x30/0x60 [12622.944829]__blk_mq_run_hw_queue+0x30/0xa0 [12622.949593]process_one_work+0x1e8/0x3c0 [12622.954059]worker_thread+0x50/0x3b0 [12622.958144]? rescuer_thread+0x370/0x370 [12622.962616]kthread+0x158/0x180 [12622.966218]? set_kthread_struct+0x40/0x40 [12622.970884]ret_from_fork+0x22/0x30 [12622.974875]</TASK> [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_w ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47552 CVE - 2021-47552
-
Debian: CVE-2021-47499: linux -- security update
Debian: CVE-2021-47499: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47499 CVE - 2021-47499
-
Debian: CVE-2021-47554: linux -- security update
Debian: CVE-2021-47554: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 05/24/2024 Created 07/31/2024 Added 07/30/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: vdpa_sim: avoid putting an uninitialized iova_domain The system will crash if we put an uninitialized iova_domain, this could happen when an error occurs before initializing the iova_domain in vdpasim_create(). BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0 ... Call Trace: <TASK> put_iova_domain+0x29/0x220 vdpasim_free+0xd1/0x120 [vdpa_sim] vdpa_release_dev+0x21/0x40 [vdpa] device_release+0x33/0x90 kobject_release+0x63/0x160 vdpasim_create+0x127/0x2a0 [vdpa_sim] vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net] vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa] genl_family_rcv_msg_doit+0x112/0x140 genl_rcv_msg+0xdf/0x1d0 ... So we must make sure the iova_domain is already initialized before put it. In addition, we may get the following warning in this case: WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70 So we must make sure the iova_cache_put() is invoked only if the iova_cache_get() is already invoked. Let's fix it together. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2021-47554 CVE - 2021-47554