{"vulnerability": "CVE-2024-3947", "sightings": [{"uuid": "fa76faff-8cf3-40e1-a363-666784d22078", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39476", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-15", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "f03fcfd5-4022-4b37-be6d-d90bd26559fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39472", "type": "seen", "source": "https://t.me/cvedetector/85", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39472 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39472 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nxfs: fix log recovery buffer allocation for the legacy h_size fixup \n \nCommit a70f9fe52daa (\"xfs: detect and handle invalid iclog size set by \nmkfs\") added a fixup for incorrect h_size values used for the initial \numount record in old xfsprogs versions.  Later commit 0c771b99d6c9 \n(\"xfs: clean up calculation of LR header blocks\") cleaned up the log \nreover buffer calculation, but stoped using the fixed up h_size value \nto size the log recovery buffer, which can lead to an out of bounds \naccess when the incorrect h_size does not come from the old mkfs \ntool, but a fuzzer. \n \nFix this by open coding xlog_logrec_hblks and taking the fixed h_size \ninto account for this calculation. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:11.000000Z"}, {"uuid": "809e9cc9-2331-4334-a353-56bc548145ad", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39476", "type": "seen", "source": "https://t.me/cvedetector/83", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39476 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39476 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmd/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING \n \nXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with \nsmall possibility, the root cause is exactly the same as commit \nbed9e27baf52 (\"Revert \"md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d\"\") \n \nHowever, Dan reported another hang after that, and junxiao investigated \nthe problem and found out that this is caused by plugged bio can't issue \nfrom raid5d(). \n \nCurrent implementation in raid5d() has a weird dependence: \n \n1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear \n   MD_SB_CHANGE_PENDING; \n2) raid5d() handles IO in a deadloop, until all IO are issued; \n3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; \n \nThis behaviour is introduce before v2.6, and for consequence, if other \ncontext hold 'reconfig_mutex', and md_check_recovery() can't update \nsuper_block, then raid5d() will waste one cpu 100% by the deadloop, until \n'reconfig_mutex' is released. \n \nRefer to the implementation from raid1 and raid10, fix this problem by \nskipping issue IO if MD_SB_CHANGE_PENDING is still set after \nmd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' \nis released. Meanwhile, the hang problem will be fixed as well. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:06.000000Z"}, {"uuid": "25cff427-f302-4ee2-99cb-cf03e7494ea9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-39479", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "8e16da35-cf0a-4993-94ec-22d09e7707ca", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39474", "type": "seen", "source": "https://t.me/cvedetector/81", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39474 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39474 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL \n \ncommit a421ef303008 (\"mm: allow !GFP_KERNEL allocations for kvmalloc\") \nincludes support for __GFP_NOFAIL, but it presents a conflict with commit \ndd544141b9eb (\"vmalloc: back off when the current task is OOM-killed\").  A \npossible scenario is as follows: \n \nprocess-a \n__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) \n    __vmalloc_area_node() \n        vm_area_alloc_pages() \n  --> oom-killer send SIGKILL to process-a \n        if (fatal_signal_pending(current)) break; \n--> return NULL; \n \nTo fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() \nif __GFP_NOFAIL set. \n \nThis issue occurred during OPLUS KASAN TEST. Below is part of the log \n-> oom-killer sends signal to process \n[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 \n \n[65731.259685] [T32454] Call trace: \n[65731.259698] [T32454]  dump_backtrace+0xf4/0x118 \n[65731.259734] [T32454]  show_stack+0x18/0x24 \n[65731.259756] [T32454]  dump_stack_lvl+0x60/0x7c \n[65731.259781] [T32454]  dump_stack+0x18/0x38 \n[65731.259800] [T32454]  mrdump_common_die+0x250/0x39c [mrdump] \n[65731.259936] [T32454]  ipanic_die+0x20/0x34 [mrdump] \n[65731.260019] [T32454]  atomic_notifier_call_chain+0xb4/0xfc \n[65731.260047] [T32454]  notify_die+0x114/0x198 \n[65731.260073] [T32454]  die+0xf4/0x5b4 \n[65731.260098] [T32454]  die_kernel_fault+0x80/0x98 \n[65731.260124] [T32454]  __do_kernel_fault+0x160/0x2a8 \n[65731.260146] [T32454]  do_bad_area+0x68/0x148 \n[65731.260174] [T32454]  do_mem_abort+0x151c/0x1b34 \n[65731.260204] [T32454]  el1_abort+0x3c/0x5c \n[65731.260227] [T32454]  el1h_64_sync_handler+0x54/0x90 \n[65731.260248] [T32454]  el1h_64_sync+0x68/0x6c \n \n[65731.260269] [T32454]  z_erofs_decompress_queue+0x7f0/0x2258 \n--> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); \n kernel panic by NULL pointer dereference. \n erofs assume kvmalloc with __GFP_NOFAIL never return NULL. \n[65731.260293] [T32454]  z_erofs_runqueue+0xf30/0x104c \n[65731.260314] [T32454]  z_erofs_readahead+0x4f0/0x968 \n[65731.260339] [T32454]  read_pages+0x170/0xadc \n[65731.260364] [T32454]  page_cache_ra_unbounded+0x874/0xf30 \n[65731.260388] [T32454]  page_cache_ra_order+0x24c/0x714 \n[65731.260411] [T32454]  filemap_fault+0xbf0/0x1a74 \n[65731.260437] [T32454]  __do_fault+0xd0/0x33c \n[65731.260462] [T32454]  handle_mm_fault+0xf74/0x3fe0 \n[65731.260486] [T32454]  do_mem_abort+0x54c/0x1b34 \n[65731.260509] [T32454]  el0_da+0x44/0x94 \n[65731.260531] [T32454]  el0t_64_sync_handler+0x98/0xb4 \n[65731.260553] [T32454]  el0t_64_sync+0x198/0x19c \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:04.000000Z"}, {"uuid": "97bde658-7387-4e21-889c-06d042cc21d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39479", "type": "seen", "source": "https://t.me/cvedetector/90", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39479 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39479 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/i915/hwmon: Get rid of devm \n \nWhen both hwmon and hwmon drvdata (on which hwmon depends) are device \nmanaged resources, the expectation, on device unbind, is that hwmon will be \nreleased before drvdata. However, in i915 there are two separate code \npaths, which both release either drvdata or hwmon and either can be \nreleased before the other. These code paths (for device unbind) are as \nfollows (see also the bug referenced below): \n \nCall Trace: \nrelease_nodes+0x11/0x70 \ndevres_release_group+0xb2/0x110 \ncomponent_unbind_all+0x8d/0xa0 \ncomponent_del+0xa5/0x140 \nintel_pxp_tee_component_fini+0x29/0x40 [i915] \nintel_pxp_fini+0x33/0x80 [i915] \ni915_driver_remove+0x4c/0x120 [i915] \ni915_pci_remove+0x19/0x30 [i915] \npci_device_remove+0x32/0xa0 \ndevice_release_driver_internal+0x19c/0x200 \nunbind_store+0x9c/0xb0 \n \nand \n \nCall Trace: \nrelease_nodes+0x11/0x70 \ndevres_release_all+0x8a/0xc0 \ndevice_unbind_cleanup+0x9/0x70 \ndevice_release_driver_internal+0x1c1/0x200 \nunbind_store+0x9c/0xb0 \n \nThis means that in i915, if use devm, we cannot gurantee that hwmon will \nalways be released before drvdata. Which means that we have a uaf if hwmon \nsysfs is accessed when drvdata has been released but hwmon hasn't. \n \nThe only way out of this seems to be do get rid of devm_ and release/free \neverything explicitly during device unbind. \n \nv2: Change commit message and other minor code changes \nv3: Cleanup from i915_hwmon_register on error (Armin Wolf) \nv4: Eliminate potential static analyzer warning (Rodrigo) \n    Eliminate fetch_and_zero (Jani) \nv5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:18.000000Z"}, {"uuid": "8e8abd16-524a-4e53-96f4-308e8414cbd6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39475", "type": "seen", "source": "https://t.me/cvedetector/89", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39475 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39475 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nfbdev: savage: Handle err return when savagefb_check_var failed \n \nThe commit 04e5eac8f3ab(\"fbdev: savage: Error out if pixclock equals zero\") \nchecks the value of pixclock to avoid divide-by-zero error. However \nthe function savagefb_probe doesn't handle the error return of \nsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:17.000000Z"}, {"uuid": "52b33ae2-9a00-4cc6-a446-4994a431bdef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39477", "type": "seen", "source": "https://t.me/cvedetector/87", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39477 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39477 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmm/hugetlb: do not call vma_add_reservation upon ENOMEM \n \nsysbot reported a splat [1] on __unmap_hugepage_range().  This is because \nvma_needs_reservation() can return -ENOMEM if \nallocate_file_region_entries() fails to allocate the file_region struct \nfor the reservation. \n \nCheck for that and do not call vma_add_reservation() if that is the case, \notherwise region_abort() and region_del() will see that we do not have any \nfile_regions. \n \nIf we detect that vma_needs_reservation() returned -ENOMEM, we clear the \nhugetlb_restore_reserve flag as if this reservation was still consumed, so \nfree_huge_folio() will not increment the resv count. \n \n[1]  \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:12.000000Z"}, {"uuid": "ec54fcce-9373-49a4-b648-83582ab89a3f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39478", "type": "seen", "source": "https://t.me/cvedetector/79", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39478 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39478 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ncrypto: starfive - Do not free stack buffer \n \nRSA text data uses variable length buffer allocated in software stack. \nCalling kfree on it causes undefined behaviour in subsequent operations. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:03.000000Z"}, {"uuid": "1afca99d-321e-4565-a375-34664398a736", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39473", "type": "seen", "source": "https://t.me/cvedetector/92", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39473 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39473 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension \n \nIf a process module does not have base config extension then the same \nformat applies to all of it's inputs and the process->base_config_ext is \nNULL, causing NULL dereference when specifically crafted topology and \nsequences used. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:20.000000Z"}]}