https://db.gcve.eu/sightings/feed 2026-07-28T03:13:34.511477+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent sightings. https://db.gcve.eu/sighting/1cd6da96-4c2f-463b-8897-d766f4123b88/export 2026-07-28T03:13:34.532268+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "1cd6da96-4c2f-463b-8897-d766f4123b88", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52433", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0398/", "content": "", "creation_timestamp": "2026-04-02T17:00:00.000000Z"} 2026-04-02T17:00:00+00:00 https://db.gcve.eu/sighting/128fabd6-f85f-4a32-a902-8fa17e57dcb6/export 2026-07-28T03:13:34.533767+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "128fabd6-f85f-4a32-a902-8fa17e57dcb6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52433", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-15", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} 2025-08-14T10:00:00+00:00 https://db.gcve.eu/sighting/9c833d66-0a6a-4b9e-86a9-4a8ede3dcb9d/export 2026-07-28T03:13:34.533902+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "9c833d66-0a6a-4b9e-86a9-4a8ede3dcb9d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52435", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-15", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"} 2025-08-14T10:00:00+00:00 https://db.gcve.eu/sighting/ff1ca23c-209b-4180-9d10-63cbf33ea1c6/export 2026-07-28T03:13:34.534014+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "ff1ca23c-209b-4180-9d10-63cbf33ea1c6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52432", "type": "seen", "source": "Telegram/tVYKL4tHJPiXNFlLlhNWYQLODbIgtSdW5vJHyVWnSZja6aYN", "content": "", "creation_timestamp": "2025-02-14T10:01:37.000000Z"} 2025-02-14T10:01:37+00:00 https://db.gcve.eu/sighting/572fe5a2-08fd-4423-91e8-b26e8a83d999/export 2026-07-28T03:13:34.534115+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "572fe5a2-08fd-4423-91e8-b26e8a83d999", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52432", "type": "seen", "source": "https://t.me/ctinow/199938", "content": "https://ift.tt/k9RK3UF\nCVE-2023-52432", "creation_timestamp": "2024-03-05T06:27:01.000000Z"} 2024-03-05T06:27:01+00:00 https://db.gcve.eu/sighting/8a1634e6-4dc9-4756-a1a1-5b130bdef9ae/export 2026-07-28T03:13:34.534222+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "8a1634e6-4dc9-4756-a1a1-5b130bdef9ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52432", "type": "seen", "source": "https://t.me/ctinow/199925", "content": "https://ift.tt/k9RK3UF\nCVE-2023-52432", "creation_timestamp": "2024-03-05T06:22:16.000000Z"} 2024-03-05T06:22:16+00:00 https://db.gcve.eu/sighting/c7598489-e582-4257-a763-61c0818547d1/export 2026-07-28T03:13:34.534315+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "c7598489-e582-4257-a763-61c0818547d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52438", "type": "seen", "source": "https://t.me/arpsyndicate/3837", "content": "#ExploitObserverAlert\n\nCVE-2023-52438\n\nDESCRIPTION: Exploit Observer has 1 entries in 1 file formats related to CVE-2023-52438. In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in shinker's callback The mmap read lock is used during the shrinker's callback, which means that using alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e (\"mm: mmap: zap pages with read mmap_sem in munmap\") the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker's debug sysfs. The following KASAN report confirms the UAF: ================================================================== BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Hardware name: linux,dummy-virt (DT) Call trace: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Last potentially related work creation: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Fix this issue by performing instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade. Note that this option has better performance than upgrading to a mmap write lock which would increase contention. Plus, mmap_write_trylock() has been recently removed anyway.", "creation_timestamp": "2024-02-21T15:17:01.000000Z"} 2024-02-21T15:17:01+00:00 https://db.gcve.eu/sighting/eae628a8-5c90-43ed-8568-68c83143c27b/export 2026-07-28T03:13:34.534436+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "eae628a8-5c90-43ed-8568-68c83143c27b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52439", "type": "seen", "source": "https://t.me/arpsyndicate/3833", "content": "#ExploitObserverAlert\n\nCVE-2023-52439\n\nDESCRIPTION: Exploit Observer has 1 entries in 1 file formats related to CVE-2023-52439. In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock.", "creation_timestamp": "2024-02-21T15:12:02.000000Z"} 2024-02-21T15:12:02+00:00 https://db.gcve.eu/sighting/f62e4b0c-96fa-42fa-9952-743b919933ad/export 2026-07-28T03:13:34.534540+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "f62e4b0c-96fa-42fa-9952-743b919933ad", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52436", "type": "seen", "source": "https://t.me/arpsyndicate/3828", "content": "#ExploitObserverAlert\n\nCVE-2023-52436\n\nDESCRIPTION: Exploit Observer has 1 entries in 1 file formats related to CVE-2023-52436. In the Linux kernel, the following vulnerability has been resolved: f2fs: explicitly null-terminate the xattr list When setting an xattr, explicitly null-terminate the xattr list. This eliminates the fragile assumption that the unused xattr space is always zeroed.", "creation_timestamp": "2024-02-21T15:04:35.000000Z"} 2024-02-21T15:04:35+00:00 https://db.gcve.eu/sighting/0eaf730c-aadc-4332-a4fd-4e1834fe0a3c/export 2026-07-28T03:13:34.534639+00:00 cedric https://db.gcve.eu/user/cedric {"uuid": "0eaf730c-aadc-4332-a4fd-4e1834fe0a3c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-52437", "type": "seen", "source": "https://t.me/arpsyndicate/3821", "content": "#ExploitObserverAlert\n\nCVE-2023-52437\n\nDESCRIPTION: Exploit Observer has 1 entries in 1 file formats related to CVE-2023-52437. In the Linux kernel, the following vulnerability has been resolved: Revert \"md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\" This reverts commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74. That commit introduced the following race and can cause system hung. md_write_start: raid5d: // mddev->in_sync == 1 set \"MD_SB_CHANGE_PENDING\" // running before md_write_start wakeup it waiting \"MD_SB_CHANGE_PENDING\" cleared >>>>>>>>> hung wakeup mddev->thread ... waiting \"MD_SB_CHANGE_PENDING\" cleared >>>> hung, raid5d should clear this flag but get hung by same flag. The issue reverted commit fixing is fixed by last patch in a new way.", "creation_timestamp": "2024-02-21T14:52:34.000000Z"} 2024-02-21T14:52:34+00:00