Total
622 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-48633 | 1 Linux | 1 Linux Kernel | 2025-09-19 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix WARN_ON(lock->magic != lock) error psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex gets destroyed by drm_gem_object_release() move the drm_gem_object_release() call in psb_gem_free_object() to after the unpin to fix the below warning: [ 79.693962] ------------[ cut here ]------------ [ 79.693992] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse [ 79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: G W E 6.0.0-rc3+ #490 [ 79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0 [ 79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff <0f> 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11 [ 79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282 [ 79.694623] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000 [ 79.694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff [ 79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: ffffad1dc048ba90 [ 79.694662] R10: 0000000000000003 R11: ffffffffaad62fe8 R12: ffff9ff302103138 [ 79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270 [ 79.694690] FS: 00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000 [ 79.694705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0 [ 79.694734] Call Trace: [ 79.694749] <TASK> [ 79.694761] ? __schedule+0x47f/0x1670 [ 79.694796] ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694830] ? lock_is_held_type+0xe3/0x140 [ 79.694864] ? ww_mutex_lock+0x38/0xa0 [ 79.694885] ? __cond_resched+0x1c/0x30 [ 79.694902] ww_mutex_lock+0x38/0xa0 [ 79.694925] psb_gem_unpin+0x27/0x1a0 [gma500_gfx] [ 79.694964] psb_gem_unpin+0x199/0x1a0 [gma500_gfx] [ 79.694996] drm_gem_object_release_handle+0x50/0x60 [ 79.695020] ? drm_gem_object_handle_put_unlocked+0xf0/0xf0 [ 79.695042] idr_for_each+0x4b/0xb0 [ 79.695066] ? _raw_spin_unlock_irqrestore+0x30/0x60 [ 79.695095] drm_gem_release+0x1c/0x30 [ 79.695118] drm_file_free.part.0+0x1ea/0x260 [ 79.695150] drm_release+0x6a/0x120 [ 79.695175] __fput+0x9f/0x260 [ 79.695203] task_work_run+0x59/0xa0 [ 79.695227] do_exit+0x387/0xbe0 [ 79.695250] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 79.695275] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695304] do_group_exit+0x33/0xb0 [ 79.695331] __x64_sys_exit_group+0x14/0x20 [ 79.695353] do_syscall_64+0x58/0x80 [ 79.695376] ? up_read+0x17/0x20 [ 79.695401] ? lock_is_held_type+0xe3/0x140 [ 79.695429] ? asm_exc_page_fault+0x22/0x30 [ 79.695450] ? lockdep_hardirqs_on+0x7d/0x100 [ 79.695473] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 79.695493] RIP: 0033:0x7ff1ccefe3f1 [ 79.695516] Code: Unable to access opcode bytes at RIP 0x7ff1ccefe3c7. [ 79.695607] RSP: 002b:00007ffed4413378 EFLAGS: ---truncated--- | |||||
| CVE-2024-26946 | 1 Linux | 1 Linux Kernel | 2025-09-18 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ] | |||||
| CVE-2024-38306 | 1 Linux | 1 Linux Kernel | 2025-09-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: protect folio::private when attaching extent buffer folios [BUG] Since v6.8 there are rare kernel crashes reported by various people, the common factor is bad page status error messages like this: BUG: Bad page state in process kswapd0 pfn:d6e840 page: refcount:0 mapcount:0 mapping:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone=2|lastcpupid=0x3fffff) page_type: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: non-NULL mapping [CAUSE] Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") changes the sequence when allocating a new extent buffer. Previously we always called grab_extent_buffer() under mapping->i_private_lock, to ensure the safety on modification on folio::private (which is a pointer to extent buffer for regular sectorsize). This can lead to the following race: Thread A is trying to allocate an extent buffer at bytenr X, with 4 4K pages, meanwhile thread B is trying to release the page at X + 4K (the second page of the extent buffer at X). Thread A | Thread B -----------------------------------+------------------------------------- | btree_release_folio() | | This is for the page at X + 4K, | | Not page X. | | alloc_extent_buffer() | |- release_extent_buffer() |- filemap_add_folio() for the | | |- atomic_dec_and_test(eb->refs) | page at bytenr X (the first | | | | page). | | | | Which returned -EEXIST. | | | | | | | |- filemap_lock_folio() | | | | Returned the first page locked. | | | | | | | |- grab_extent_buffer() | | | | |- atomic_inc_not_zero() | | | | | Returned false | | | | |- folio_detach_private() | | |- folio_detach_private() for X | |- folio_test_private() | | |- folio_test_private() | Returned true | | | Returned true |- folio_put() | |- folio_put() Now there are two puts on the same folio at folio X, leading to refcount underflow of the folio X, and eventually causing the BUG_ON() on the page->mapping. The condition is not that easy to hit: - The release must be triggered for the middle page of an eb If the release is on the same first page of an eb, page lock would kick in and prevent the race. - folio_detach_private() has a very small race window It's only between folio_test_private() and folio_clear_private(). That's exactly when mapping->i_private_lock is used to prevent such race, and commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() to allocate-then-attach method") screwed that up. At that time, I thought the page lock would kick in as filemap_release_folio() also requires the page to be locked, but forgot the filemap_release_folio() only locks one page, not all pages of an extent buffer. [FIX] Move all the code requiring i_private_lock into attach_eb_folio_to_filemap(), so that everything is done with proper lock protection. Furthermore to prevent future problems, add an extra lockdep_assert_locked() to ensure we're holding the proper lock. To reproducer that is able to hit the race (takes a few minutes with instrumented code inserting delays to alloc_extent_buffer()): #!/bin/sh drop_caches () { while(true); do echo 3 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/compact_memory done } run_tar () { while(true); do for x in `seq 1 80` ; do tar cf /dev/zero /mnt > /dev/null & done wait done } mkfs.btrfs -f -d single -m single ---truncated--- | |||||
| CVE-2025-8836 | 1 Jasper Project | 1 Jasper | 2025-09-16 | 1.7 LOW | 3.3 LOW |
| A vulnerability was determined in JasPer up to 4.2.5. Affected by this issue is the function jpc_floorlog2 of the file src/libjasper/jpc/jpc_enc.c of the component JPEG2000 Encoder. The manipulation leads to reachable assertion. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as 79185d32d7a444abae441935b20ae4676b3513d4. It is recommended to apply a patch to fix this issue. | |||||
| CVE-2024-8361 | 2025-09-16 | N/A | 7.5 HIGH | ||
| In SiWx91x devices, the SHA2/224 algorithm returns a hash of 256 bits instead of 224 bits. This incorrect hash length triggers a software assertion, which subsequently causes a Denial of Service (DoS). If a watchdog is implemented, device will restart after watch dog expires. If watchdog is not implemented, device can be recovered only after a hard reset | |||||
| CVE-2025-9403 | 1 Jqlang | 1 Jq | 2025-09-12 | 1.7 LOW | 3.3 LOW |
| A vulnerability was determined in jqlang jq up to 1.6. Impacted is the function run_jq_tests of the file jq_test.c of the component JSON Parser. Executing manipulation can lead to reachable assertion. The attack requires local access. The exploit has been publicly disclosed and may be utilized. Other versions might be affected as well. | |||||
| CVE-2025-8537 | 1 Axiosys | 1 Bento4 | 2025-09-12 | 2.6 LOW | 3.7 LOW |
| A vulnerability, which was classified as problematic, was found in Axiomatic Bento4 up to 1.6.0-641. Affected is the function AP4_DataBuffer::SetDataSize of the file Mp4Decrypt.cpp of the component mp4decrypt. The manipulation leads to allocation of resources. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. | |||||
| CVE-2024-32475 | 1 Envoyproxy | 1 Envoy | 2025-09-04 | N/A | 7.5 HIGH |
| Envoy is a cloud-native, open source edge and service proxy. When an upstream TLS cluster is used with `auto_sni` enabled, a request containing a `host`/`:authority` header longer than 255 characters triggers an abnormal termination of Envoy process. Envoy does not gracefully handle an error when setting SNI for outbound TLS connection. The error can occur when Envoy attempts to use the `host`/`:authority` header value longer than 255 characters as SNI for outbound TLS connection. SNI length is limited to 255 characters per the standard. Envoy always expects this operation to succeed and abnormally aborts the process when it fails. This vulnerability is fixed in 1.30.1, 1.29.4, 1.28.3, and 1.27.5. | |||||
| CVE-2024-50614 | 1 Tinyxml2 Project | 1 Tinyxml2 | 2025-09-04 | N/A | 6.5 MEDIUM |
| TinyXML2 through 10.0.0 has a reachable assertion for UINT_MAX/16, that may lead to application exit, in tinyxml2.cpp XMLUtil::GetCharacterRef. | |||||
| CVE-2024-50615 | 1 Tinyxml2 Project | 1 Tinyxml2 | 2025-09-04 | N/A | 6.5 MEDIUM |
| TinyXML2 through 10.0.0 has a reachable assertion for UINT_MAX/digit, that may lead to application exit, in tinyxml2.cpp XMLUtil::GetCharacterRef. | |||||
| CVE-2025-9405 | 1 Open5gs | 1 Open5gs | 2025-09-02 | 5.0 MEDIUM | 5.3 MEDIUM |
| A security flaw has been discovered in Open5GS up to 2.7.5. The impacted element is the function gmm_state_exception of the file src/amf/gmm-sm.c. The manipulation results in reachable assertion. It is possible to launch the attack remotely. The exploit has been released to the public and may be exploited. The patch is identified as 8e5fed16114f2f5e40bee1b161914b592b2b7b8f. Applying a patch is advised to resolve this issue. | |||||
| CVE-2025-50422 | 2025-08-26 | N/A | 2.9 LOW | ||
| Cairo through 1.18.4, as used in Poppler through 25.08.0, has an "unscaled->face == NULL" assertion failure for _cairo_ft_unscaled_font_fini in cairo-ft-font.c. | |||||
| CVE-2025-6952 | 1 Open5gs | 1 Open5gs | 2025-08-25 | 1.7 LOW | 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-2025-8698 | 1 Open5gs | 1 Open5gs | 2025-08-25 | 1.7 LOW | 3.3 LOW |
| A vulnerability was found in Open5GS up to 2.7.5. It has been classified as problematic. Affected is the function amf_nsmf_pdusession_handle_release_sm_context of the file src/amf/nsmf-handler.c of the component AMF Service. The manipulation leads to reachable assertion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The name of the patch is 66bc558e417e70ae216ec155e4e81c14ae0ecf30. It is recommended to apply a patch to fix this issue. | |||||
| CVE-2025-7485 | 1 Open5gs | 1 Open5gs | 2025-08-25 | 1.7 LOW | 3.3 LOW |
| A vulnerability classified as problematic was found in Open5GS up to 2.7.3. Affected by this vulnerability is the function ngap_recv_handler/s1ap_recv_handler/recv_handler of the component SCTP Partial Message Handler. The manipulation leads to reachable assertion. The attack needs to be approached locally. The patch is named cfa44575020f3fb045fd971358442053c8684d3d. It is recommended to apply a patch to fix this issue. | |||||
| CVE-2025-9301 | 2025-08-22 | 1.7 LOW | 3.3 LOW | ||
| A vulnerability was determined in cmake 4.1.20250725-gb5cce23. This affects the function cmForEachFunctionBlocker::ReplayItems of the file cmForEachCommand.cxx. This manipulation causes reachable assertion. The attack needs to be launched locally. The exploit has been publicly disclosed and may be utilized. Patch name: 37e27f71bc356d880c908040cd0cb68fa2c371b8. It is suggested to install a patch to address this issue. | |||||
| CVE-2025-24798 | 1 Meshtastic | 1 Meshtastic Firmware | 2025-08-22 | N/A | 4.3 MEDIUM |
| Meshtastic is an open source mesh networking solution. From 1.2.1 until 2.6.2, a packet sent to the routing module that contains want_response==true causes a crash. This can lead to a degradation of service for nodes within range of a malicious sender, or via MQTT if downlink is enabled. This vulnerability is fixed in 2.6.2. | |||||
| CVE-2025-30034 | 1 Siemens | 1 Simatic Rtls Locating Manager | 2025-08-20 | N/A | 6.2 MEDIUM |
| A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions < V3.3). Affected devices do not properly validate input sent to its listening port on the local loopback interface. This could allow an unauthenticated local attacker to cause a denial of service condition. | |||||
| CVE-2025-27073 | 1 Qualcomm | 340 Ar8035, Ar8035 Firmware, Csr8811 and 337 more | 2025-08-20 | N/A | 7.5 HIGH |
| Transient DOS while creating NDP instance. | |||||
| CVE-2025-21452 | 1 Qualcomm | 160 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 157 more | 2025-08-20 | N/A | 7.5 HIGH |
| Transient DOS while processing a random-access response (RAR) with an invalid PDU length on LTE network. | |||||