Total
645 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-26726 | 1 Linux | 1 Linux Kernel | 2025-07-10 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test. | ||||
| CVE-2025-6952 | 1 Open5gs | 1 Open5gs | 2025-07-06 | 3.3 Low |
| A vulnerability, which was classified as problematic, has been found in Open5GS up to 2.7.5. This issue affects the function amf_state_operational of the file src/amf/amf-sm.c of the component AMF Service. The manipulation leads to reachable assertion. It is possible to launch the attack on the local host. The identifier of the patch is 53e9e059ed96b940f7ddcd9a2b68cb512524d5db. It is recommended to apply a patch to fix this issue. | ||||
| CVE-2024-24420 | 1 Linuxfoundation | 1 Magma | 2025-07-03 | 7.5 High |
| A reachable assertion in the decode_linked_ti_ie function of Magma <= 1.8.0 (fixed in v1.9 commit 08472ba98b8321f802e95f5622fa90fec2dea486) allows attackers to cause a Denial of Service (DoS) via a crafted NAS packet. | ||||
| CVE-2022-31651 | 1 Sound Exchange Project | 1 Sound Exchange | 2025-06-27 | 5.5 Medium |
| In SoX 14.4.2, there is an assertion failure in rate_init in rate.c in libsox.a. | ||||
| CVE-2025-6497 | 1 Htacg | 1 Tidy | 2025-06-27 | 3.3 Low |
| A vulnerability was found in HTACG tidy-html5 5.8.0. It has been rated as problematic. This issue affects the function prvTidyParseNamespace of the file src/parser.c. The manipulation leads to reachable assertion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2025-6273 | 1 Webassembly | 1 Wabt | 2025-06-23 | 3.3 Low |
| A vulnerability was found in WebAssembly wabt up to 1.0.37 and classified as problematic. This issue affects the function LogOpcode of the file src/binary-reader-objdump.cc. The manipulation leads to reachable assertion. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains that this issue might not affect "real world wasm programs". | ||||
| CVE-2025-40775 | 1 Isc | 1 Bind 9 | 2025-06-23 | 7.5 High |
| When an incoming DNS protocol message includes a Transaction Signature (TSIG), BIND always checks it. If the TSIG contains an invalid value in the algorithm field, BIND immediately aborts with an assertion failure. This issue affects BIND 9 versions 9.20.0 through 9.20.8 and 9.21.0 through 9.21.7. | ||||
| CVE-2024-25445 | 1 Hugin Project | 1 Hugin | 2025-06-20 | 7.8 High |
| Improper handling of values in HuginBase::PTools::Transform::transform of Hugin 2022.0.0 leads to an assertion failure. | ||||
| CVE-2023-52569 | 1 Linux | 1 Linux Kernel | 2025-06-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node's tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items. | ||||
| CVE-2022-49348 | 1 Redhat | 1 Enterprise Linux | 2025-06-19 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that we are in the middle of replay the fast commit journal. This was actually a mistake, since the sbi->s_mount_info is initialized from es->s_state. Arguably s_mount_state is misleadingly named, but the name is historical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_flag() inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags. The problem with using EXT4_FC_REPLAY is that a maliciously corrupted superblock could result in EXT4_FC_REPLAY getting set in s_mount_state. This bypasses some sanity checks, and this can trigger a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter out the EXT4_FC_REPLAY bit for now. We should eventually transition away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY. | ||||
| CVE-2022-48634 | 1 Linux | 1 Linux Kernel | 2025-06-19 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix BUG: sleeping function called from invalid context errors gma_crtc_page_flip() was holding the event_lock spinlock while calling crtc_funcs->mode_set_base() which takes ww_mutex. The only reason to hold event_lock is to clear gma_crtc->page_flip_event on mode_set_base() errors. Instead unlock it after setting gma_crtc->page_flip_event and on errors re-take the lock and clear gma_crtc->page_flip_event it it is still set. This fixes the following WARN/stacktrace: [ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell [ 512.123031] preempt_count: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] <TASK> [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60 [ 512.124104] ? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? do_syscall_64+0x67/0x80 [ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0 [ 512.124300] ? do_syscall_64+0x67/0x80 [ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80 [ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 [ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647] </TASK> | ||||
| CVE-2025-29339 | 1 Open5gs | 1 Open5gs | 2025-06-19 | 7.5 High |
| An issue in UPF in Open5GS UPF versions up to v2.7.2 results an assertion failure vulnerability in PFCP session parameter validation. When processing a PFCP Session Establishment Request with PDN Type=0, the UPF fails to handle the invalid value propagated from SMF (or via direct attack), triggering a fatal assertion check and causing a daemon crash. | ||||
| CVE-2023-43523 | 1 Qualcomm | 284 Ar8035, Ar8035 Firmware, Csr8811 and 281 more | 2025-06-17 | 7.5 High |
| Transient DOS while processing 11AZ RTT management action frame received through OTA. | ||||
| CVE-2024-3652 | 2 Libreswan, Redhat | 7 Libreswan, Enterprise Linux, Openshift and 4 more | 2025-06-17 | 6.5 Medium |
| The Libreswan Project was notified of an issue causing libreswan to restart when using IKEv1 without specifying an esp= line. When the peer requests AES-GMAC, libreswan's default proposal handler causes an assertion failure and crashes and restarts. IKEv2 connections are not affected. | ||||
| CVE-2025-5501 | 1 Open5gs | 1 Open5gs | 2025-06-13 | 5.3 Medium |
| A vulnerability classified as problematic was found in Open5GS up to 2.7.3. Affected by this vulnerability is the function ngap_handle_path_switch_request_transfer of the file src/smf/ngap-handler.c of the component NGAP PathSwitchRequest Message Handler. The manipulation leads to reachable assertion. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The patch is named 2daa44adab762c47a8cef69cc984946973a845b3. It is recommended to apply a patch to fix this issue. | ||||
| CVE-2021-3326 | 6 Debian, Fujitsu, Gnu and 3 more | 18 Debian Linux, M10-1, M10-1 Firmware and 15 more | 2025-06-09 | 7.5 High |
| The iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service. | ||||
| CVE-2020-29562 | 3 Fedoraproject, Gnu, Netapp | 3 Fedora, Glibc, E-series Santricity Os Controller | 2025-06-09 | 4.8 Medium |
| The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service. | ||||
| CVE-2023-34969 | 4 Debian, Fedoraproject, Freedesktop and 1 more | 5 Debian Linux, Fedora, Dbus and 2 more | 2025-06-09 | 6.5 Medium |
| D-Bus before 1.15.6 sometimes allows unprivileged users to crash dbus-daemon. If a privileged user with control over the dbus-daemon is using the org.freedesktop.DBus.Monitoring interface to monitor message bus traffic, then an unprivileged user with the ability to connect to the same dbus-daemon can cause a dbus-daemon crash under some circumstances via an unreplyable message. When done on the well-known system bus, this is a denial-of-service vulnerability. The fixed versions are 1.12.28, 1.14.8, and 1.15.6. | ||||
| CVE-2025-5520 | 1 Open5gs | 1 Open5gs | 2025-06-09 | 5.3 Medium |
| A vulnerability was found in Open5GS up to 2.7.3. It has been classified as problematic. Affected is the function gmm_state_authentication/emm_state_authentication of the component AMF/MME. The manipulation leads to reachable assertion. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The name of the patch is 9f5d133657850e6167231527514ee1364d37a884. It is recommended to apply a patch to fix this issue. This is a different issue than CVE-2025-1893. | ||||
| CVE-2024-46751 | 1 Linux | 1 Linux Kernel | 2025-06-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message. | ||||