{"vulnerability": "CVE-2024-5792", "sightings": [{"uuid": "1572e841-4de8-41e8-99df-e3901ae27f6f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57920", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sib7nft2h", "content": "", "creation_timestamp": "2025-01-19T12:16:19.417874Z"}, {"uuid": "0e92dd40-f894-42f7-8ff0-99533175ed6e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57921", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sidbzjy2f", "content": "", "creation_timestamp": "2025-01-19T12:16:21.661828Z"}, {"uuid": "0e89a764-fbea-4bbb-ab67-7de20434bf69", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57922", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sifls542p", "content": "", "creation_timestamp": "2025-01-19T12:16:24.271785Z"}, {"uuid": "3d24db71-54df-4fb3-807f-861fb1167a77", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57923", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sihs2wo27", "content": "", "creation_timestamp": "2025-01-19T12:16:26.493415Z"}, {"uuid": "d9b1dbbc-50a0-4e75-ab7b-17484aaf3c0b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57924", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sikuynr2s", "content": "", "creation_timestamp": "2025-01-19T12:16:29.579535Z"}, {"uuid": "ab349998-a555-4795-a8ac-4853ad8013b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57925", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3simxpnl2n", "content": "", "creation_timestamp": "2025-01-19T12:16:31.691667Z"}, {"uuid": "c1d5d1fc-a0e5-4806-95c8-c91a291057a7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57926", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sip63o627", "content": "", "creation_timestamp": "2025-01-19T12:16:34.432626Z"}, {"uuid": "ed42aede-2f8e-4dee-9c80-8b5910c3a0dd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57927", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3sirwsbi2b", "content": "", "creation_timestamp": "2025-01-19T12:16:36.946065Z"}, {"uuid": "a9b50d2e-67d6-415d-82c7-bebefdec9c7c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57928", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3siujc332t", "content": "", "creation_timestamp": "2025-01-19T12:16:39.851815Z"}, {"uuid": "12c84ba8-5366-4ef2-af1d-c5eddf18f3fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57929", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3siwm4kr2s", "content": "", "creation_timestamp": "2025-01-19T12:16:42.193514Z"}, {"uuid": "61c6213f-6994-4c5a-bc34-1c8eb851e56b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57928", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113855087502562969", "content": "", "creation_timestamp": "2025-01-19T12:46:04.392837Z"}, {"uuid": "e5a70f8d-0f0c-41d0-87e4-b1f5e40c1295", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57923", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3undlhjd2e", "content": "", "creation_timestamp": "2025-01-19T12:54:57.437762Z"}, {"uuid": "58f2e5fd-49e0-4969-a1e1-d8517893d2b9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57920", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3undpyvi2k", "content": "", "creation_timestamp": "2025-01-19T12:54:58.001937Z"}, {"uuid": "84e1a0c5-1b38-4891-b23c-fbfc6a97954d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57922", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3une43f42u", "content": "", "creation_timestamp": "2025-01-19T12:54:59.688693Z"}, {"uuid": "136ef5eb-b38c-42d4-a78e-68052da4dd47", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57927", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3une7rke2u", "content": "", "creation_timestamp": "2025-01-19T12:55:00.262572Z"}, {"uuid": "6392426d-9106-453a-bdea-2fb7bcdcf7ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "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"}, {"uuid": "240eceb7-bf03-4a2e-a81b-552fbeda1f66", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "81ec6a4f-cd05-4d97-ba08-9704bba24a84", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57926", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2334", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57926\n\ud83d\udd39 Description: 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...\n\ud83d\udccf Published: 2025-01-19T11:52:43.915Z\n\ud83d\udccf Modified: 2025-01-19T11:52:43.915Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/7083b93e9755d60f0c2bcaa9d064308108280534\n2. https://git.kernel.org/stable/c/078b2ff7da200b7532398e668eef723ad40fb516\n3. https://git.kernel.org/stable/c/36684e9d88a2e2401ae26715a2e217cb4295cea7", "creation_timestamp": "2025-01-19T11:58:27.000000Z"}, {"uuid": "40a9c4cd-443e-4d19-b8de-d2d1a05b7d35", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57927", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2333", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57927\n\ud83d\udd39 Description: 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.\n\ud83d\udccf Published: 2025-01-19T11:52:44.567Z\n\ud83d\udccf Modified: 2025-01-19T11:52:44.567Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/13a07cc81e2d116cece727a83746c74b87a9d417\n2. https://git.kernel.org/stable/c/86ad1a58f6a9453f49e06ef957a40a8dac00a13f", "creation_timestamp": "2025-01-19T11:58:26.000000Z"}, {"uuid": "2d5d1042-4827-4313-a975-7c2ec505da32", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57928", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2332", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57928\n\ud83d\udd39 Description: 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].\n\ud83d\udccf Published: 2025-01-19T11:52:45.427Z\n\ud83d\udccf Modified: 2025-01-19T11:52:45.427Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/88ecdfea1b333de5c51442b45cd549eeadf01852\n2. https://git.kernel.org/stable/c/105549d09a539a876b7c3330ab52d8aceedad358", "creation_timestamp": "2025-01-19T11:58:26.000000Z"}, {"uuid": "a3a886a8-de7f-47fa-b188-8fedb3adf150", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57922", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2336", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57922\n\ud83d\udd39 Description: 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)\n\ud83d\udccf Published: 2025-01-19T11:52:41.156Z\n\ud83d\udccf Modified: 2025-01-19T11:52:41.156Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/f3d1e4062ef251fa55ccfeca1e54a98b6818b3a1\n2. https://git.kernel.org/stable/c/ae9ab63a268be99a27a4720ca24f6be801744fee\n3. https://git.kernel.org/stable/c/4f0dd09ed3001725ffd8cdc2868e71df585392fe\n4. https://git.kernel.org/stable/c/0881fbc4fd62e00a2b8e102725f76d10351b2ea8", "creation_timestamp": "2025-01-19T11:58:29.000000Z"}, {"uuid": "76d3226e-7b5e-4bab-a3b6-740b006791e5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57925", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/2335", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-57925\n\ud83d\udd39 Description: 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.\n\ud83d\udccf Published: 2025-01-19T11:52:43.244Z\n\ud83d\udccf Modified: 2025-01-19T11:52:43.244Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/ee7e40f7fb17f08a8cbae50553e5c2e10ae32fce\n2. https://git.kernel.org/stable/c/271ae0edbfc942795c162e6cf20d2bc02bd7fde4\n3. https://git.kernel.org/stable/c/2976e91a3e569cf2c92c9f71512c0ab1312fe965\n4. https://git.kernel.org/stable/c/4c16e1cadcbcaf3c82d5fc310fbd34d0f5d0db7c", "creation_timestamp": "2025-01-19T11:58:28.000000Z"}, {"uuid": "1b8b47b7-e726-403e-b66a-621fef99ad6a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "1d5c0267-6848-4f3b-88d8-84527c3719ff", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "601919cf-2526-40dd-8ecb-53aa51559afe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "9a45c816-8db2-4fee-b54b-684b65886b77", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "0294b47c-83c8-42f3-b119-af8f351fed7b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "382d17bf-3e80-48a4-980c-71f40dcfb1d8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "86671e6b-86b1-43b7-8de8-cb1e54732406", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "8b20b0ef-5672-4b20-870c-5f7ab1b1fe95", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}, {"uuid": "2c34cda5-d3f1-429d-8b5b-77f8f2f2df4c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57921", "type": "seen", "source": "https://t.me/cvedetector/15845", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57921 - AMD GPU amdgpu: Race Condition Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-57921 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amdgpu: Add a lock when accessing the buddy trim function  \n  \nWhen running YouTube videos and Steam games simultaneously,  \nthe tester found a system hang / race condition issue with  \nthe multi-display configuration setting. Adding a lock to  \nthe buddy allocator's trim function would be the solution.  \n  \n  \n[ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108  \n[ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]  \n[ 7197.250470] Call Trace:  \n[ 7197.250472]    \n[ 7197.250475]  ? show_regs+0x6d/0x80  \n[ 7197.250481]  ? die_addr+0x37/0xa0  \n[ 7197.250483]  ? exc_general_protection+0x1db/0x480  \n[ 7197.250488]  ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]  \n[ 7197.250493]  ? asm_exc_general_protection+0x27/0x30  \n[ 7197.250498]  ? __alloc_range+0x8b/0x340 [amddrm_buddy]  \n[ 7197.250501]  ? __alloc_range+0x109/0x340 [amddrm_buddy]  \n[ 7197.250506]  amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]  \n[ 7197.250511]  amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]  \n[ 7197.250682]  amdttm_resource_alloc+0x46/0xb0 [amdttm]  \n[ 7197.250689]  ttm_bo_alloc_resource+0xe4/0x370 [amdttm]  \n[ 7197.250696]  amdttm_bo_validate+0x9d/0x180 [amdttm]  \n[ 7197.250701]  amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]  \n[ 7197.250831]  amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]  \n[ 7197.251025]  ? try_wait_for_completion+0x59/0x70  \n[ 7197.251030]  drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0  \n[ 7197.251035]  drm_atomic_helper_prepare_planes+0x5d/0x70  \n[ 7197.251037]  drm_atomic_helper_commit+0x84/0x160  \n[ 7197.251040]  drm_atomic_nonblocking_commit+0x59/0x70  \n[ 7197.251043]  drm_mode_atomic_ioctl+0x720/0x850  \n[ 7197.251047]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10  \n[ 7197.251049]  drm_ioctl_kernel+0xb9/0x120  \n[ 7197.251053]  ? srso_alias_return_thunk+0x5/0xfbef5  \n[ 7197.251056]  drm_ioctl+0x2d4/0x550  \n[ 7197.251058]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10  \n[ 7197.251063]  amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]  \n[ 7197.251186]  __x64_sys_ioctl+0xa0/0xf0  \n[ 7197.251190]  x64_sys_call+0x143b/0x25c0  \n[ 7197.251193]  do_syscall_64+0x7f/0x180  \n[ 7197.251197]  ? srso_alias_return_thunk+0x5/0xfbef5  \n[ 7197.251199]  ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]  \n[ 7197.251329]  ? drm_internal_framebuffer_create+0xb7/0x1a0  \n[ 7197.251332]  ? srso_alias_return_thunk+0x5/0xfbef5  \n  \n(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516) \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:17.000000Z"}, {"uuid": "0aa2c6ad-feaf-43b6-b142-85de34064dff", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-57929", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/15844", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-57929 - Linux Device-Mapper Array Buffer\u00edo Buffer Overwrite\", \n  \"Content\": \"CVE ID : CVE-2024-57929 \nPublished : Jan. 19, 2025, 12:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndm array: fix releasing a faulty array block twice in dm_array_cursor_end  \n  \nWhen dm_bm_read_lock() fails due to locking or checksum errors, it  \nreleases the faulty block implicitly while leaving an invalid output  \npointer behind. The caller of dm_bm_read_lock() should not operate on  \nthis invalid dm_block pointer, or it will lead to undefined result.  \nFor example, the dm_array_cursor incorrectly caches the invalid pointer  \non reading a faulty array block, causing a double release in  \ndm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().  \n  \nReproduce steps:  \n  \n1. initialize a cache device  \n  \ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"  \ndmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\"  \ndmsetup create corig --table \"0 524288 linear /dev/sdc $262144\"  \ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1  \ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\  \n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"  \n  \n2. wipe the second array block offline  \n  \ndmsteup remove cache cmeta cdata corig  \nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\  \n2>/dev/null | hexdump -e '1/8 \"%u\\n\"')  \nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\  \n2>/dev/null | hexdump -e '1/8 \"%u\\n\"')  \ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock  \n  \n3. try reopen the cache device  \n  \ndmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\"  \ndmsetup create cdata --table \"0 65536 linear /dev/sdc 8192\"  \ndmsetup create corig --table \"0 524288 linear /dev/sdc $262144\"  \ndmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\  \n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\"  \n  \nKernel logs:  \n  \n(snip)  \ndevice-mapper: array: array_block_check failed: blocknr 0 != wanted 10  \ndevice-mapper: block manager: array validator check failed for block 10  \ndevice-mapper: array: get_ablock failed  \ndevice-mapper: cache metadata: dm_array_cursor_next for mapping failed  \n------------[ cut here ]------------  \nkernel BUG at drivers/md/dm-bufio.c:638!  \n  \nFix by setting the cached block pointer to NULL on errors.  \n  \nIn addition to the reproducer described above, this fix can be  \nverified using the \"array_cursor/damaged\" test in dm-unit:  \n  dm-unit run /pdata/array_cursor/damaged --kernel-dir \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:16.000000Z"}, {"uuid": "d6b0f877-9369-473d-987b-12cf93db94e2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-5792", "type": "seen", "source": "https://t.me/cvedetector/497", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-5792 - The Houzez CRM plugin for WordPress is vulnerable\", \n  \"Content\": \"CVE ID : CVE-2024-5792 \nPublished : July 10, 2024, 2:15 a.m. | 18\u00a0minutes ago \nDescription : The Houzez CRM plugin for WordPress is vulnerable to time-based SQL Injection via the notes \u2018belong_to\u2019 parameter in all versions up to, and including, 1.4.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Custom-level (seller) access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. \nSeverity: 8.8 | HIGH \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"10 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-10T04:38:05.000000Z"}, {"uuid": "d73abacc-56de-454e-a4b7-bb81ad89ff62", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "4f29edb9-4c4b-44ca-b041-9b050656b6ae", "vulnerability": "CVE-2024-57924", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-134-10", "content": "", "creation_timestamp": "2026-05-14T10:00:00.000000Z"}]}