Search
Search Results (17 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23441 | 1 Linux | 1 Linux Kernel | 2026-04-03 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent concurrent access to IPSec ASO context The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5e_ipsec_aso struct for each PF, which contains a shared DMA-mapped context for all ASO operations. A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area. When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results. This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained. | ||||
| CVE-2026-23459 | 1 Linux | 1 Linux Kernel | 2026-04-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ip_tunnel: adapt iptunnel_xmit_stats() to NETDEV_PCPU_STAT_DSTATS Blamed commits forgot that vxlan/geneve use udp_tunnel[6]_xmit_skb() which call iptunnel_xmit_stats(). iptunnel_xmit_stats() was assuming tunnels were only using NETDEV_PCPU_STAT_TSTATS. @syncp offset in pcpu_sw_netstats and pcpu_dstats is different. 32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten. This patch also moves pcpu_stat_type closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnel_xmit_stats() needs to read it. | ||||
| CVE-2026-23465 | 1 Linux | 1 Linux Kernel | 2026-04-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, but it # it does not log its new dentries (dir1). $ xfs_io -c "fsync" dir2 # This fsync on the parent directory is no-op, since the previous fsync # logged it (but without logging its new dentries). $ xfs_io -c "fsync" . <power failure> # After log replay dir1 is missing. Fix this by ensuring we log new dir dentries whenever we log the parent directory of a no longer existing conflicting inode. A test case for fstests will follow soon. | ||||
| CVE-2026-23281 | 1 Linux | 1 Linux Kernel | 2026-03-27 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix use-after-free in lbs_free_adapter() The lbs_free_adapter() function uses timer_delete() (non-synchronous) for both command_timer and tx_lockup_timer before the structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If a timer callback is executing when lbs_free_adapter() is called, the callback will access freed memory since lbs_cfg_free() frees the containing structure immediately after lbs_free_adapter() returns. Both timer callbacks (lbs_cmd_timeout_handler and lbs_tx_lockup_handler) access priv->driver_lock, priv->cur_cmd, priv->dev, and other fields, which would all be use-after-free violations. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. This bug was introduced in commit 8f641d93c38a ("libertas: detect TX lockups and reset hardware") where del_timer() was used instead of del_timer_sync() in the cleanup path. The command_timer has had the same issue since the driver was first written. | ||||
| CVE-2023-5088 | 2 Qemu, Redhat | 3 Qemu, Advanced Virtualization, Enterprise Linux | 2026-02-25 | 6.4 Medium |
| A bug in QEMU could cause a guest I/O operation otherwise addressed to an arbitrary disk offset to be targeted to offset 0 instead (potentially overwriting the VM's boot code). This could be used, for example, by L2 guests with a virtual disk (vdiskL2) stored on a virtual disk of an L1 (vdiskL1) hypervisor to read and/or write data to LBA 0 of vdiskL1, potentially gaining control of L1 at its next reboot. | ||||
| CVE-2022-49751 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning. | ||||
| CVE-2024-1739 | 1 Lunary | 1 Lunary | 2025-06-18 | 9.1 Critical |
| lunary-ai/lunary is vulnerable to an authentication issue due to improper validation of email addresses during the signup process. Specifically, the server fails to treat email addresses as case insensitive, allowing the creation of multiple accounts with the same email address by varying the case of the email characters. For example, accounts for 'abc@gmail.com' and 'Abc@gmail.com' can both be created, leading to potential impersonation and confusion among users. | ||||
| CVE-2021-47189 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 6.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory ordering between normal and ordered work functions Ordered work functions aren't guaranteed to be handled by the same thread which executed the normal work functions. The only way execution between normal/ordered functions is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don't guarantee any ordering whatsoever. This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs because async_chunk::inode suddenly became NULL. The call trace was similar to: pc : submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 <registers omitted for brevity> Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0 run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18 Fix this by adding respective barrier calls which ensure that all accesses preceding setting of WORK_DONE_BIT are strictly ordered before setting the flag. At the same time add a read barrier after reading of WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads would be strictly ordered after reading the bit. This in turn ensures are all accesses before WORK_DONE_BIT are going to be strictly ordered before any access that can occur in ordered_func. | ||||
| CVE-2024-58131 | 1 Fisco-bcos | 1 Fisco-bcos | 2025-04-08 | 4 Medium |
| FISCO BCOS 3.11.0 has an issue with synchronization of the transaction pool that can, for example, be observed when a malicious node (that has modified the codebase to allow a large min_seal_time value) joins a blockchain network. | ||||
| CVE-2024-58133 | 2025-04-07 | 4 Medium | ||
| In chainmaker-go (aka ChainMaker) before 2.4.0, when making frequent updates to a node's configuration file and restarting this node, concurrent writes by logger.go to a map are mishandled. Creating other logs simultaneously can lead to a read-write conflict and panic. | ||||
| CVE-2024-58132 | 2025-04-07 | 4 Medium | ||
| In chainmaker-go (aka ChainMaker) before 2.3.6, multiple updates to a single node's configuration can cause other normal nodes to perform concurrent read and write operations on a map, leading to a panic. | ||||
| CVE-2023-25730 | 2 Mozilla, Redhat | 8 Firefox, Firefox Esr, Thunderbird and 5 more | 2025-01-10 | 5.4 Medium |
| A background script invoking <code>requestFullscreen</code> and then blocking the main thread could force the browser into fullscreen mode indefinitely, resulting in potential user confusion or spoofing attacks. This vulnerability affects Firefox < 110, Thunderbird < 102.8, and Firefox ESR < 102.8. | ||||
| CVE-2024-1902 | 1 Lunary | 1 Lunary | 2025-01-10 | 7.5 High |
| lunary-ai/lunary is vulnerable to a session reuse attack, allowing a removed user to change the organization name without proper authorization. The vulnerability stems from the lack of validation to check if a user is still part of an organization before allowing them to make changes. An attacker can exploit this by using an old authorization token to send a PATCH request, modifying the organization's name even after being removed from the organization. This issue is due to incorrect synchronization and affects the orgs.patch route. | ||||
| CVE-2024-5755 | 1 Lunary | 1 Lunary | 2024-11-21 | 5.3 Medium |
| In lunary-ai/lunary versions <=v1.2.11, an attacker can bypass email validation by using a dot character ('.') in the email address. This allows the creation of multiple accounts with essentially the same email address (e.g., 'attacker123@gmail.com' and 'attacker.123@gmail.com'), leading to incorrect synchronization and potential security issues. | ||||
| CVE-2022-1931 | 1 Trudesk Project | 1 Trudesk | 2024-11-21 | 8.1 High |
| Incorrect Synchronization in GitHub repository polonel/trudesk prior to 1.2.3. | ||||
| CVE-2024-6657 | 2024-11-04 | 6.5 Medium | ||
| A denial of service may be caused to a single peripheral device in a BLE network when multiple central devices continuously connect and disconnect to the peripheral. A hard reset is required to recover the peripheral device. | ||||
| CVE-2024-4278 | 1 Gitlab | 1 Gitlab | 2024-10-08 | 5.5 Medium |
| An information disclosure issue has been discovered in GitLab EE affecting all versions starting from 16.5 prior to 17.2.8, from 17.3 prior to 17.3.4, and from 17.4 prior to 17.4.1. A maintainer could obtain a Dependency Proxy password by editing a certain Dependency Proxy setting. | ||||
Page 1 of 1.