https://vulnerability.circl.lu/sightings/feed 2026-05-04T13:56:16.321882+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/8b20b0ef-5672-4b20-870c-5f7ab1b1fe95/export 2026-05-04T13:56:16.516889+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "8b20b0ef-5672-4b20-870c-5f7ab1b1fe95", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57922", "type": "seen", "source": "https://t.me/cvedetector/15846", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57922 - AMD Display Divide-by-Zero Error (Linux Kernel)\", \n \"Content\": \"CVE ID : CVE-2024-57922 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/amd/display: Add check for granularity in dml ceil/floor helpers \n \n[Why] \nWrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() \nshould check for granularity is non zero to avoid assert and \ndivide-by-zero error in dcn_bw_ functions. \n \n[How] \nAdd check for granularity 0. \n \n(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:18.000000Z"} 2025-01-19T13:58:18+00:00 https://vulnerability.circl.lu/sighting/86671e6b-86b1-43b7-8de8-cb1e54732406/export 2026-05-04T13:56:16.516809+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "86671e6b-86b1-43b7-8de8-cb1e54732406", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57923", "type": "seen", "source": "https://t.me/cvedetector/15847", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57923 - btrfs zlib S390 Hardware Acceleration Path Buffer Overflow\", \n \"Content\": \"CVE ID : CVE-2024-57923 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nbtrfs: zlib: fix avail_in bytes for s390 zlib HW compression path \n \nSince the input data length passed to zlib_compress_folios() can be \narbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may \ncause read-in bytes to exceed the input range. Currently this triggers \nan assert in btrfs_compress_folios() on the debug kernel (see below). \nFix strm.avail_in calculation for S390 hardware acceleration path. \n \n assertion failed: *total_in <=0000021761df6538: 0707 bcr 0,%r7 \n 0000021761df653a: 0707 bcr 0,%r7 \n 0000021761df653c: 0707 bcr 0,%r7 \n 0000021761df653e: 0707 bcr 0,%r7 \n 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 \n Call Trace: \n [<0000021761df6538] btrfs_compress_folios+0x198/0x1a0 \n ([<0000021761df6534] btrfs_compress_folios+0x194/0x1a0) \n [<0000021761d97788] compress_file_range+0x3b8/0x6d0 \n [<0000021761dcee7c] btrfs_work_helper+0x10c/0x160 \n [<0000021761645760] process_one_work+0x2b0/0x5d0 \n [<000002176164637e] worker_thread+0x20e/0x3e0 \n [<000002176165221a] kthread+0x15a/0x170 \n [<00000217615b859c] __ret_from_fork+0x3c/0x60 \n [<00000217626e72d2] ret_from_fork+0xa/0x38 \n INFO: lockdep is turned off. \n Last Breaking-Event-Address: \n [<0000021761597924] _printk+0x4c/0x58 \n Kernel panic - not syncing: Fatal exception: panic_on_oops \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:19.000000Z"} 2025-01-19T13:58:19+00:00 https://vulnerability.circl.lu/sighting/382d17bf-3e80-48a4-980c-71f40dcfb1d8/export 2026-05-04T13:56:16.516728+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "382d17bf-3e80-48a4-980c-71f40dcfb1d8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57924", "type": "seen", "source": "https://t.me/cvedetector/15848", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57924 - Oracle Solaris Linux Kernel File Handle Encoding Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-57924 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nfs: relax assertions on failure to encode file handles \n \nEncoding file handles is usually performed by a filesystem >encode_fh() \nmethod that may fail for various reasons. \n \nThe legacy users of exportfs_encode_fh(), namely, nfsd and \nname_to_handle_at(2) syscall are ready to cope with the possibility \nof failure to encode a file handle. \n \nThere are a few other users of exportfs_encode_{fh,fid}() that \ncurrently have a WARN_ON() assertion when ->encode_fh() fails. \nRelax those assertions because they are wrong. \n \nThe second linked bug report states commit 16aac5ad1fa9 (\"ovl: support \nencoding non-decodable file handles\") in v6.6 as the regressing commit, \nbut this is not accurate. \n \nThe aforementioned commit only increases the chances of the assertion \nand allows triggering the assertion with the reproducer using overlayfs, \ninotify and drop_caches. \n \nTriggering this assertion was always possible with other filesystems and \nother reasons of ->encode_fh() failures and more particularly, it was \nalso possible with the exact same reproducer using overlayfs that is \nmounted with options index=on,nfs_export=on also on kernels < v6.6. \nTherefore, I am not listing the aforementioned commit as a Fixes commit. \n \nBackport hint: this patch will have a trivial conflict applying to \nv6.6.y, and other trivial conflicts applying to stable kernels < v6.6. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:20.000000Z"} 2025-01-19T13:58:20+00:00 https://vulnerability.circl.lu/sighting/0294b47c-83c8-42f3-b119-af8f351fed7b/export 2026-05-04T13:56:16.516645+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "0294b47c-83c8-42f3-b119-af8f351fed7b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57925", "type": "seen", "source": "https://t.me/cvedetector/15849", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57925 - \"Ksmbd Kernel Illegal Memory Write Vulnerability\"\", \n \"Content\": \"CVE ID : CVE-2024-57925 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nksmbd: fix a missing return value check bug \n \nIn the smb2_send_interim_resp(), if ksmbd_alloc_work_struct() \nfails to allocate a node, it returns a NULL pointer to the \nin_work pointer. This can lead to an illegal memory write of \nin_work->response_buf when allocate_interim_rsp_buf() attempts \nto perform a kzalloc() on it. \n \nTo address this issue, incorporating a check for the return \nvalue of ksmbd_alloc_work_struct() ensures that the function \nreturns immediately upon allocation failure, thereby preventing \nthe aforementioned illegal memory access. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:23.000000Z"} 2025-01-19T13:58:23+00:00 https://vulnerability.circl.lu/sighting/9a45c816-8db2-4fee-b54b-684b65886b77/export 2026-05-04T13:56:16.516531+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "9a45c816-8db2-4fee-b54b-684b65886b77", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57926", "type": "seen", "source": "https://t.me/cvedetector/15850", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57926 - Mediatek Linux Kernel DRM Use-After-Free Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-57926 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/mediatek: Set private->all_drm_private[i]->drm to NULL if mtk_drm_bind returns err \n \nThe pointer need to be set to NULL, otherwise KASAN complains about \nuse-after-free. Because in mtk_drm_bind, all private's drm are set \nas follows. \n \nprivate->all_drm_private[i]->drm = drm; \n \nAnd drm will be released by drm_dev_put in case mtk_drm_kms_init returns \nfailure. However, the shutdown path still accesses the previous allocated \nmemory in drm_atomic_helper_shutdown. \n \n[ 84.874820] watchdog: watchdog0: watchdog did not stop! \n[ 86.512054] ================================================================== \n[ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378 \n[ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1 \n[ 86.515213] \n[ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 \n[ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022 \n[ 86.517960] Call trace: \n[ 86.518333] show_stack+0x20/0x38 (C) \n[ 86.518891] dump_stack_lvl+0x90/0xd0 \n[ 86.519443] print_report+0xf8/0x5b0 \n[ 86.519985] kasan_report+0xb4/0x100 \n[ 86.520526] __asan_report_load8_noabort+0x20/0x30 \n[ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378 \n[ 86.521966] mtk_drm_shutdown+0x54/0x80 \n[ 86.522546] platform_shutdown+0x64/0x90 \n[ 86.523137] device_shutdown+0x260/0x5b8 \n[ 86.523728] kernel_restart+0x78/0xf0 \n[ 86.524282] __do_sys_reboot+0x258/0x2f0 \n[ 86.524871] __arm64_sys_reboot+0x90/0xd8 \n[ 86.525473] invoke_syscall+0x74/0x268 \n[ 86.526041] el0_svc_common.constprop.0+0xb0/0x240 \n[ 86.526751] do_el0_svc+0x4c/0x70 \n[ 86.527251] el0_svc+0x4c/0xc0 \n[ 86.527719] el0t_64_sync_handler+0x144/0x168 \n[ 86.528367] el0t_64_sync+0x198/0x1a0 \n[ 86.528920] \n[ 86.529157] The buggy address belongs to the physical page: \n[ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc \n[ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) \n[ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 \n[ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000 \n[ 86.534511] page dumped because: kasan: bad access detected \n[ 86.535323] \n[ 86.535559] Memory state around the buggy address: \n[ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff \n[ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff \n[ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff \n[ 86.544733] ^ \n[ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff \n[ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff \n[ 86.563928] ================================================================== \n[ 86.571093] Disabling lock debugging due to kernel taint \n[ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b \n[ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f] \n... \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:24.000000Z"} 2025-01-19T13:58:24+00:00 https://vulnerability.circl.lu/sighting/601919cf-2526-40dd-8ecb-53aa51559afe/export 2026-05-04T13:56:16.516441+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "601919cf-2526-40dd-8ecb-53aa51559afe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57927", "type": "seen", "source": "https://t.me/cvedetector/15851", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57927 - Linux Kernel NFS Null File Pointer Cahce Writing Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-57927 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nnfs: Fix oops in nfs_netfs_init_request() when copying to cache \n \nWhen netfslib wants to copy some data that has just been read on behalf of \nnfs, it creates a new write request and calls nfs_netfs_init_request() to \ninitialise it, but with a NULL file pointer. This causes \nnfs_file_open_context() to oops - however, we don't actually need the nfs \ncontext as we're only going to write to the cache. \n \nFix this by just returning if we aren't given a file pointer and emit a \nwarning if the request was for something other than copy-to-cache. \n \nFurther, fix nfs_netfs_free_request() so that it doesn't try to free the \ncontext if the pointer is NULL. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:25.000000Z"} 2025-01-19T13:58:25+00:00 https://vulnerability.circl.lu/sighting/1d5c0267-6848-4f3b-88d8-84527c3719ff/export 2026-05-04T13:56:16.516324+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "1d5c0267-6848-4f3b-88d8-84527c3719ff", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57920", "type": "seen", "source": "https://t.me/cvedetector/15852", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57920 - Ampegu Null Pointer Dereference\", \n \"Content\": \"CVE ID : CVE-2024-57920 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/amdkfd: wq_release signals dma_fence only when available \n \nkfd_process_wq_release() signals eviction fence by \ndma_fence_signal() which wanrs if dma_fence \nis NULL. \n \nkfd_process->ef is initialized by kfd_process_device_init_vm() \nthrough ioctl. That means the fence is NULL for a new \ncreated kfd_process, and close a kfd_process right \nafter open it will trigger the warning. \n \nThis commit conditionally signals the eviction fence \nin kfd_process_wq_release() only when it is available. \n \n[ 503.660882] WARNING: CPU: 0 PID: 9 at drivers/dma-buf/dma-fence.c:467 dma_fence_signal+0x74/0xa0 \n[ 503.782940] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu] \n[ 503.789640] RIP: 0010:dma_fence_signal+0x74/0xa0 \n[ 503.877620] Call Trace: \n[ 503.880066] \n[ 503.882168] ? __warn+0xcd/0x260 \n[ 503.885407] ? dma_fence_signal+0x74/0xa0 \n[ 503.889416] ? report_bug+0x288/0x2d0 \n[ 503.893089] ? handle_bug+0x53/0xa0 \n[ 503.896587] ? exc_invalid_op+0x14/0x50 \n[ 503.900424] ? asm_exc_invalid_op+0x16/0x20 \n[ 503.904616] ? dma_fence_signal+0x74/0xa0 \n[ 503.908626] kfd_process_wq_release+0x6b/0x370 [amdgpu] \n[ 503.914081] process_one_work+0x654/0x10a0 \n[ 503.918186] worker_thread+0x6c3/0xe70 \n[ 503.921943] ? srso_alias_return_thunk+0x5/0xfbef5 \n[ 503.926735] ? srso_alias_return_thunk+0x5/0xfbef5 \n[ 503.931527] ? __kthread_parkme+0x82/0x140 \n[ 503.935631] ? __pfx_worker_thread+0x10/0x10 \n[ 503.939904] kthread+0x2a8/0x380 \n[ 503.943132] ? __pfx_kthread+0x10/0x10 \n[ 503.946882] ret_from_fork+0x2d/0x70 \n[ 503.950458] ? __pfx_kthread+0x10/0x10 \n[ 503.954210] ret_from_fork_asm+0x1a/0x30 \n[ 503.958142] \n[ 503.960328] ---[ end trace 0000000000000000 ]--- \n \n(cherry picked from commit 2774ef7625adb5fb9e9265c26a59dca7b8fd171e) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:26.000000Z"} 2025-01-19T13:58:26+00:00 https://vulnerability.circl.lu/sighting/1b8b47b7-e726-403e-b66a-621fef99ad6a/export 2026-05-04T13:56:16.515360+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "1b8b47b7-e726-403e-b66a-621fef99ad6a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-57928", "type": "seen", "source": "https://t.me/cvedetector/15855", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-57928 - Linux Kernel Netfs Enomem Handling Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-57928 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nnetfs: Fix enomem handling in buffered reads \n \nIf netfs_read_to_pagecache() gets an error from either ->prepare_read() or \nfrom netfs_prepare_read_iterator(), it needs to decrement ->nr_outstanding, \ncancel the subrequest and break out of the issuing loop. Currently, it \nonly does this for two of the cases, but there are two more that aren't \nhandled. \n \nFix this by moving the handling to a common place and jumping to it from \nall four places. This is in preference to inserting a wrapper around \nnetfs_prepare_read_iterator() as proposed by Dmitry Antipov[1]. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"19 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:58:30.000000Z"} 2025-01-19T13:58:30+00:00 https://vulnerability.circl.lu/sighting/240eceb7-bf03-4a2e-a81b-552fbeda1f66/export 2026-05-04T13:56:16.514310+00:00 Alexandre Dulaunoy http://vulnerability.circl.lu/user/adulau {"uuid": "240eceb7-bf03-4a2e-a81b-552fbeda1f66", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-57924", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"} 2025-12-03T14:14:49.267740+00:00 https://vulnerability.circl.lu/sighting/6392426d-9106-453a-bdea-2fb7bcdcf7ef/export 2026-05-04T13:56:16.512768+00:00 Joseph Lee http://vulnerability.circl.lu/user/syspect {"uuid": "6392426d-9106-453a-bdea-2fb7bcdcf7ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-57924", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"} 2026-03-19T00:00:00+00:00