Total
28 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-36737 | 1 Oneflow | 1 Oneflow | 2025-02-13 | 7.5 High |
| Improper input validation in OneFlow-Inc. Oneflow v0.9.1 allows attackers to cause a Denial of Service (DoS) via inputting a negative value into the oneflow.full parameter. | ||||
| CVE-2024-0607 | 3 Fedoraproject, Linux, Redhat | 3 Fedora, Linux Kernel, Enterprise Linux | 2025-02-07 | 6.6 Medium |
| A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality. | ||||
| CVE-2024-26773 | 1 Redhat | 5 Enterprise Linux, Rhel Aus, Rhel E4s and 2 more | 2024-12-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group | ||||
| CVE-2024-26772 | 1 Redhat | 5 Enterprise Linux, Rhel Aus, Rhel E4s and 2 more | 2024-12-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap. | ||||
| CVE-2022-48652 | 2024-12-19 | 6.1 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: ice: Fix crash by keep old cfg when update TCs more than queues There are problems if allocated queues less than Traffic Classes. Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs. Another case is if we first set less queues, and later update more TCs config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access. [ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice] [ 95.971774] ice_vsi_open+0x25/0x120 [ice] [ 95.971843] ice_open_internal+0xb8/0x1f0 [ice] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice] [ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280 [ 95.972591] ? rtnl_calcit.isra.31+0x100/0x100 [ 95.972661] netlink_rcv_skb+0xcf/0xf0 [ 95.972720] netlink_unicast+0x16d/0x220 [ 95.972781] netlink_sendmsg+0x2ba/0x3a0 [ 95.975891] sock_sendmsg+0x4c/0x50 [ 95.979032] ___sys_sendmsg+0x2e4/0x300 [ 95.982147] ? kmem_cache_alloc+0x13e/0x190 [ 95.985242] ? __wake_up_common_lock+0x79/0x90 [ 95.988338] ? __check_object_size+0xac/0x1b0 [ 95.991440] ? _copy_to_user+0x22/0x30 [ 95.994539] ? move_addr_to_user+0xbb/0xd0 [ 95.997619] ? __sys_sendmsg+0x53/0x80 [ 96.000664] __sys_sendmsg+0x53/0x80 [ 96.003747] do_syscall_64+0x5b/0x1d0 [ 96.006862] entry_SYSCALL_64_after_hwframe+0x65/0xca Only update num_txq/rxq when passed check, and restore tc_cfg if setup queue map failed. | ||||
| CVE-2021-46989 | 2024-12-19 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: hfsplus: prevent corruption in shrinking truncate I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation") HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check. | ||||
| CVE-2024-39531 | 1 Juniper | 1 Junos Os Evolved | 2024-11-21 | 7.5 High |
| An Improper Handling of Values vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved on ACX 7000 Series allows a network-based, unauthenticated attacker to cause a Denial-of-Service (DoS). If a value is configured for DDoS bandwidth or burst parameters for any protocol in a queue, all protocols which share the same queue will have their bandwidth or burst value changed to the new value. If, for example, OSPF was configured with a certain bandwidth value, ISIS would also be limited to this value. So inadvertently either the control plane is open for a high level of specific traffic which was supposed to be limited to a lower value, or the limit for a certain protocol is so low that chances to succeed with a volumetric DoS attack are significantly increased. This issue affects Junos OS Evolved on ACX 7000 Series: * All versions before 21.4R3-S7-EVO, * 22.1 versions before 22.1R3-S6-EVO, * 22.2 versions before 22.2R3-S3-EVO, * 22.3 versions before 22.3R3-S3-EVO, * 22.4 versions before 22.4R3-S2-EVO, * 23.2 versions before 23.2R2-EVO, * 23.4 versions before 23.4R1-S1-EVO, 23.4R2-EVO. | ||||
| CVE-2024-30917 | 1 Eprosima | 1 Fast Dds | 2024-11-21 | 5.5 Medium |
| An issue was discovered in eProsima FastDDS v.2.14.0 and before, allows a local attacker to cause a denial of service (DoS) and obtain sensitive information via a crafted history_depth parameter in DurabilityService QoS component. | ||||
| CVE-2024-30800 | 2024-11-21 | 5.6 Medium | ||
| PX4 Autopilot v.1.14 allows an attacker to fly the drone into no-fly zones by breaching the geofence using flaws in the function. | ||||
| CVE-2024-29460 | 1 Dronecode | 1 Px4 Drone Autopilot | 2024-11-21 | 6.6 Medium |
| An issue in PX4 Autopilot v.1.14.0 allows an attacker to manipulate the flight path allowing for crashes of the drone via the home point location of the mission_block.cpp component. | ||||
| CVE-2022-4851 | 1 Usememos | 1 Memos | 2024-11-21 | 5.3 Medium |
| Improper Handling of Values in GitHub repository usememos/memos prior to 0.9.1. | ||||
| CVE-2022-3409 | 1 Openbmc-project | 1 Openbmc | 2024-11-21 | 8.2 High |
| A vulnerability in bmcweb of OpenBMC Project allows user to cause denial of service. This vulnerability was identified during mitigation for CVE-2022-2809. When fuzzing the multipart_parser code using AFL++ with address sanitizer enabled to find smallest memory corruptions possible. It detected problem in how multipart_parser handles unclosed http headers. If long enough http header is passed in the multipart form without colon there is one byte overwrite on heap. It can be conducted multiple times in a loop to cause DoS. | ||||
| CVE-2022-32091 | 4 Debian, Fedoraproject, Mariadb and 1 more | 5 Debian Linux, Fedora, Mariadb and 2 more | 2024-11-21 | 7.5 High |
| MariaDB v10.7 was discovered to contain an use-after-poison in in __interceptor_memset at /libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc. | ||||
| CVE-2022-32089 | 3 Fedoraproject, Mariadb, Redhat | 4 Fedora, Mariadb, Enterprise Linux and 1 more | 2024-11-21 | 7.5 High |
| MariaDB v10.5 to v10.7 was discovered to contain a segmentation fault via the component st_select_lex_unit::exclude_level. | ||||
| CVE-2022-32088 | 3 Debian, Mariadb, Redhat | 4 Debian Linux, Mariadb, Enterprise Linux and 1 more | 2024-11-21 | 7.5 High |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Exec_time_tracker::get_loops/Filesort_tracker::report_use/filesort. | ||||
| CVE-2022-32087 | 3 Debian, Mariadb, Redhat | 4 Debian Linux, Mariadb, Enterprise Linux and 1 more | 2024-11-21 | 7.5 High |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_args::walk_args. | ||||
| CVE-2022-32086 | 2 Mariadb, Redhat | 2 Mariadb, Rhel Software Collections | 2024-11-21 | 7.5 High |
| MariaDB v10.4 to v10.8 was discovered to contain a segmentation fault via the component Item_field::fix_outer_field. | ||||
| CVE-2022-32085 | 3 Debian, Mariadb, Redhat | 4 Debian Linux, Mariadb, Enterprise Linux and 1 more | 2024-11-21 | 7.5 High |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_func_in::cleanup/Item::cleanup_processor. | ||||
| CVE-2022-32084 | 4 Debian, Fedoraproject, Mariadb and 1 more | 5 Debian Linux, Fedora, Mariadb and 2 more | 2024-11-21 | 7.5 High |
| MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component sub_select. | ||||
| CVE-2022-32083 | 3 Debian, Mariadb, Redhat | 4 Debian Linux, Mariadb, Enterprise Linux and 1 more | 2024-11-21 | 7.5 High |
| MariaDB v10.2 to v10.6.1 was discovered to contain a segmentation fault via the component Item_subselect::init_expr_cache_tracker. | ||||