{"vulnerability": "cve-2024-5006", "sightings": [{"uuid": "403de663-a527-4836-a276-fbfd1bcad666", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50066", "type": "seen", "source": "https://u1f383.github.io/linux/2025/01/12/memory-related-cves-exploited-in-kernelctf.html", "content": "", "creation_timestamp": "2025-01-11T23:00:00.000000Z"}, {"uuid": "1613c8cf-3a30-4e33-9ecc-1be908397c8e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50067", "type": "seen", "source": "https://bsky.app/profile/o2cloud.bsky.social/post/3mbynkk7rzk2z", "content": "", "creation_timestamp": "2026-01-09T13:55:34.080819Z"}, {"uuid": "63462484-2f8f-4830-9c2f-12c64f24ee0a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50067", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "5a8f352d-1bef-426b-ab20-af93abed9ed4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50060", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "4cdaff45-7021-40b9-aebe-578202423e92", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-50060", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "a5fa6954-788a-442e-a05c-d8bbe219bdbc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50061", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "7896990b-d6f9-47d6-909b-8528352393fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50062", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "eab0b18a-9a58-4552-a1dd-8d2b3c780175", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-50063", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "3715dbfc-a189-4c0c-a217-44a326d4334f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50061", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/4893", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-50061\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition\n\nIn the cdns_i3c_master_probe function, &master->hj_work is bound with\ncdns_i3c_master_hj. And cdns_i3c_master_interrupt can call\ncnds_i3c_master_demux_ibis function to start the work.\n\nIf we remove the module which will call cdns_i3c_master_remove to\nmake cleanup, it will free master->base through i3c_master_unregister\nwhile the work mentioned above will be used. The sequence of operations\nthat may lead to a UAF bug is as follows:\n\nCPU0                                      CPU1\n\n                                     | cdns_i3c_master_hj\ncdns_i3c_master_remove               |\ni3c_master_unregister(&master->base) |\ndevice_unregister(&master->dev)      |\ndevice_release                       |\n//free master->base                  |\n                                     | i3c_master_do_daa(&master->base)\n                                     | //use master->base\n\nFix it by ensuring that the work is canceled before proceeding with\nthe cleanup in cdns_i3c_master_remove.\n\ud83d\udccf Published: 2024-10-21T19:39:50.415Z\n\ud83d\udccf Modified: 2025-02-21T13:45:14.131Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/2a21bad9964c91b34d65ba269914233720c0b1ce\n2. https://git.kernel.org/stable/c/ea0256e393e0072e8c80fd941547807f0c28108b\n3. https://git.kernel.org/stable/c/687016d6a1efbfacdd2af913e2108de6b75a28d5\n4. https://git.kernel.org/stable/c/609366e7a06d035990df78f1562291c3bf0d4a12", "creation_timestamp": "2025-02-21T14:18:31.000000Z"}, {"uuid": "6d2c03b2-98a4-4952-a38d-ee49348f2a00", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-50067", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0395/", "content": "", "creation_timestamp": "2026-04-02T17:00:00.000000Z"}, {"uuid": "020ecfc6-14b7-4541-bf2c-5f30acce868e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50066", "type": "seen", "source": "https://t.me/cvedetector/8674", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50066 - Linux Kernel tmpfs mremap Privilege Escalation Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50066 \nPublished : Oct. 23, 2024, 6:15 a.m. | 38\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/mremap: fix move_normal_pmd/retract_page_tables race  \n  \nIn mremap(), move_page_tables() looks at the type of the PMD entry and the  \nspecified address range to figure out by which method the next chunk of  \npage table entries should be moved.  \n  \nAt that point, the mmap_lock is held in write mode, but no rmap locks are  \nheld yet.  For PMD entries that point to page tables and are fully covered  \nby the source address range, move_pgt_entry(NORMAL_PMD, ...) is called,  \nwhich first takes rmap locks, then does move_normal_pmd().   \nmove_normal_pmd() takes the necessary page table locks at source and  \ndestination, then moves an entire page table from the source to the  \ndestination.  \n  \nThe problem is: The rmap locks, which protect against concurrent page  \ntable removal by retract_page_tables() in the THP code, are only taken  \nafter the PMD entry has been read and it has been decided how to move it.   \nSo we can race as follows (with two processes that have mappings of the  \nsame tmpfs file that is stored on a tmpfs mount with huge=advise); note  \nthat process A accesses page tables through the MM while process B does it  \nthrough the file rmap:  \n  \nprocess A                      process B  \n=========                      =========  \nmremap  \n  mremap_to  \n    move_vma  \n      move_page_tables  \n        get_old_pmd  \n        alloc_new_pmd  \n                      *** PREEMPT ***  \n                               madvise(MADV_COLLAPSE)  \n                                 do_madvise  \n                                   madvise_walk_vmas  \n                                     madvise_vma_behavior  \n                                       madvise_collapse  \n                                         hpage_collapse_scan_file  \n                                           collapse_file  \n                                             retract_page_tables  \n                                               i_mmap_lock_read(mapping)  \n                                               pmdp_collapse_flush  \n                                               i_mmap_unlock_read(mapping)  \n        move_pgt_entry(NORMAL_PMD, ...)  \n          take_rmap_locks  \n          move_normal_pmd  \n          drop_rmap_locks  \n  \nWhen this happens, move_normal_pmd() can end up creating bogus PMD entries  \nin the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`.  The effect  \ndepends on arch-specific and machine-specific details; on x86, you can end  \nup with physical page 0 mapped as a page table, which is likely  \nexploitable for user->kernel privilege escalation.  \n  \nFix the race by letting process B recheck that the PMD still points to a  \npage table after the rmap locks have been taken.  Otherwise, we bail and  \nlet the caller fall back to the PTE-level copying path, which will then  \nbail immediately at the pmd_none() check.  \n  \nBug reachability: Reaching this bug requires that you can create  \nshmem/file THP mappings - anonymous THP uses different code that doesn't  \nzap stuff under rmap locks.  File THP is gated on an experimental config  \nflag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need  \nshmem THP to hit this bug.  As far as I know, getting shmem THP normally  \nrequires that you can mount your own tmpfs with the right mount flags,  \nwhich would require creating your own user+mount namespace; though I don't  \nknow if some distros maybe enable shmem THP by default or something like  \nthat.  \n  \nBug impact: This issue can likely be used for user->kernel privilege  \nescalation when it is reachable. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"23 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-23T09:01:36.000000Z"}, {"uuid": "f18c84f3-9bb1-48a6-ac56-5ccba5e223e3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50066", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/6849", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-50066\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mremap: fix move_normal_pmd/retract_page_tables race\n\nIn mremap(), move_page_tables() looks at the type of the PMD entry and the\nspecified address range to figure out by which method the next chunk of\npage table entries should be moved.\n\nAt that point, the mmap_lock is held in write mode, but no rmap locks are\nheld yet.  For PMD entries that point to page tables and are fully covered\nby the source address range, move_pgt_entry(NORMAL_PMD, ...) is called,\nwhich first takes rmap locks, then does move_normal_pmd(). \nmove_normal_pmd() takes the necessary page table locks at source and\ndestination, then moves an entire page table from the source to the\ndestination.\n\nThe problem is: The rmap locks, which protect against concurrent page\ntable removal by retract_page_tables() in the THP code, are only taken\nafter the PMD entry has been read and it has been decided how to move it. \nSo we can race as follows (with two processes that have mappings of the\nsame tmpfs file that is stored on a tmpfs mount with huge=advise); note\nthat process A accesses page tables through the MM while process B does it\nthrough the file rmap:\n\nprocess A                      process B\n=========                      =========\nmremap\n  mremap_to\n    move_vma\n      move_page_tables\n        get_old_pmd\n        alloc_new_pmd\n                      *** PREEMPT ***\n                               madvise(MADV_COLLAPSE)\n                                 do_madvise\n                                   madvise_walk_vmas\n                                     madvise_vma_behavior\n                                       madvise_collapse\n                                         hpage_collapse_scan_file\n                                           collapse_file\n                                             retract_page_tables\n                                               i_mmap_lock_read(mapping)\n                                               pmdp_collapse_flush\n                                               i_mmap_unlock_read(mapping)\n        move_pgt_entry(NORMAL_PMD, ...)\n          take_rmap_locks\n          move_normal_pmd\n          drop_rmap_locks\n\nWhen this happens, move_normal_pmd() can end up creating bogus PMD entries\nin the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`.  The effect\ndepends on arch-specific and machine-specific details; on x86, you can end\nup with physical page 0 mapped as a page table, which is likely\nexploitable for user->kernel privilege escalation.\n\nFix the race by letting process B recheck that the PMD still points to a\npage table after the rmap locks have been taken.  Otherwise, we bail and\nlet the caller fall back to the PTE-level copying path, which will then\nbail immediately at the pmd_none() check.\n\nBug reachability: Reaching this bug requires that you can create\nshmem/file THP mappings - anonymous THP uses different code that doesn't\nzap stuff under rmap locks.  File THP is gated on an experimental config\nflag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need\nshmem THP to hit this bug.  As far as I know, getting shmem THP normally\nrequires that you can mount your own tmpfs with the right mount flags,\nwhich would require creating your own user+mount namespace; though I don't\nknow if some distros maybe enable shmem THP by default or something like\nthat.\n\nBug impact: This issue can likely be used for user->kernel privilege\nescalation when it is reachable.\n\ud83d\udccf Published: 2024-10-23T05:20:37.942Z\n\ud83d\udccf Modified: 2025-03-07T16:19:11.266Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/17396e32f975130b3e6251f024c8807d192e4c3e\n2. https://git.kernel.org/stable/c/1552ce9ce8af47c0fe911682e5e1855e25851ca9\n3. https://git.kernel.org/stable/c/6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa\n4. https://project-zero.issues.chromium.org/issues/371047675", "creation_timestamp": "2025-03-07T16:35:19.000000Z"}, {"uuid": "55eec153-2ca5-49d6-adf6-73d7763b9db6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50063", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/13400", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-50063\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent tail call between progs attached to different hooks\n\nbpf progs can be attached to kernel functions, and the attached functions\ncan take different parameters or return different return values. If\nprog attached to one kernel function tail calls prog attached to another\nkernel function, the ctx access or return value verification could be\nbypassed.\n\nFor example, if prog1 is attached to func1 which takes only 1 parameter\nand prog2 is attached to func2 which takes two parameters. Since verifier\nassumes the bpf ctx passed to prog2 is constructed based on func2's\nprototype, verifier allows prog2 to access the second parameter from\nthe bpf ctx passed to it. The problem is that verifier does not prevent\nprog1 from passing its bpf ctx to prog2 via tail call. In this case,\nthe bpf ctx passed to prog2 is constructed from func1 instead of func2,\nthat is, the assumption for ctx access verification is bypassed.\n\nAnother example, if BPF LSM prog1 is attached to hook file_alloc_security,\nand BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier\nknows the return value rules for these two hooks, e.g. it is legal for\nbpf_lsm_audit_rule_known to return positive number 1, and it is illegal\nfor file_alloc_security to return positive number. So verifier allows\nprog2 to return positive number 1, but does not allow prog1 to return\npositive number. The problem is that verifier does not prevent prog1\nfrom calling prog2 via tail call. In this case, prog2's return value 1\nwill be used as the return value for prog1's hook file_alloc_security.\nThat is, the return value rule is bypassed.\n\nThis patch adds restriction for tail call to prevent such bypasses.\n\ud83d\udccf Published: 2024-10-21T19:39:51.718Z\n\ud83d\udccf Modified: 2025-04-25T10:06:42.681Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/d9a807fb7cbfad4328824186e2e4bee28f72169b\n2. https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1\n3. https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1\n4. https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356", "creation_timestamp": "2025-04-25T11:07:43.000000Z"}, {"uuid": "7e15789a-156b-49e6-a5b0-23211343adc1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50065", "type": "seen", "source": "https://t.me/cvedetector/8552", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50065 - Linux NTFS3 RCU Wait Sleepfulness\", \n  \"Content\": \"CVE ID : CVE-2024-50065 \nPublished : Oct. 21, 2024, 8:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nntfs3: Change to non-blocking allocation in ntfs_d_hash  \n  \nd_hash is done while under \"rcu-walk\" and should not sleep.  \n__get_name() allocates using GFP_KERNEL, having the possibility  \nto sleep when under memory pressure. Change the allocation to  \nGFP_NOWAIT. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T22:43:02.000000Z"}, {"uuid": "bc57f7ec-00cc-4936-852f-4fc4fff83913", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50063", "type": "seen", "source": "https://t.me/cvedetector/8551", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50063 - \"Linux Kernel BPF Tail Call Exploit\"\", \n  \"Content\": \"CVE ID : CVE-2024-50063 \nPublished : Oct. 21, 2024, 8:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Prevent tail call between progs attached to different hooks  \n  \nbpf progs can be attached to kernel functions, and the attached functions  \ncan take different parameters or return different return values. If  \nprog attached to one kernel function tail calls prog attached to another  \nkernel function, the ctx access or return value verification could be  \nbypassed.  \n  \nFor example, if prog1 is attached to func1 which takes only 1 parameter  \nand prog2 is attached to func2 which takes two parameters. Since verifier  \nassumes the bpf ctx passed to prog2 is constructed based on func2's  \nprototype, verifier allows prog2 to access the second parameter from  \nthe bpf ctx passed to it. The problem is that verifier does not prevent  \nprog1 from passing its bpf ctx to prog2 via tail call. In this case,  \nthe bpf ctx passed to prog2 is constructed from func1 instead of func2,  \nthat is, the assumption for ctx access verification is bypassed.  \n  \nAnother example, if BPF LSM prog1 is attached to hook file_alloc_security,  \nand BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier  \nknows the return value rules for these two hooks, e.g. it is legal for  \nbpf_lsm_audit_rule_known to return positive number 1, and it is illegal  \nfor file_alloc_security to return positive number. So verifier allows  \nprog2 to return positive number 1, but does not allow prog1 to return  \npositive number. The problem is that verifier does not prevent prog1  \nfrom calling prog2 via tail call. In this case, prog2's return value 1  \nwill be used as the return value for prog1's hook file_alloc_security.  \nThat is, the return value rule is bypassed.  \n  \nThis patch adds restriction for tail call to prevent such bypasses. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T22:43:01.000000Z"}, {"uuid": "bfbf747a-9268-4ead-a328-8b1d39921d68", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50062", "type": "seen", "source": "https://t.me/cvedetector/8550", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50062 - \"RTRSrv Linux Kernel Null Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-50062 \nPublished : Oct. 21, 2024, 8:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nRDMA/rtrs-srv: Avoid null pointer deref during path establishment  \n  \nFor RTRS path establishment, RTRS client initiates and completes con_num  \nof connections. After establishing all its connections, the information  \nis exchanged between the client and server through the info_req message.  \nDuring this exchange, it is essential that all connections have been  \nestablished, and the state of the RTRS srv path is CONNECTED.  \n  \nSo add these sanity checks, to make sure we detect and abort process in  \nerror scenarios to avoid null pointer deref. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T22:42:57.000000Z"}, {"uuid": "0f675908-2775-424f-8168-0ba56ab4901b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50061", "type": "seen", "source": "https://t.me/cvedetector/8549", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50061 - Linux i3c: Master: cdns: Use After Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50061 \nPublished : Oct. 21, 2024, 8:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ni3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition  \n  \nIn the cdns_i3c_master_probe function, &master->hj_work is bound with  \ncdns_i3c_master_hj. And cdns_i3c_master_interrupt can call  \ncnds_i3c_master_demux_ibis function to start the work.  \n  \nIf we remove the module which will call cdns_i3c_master_remove to  \nmake cleanup, it will free master->base through i3c_master_unregister  \nwhile the work mentioned above will be used. The sequence of operations  \nthat may lead to a UAF bug is as follows:  \n  \nCPU0                                      CPU1  \n  \n                                     | cdns_i3c_master_hj  \ncdns_i3c_master_remove               |  \ni3c_master_unregister(&master->base) |  \ndevice_unregister(&master->dev)      |  \ndevice_release                       |  \n//free master->base                  |  \n                                     | i3c_master_do_daa(&master->base)  \n                                     | //use master->base  \n  \nFix it by ensuring that the work is canceled before proceeding with  \nthe cleanup in cdns_i3c_master_remove. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T22:42:56.000000Z"}, {"uuid": "cc36fe2c-a3c5-468b-aa20-cd849c7023ea", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50064", "type": "seen", "source": "https://t.me/cvedetector/8547", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50064 - Linux zram Memory Leak\", \n  \"Content\": \"CVE ID : CVE-2024-50064 \nPublished : Oct. 21, 2024, 8:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nzram: free secondary algorithms names  \n  \nWe need to kfree() secondary algorithms names when reset zram device that  \nhad multi-streams, otherwise we leak memory.  \n  \n[senozhatsky@chromium.org: kfree(NULL) is legal]  \n  Link:  \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T22:42:55.000000Z"}, {"uuid": "d5c5e54d-6c57-4542-b5f0-4e59e11baafb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50060", "type": "seen", "source": "https://t.me/cvedetector/8546", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50060 - Apache Io_uring Lock Lack of Overflow Defense\", \n  \"Content\": \"CVE ID : CVE-2024-50060 \nPublished : Oct. 21, 2024, 8:15 p.m. | 16\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nio_uring: check if we need to reschedule during overflow flush  \n  \nIn terms of normal application usage, this list will always be empty.  \nAnd if an application does overflow a bit, it'll have a few entries.  \nHowever, nothing obviously prevents syzbot from running a test case  \nthat generates a ton of overflow entries, and then flushing them can  \ntake quite a while.  \n  \nCheck for needing to reschedule while flushing, and drop our locks and  \ndo so if necessary. There's no state to maintain here as overflows  \nalways prune from head-of-list, hence it's fine to drop and reacquire  \nthe locks at the end of the loop. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T22:42:54.000000Z"}, {"uuid": "58dd0a16-28f6-4794-a34f-21ab8414f58c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50067", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/9084", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50067 - \"Linux kernel uprobe vulnerability: Out-of-bounds memory access of fetching args\"\", \n  \"Content\": \"CVE ID : CVE-2024-50067 \nPublished : Oct. 28, 2024, 1:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nuprobe: avoid out-of-bounds memory access of fetching args  \n  \nUprobe needs to fetch args into a percpu buffer, and then copy to ring  \nbuffer to avoid non-atomic context problem.  \n  \nSometimes user-space strings, arrays can be very large, but the size of  \npercpu buffer is only page size. And store_trace_args() won't check  \nwhether these data exceeds a single page or not, caused out-of-bounds  \nmemory access.  \n  \nIt could be reproduced by following steps:  \n1. build kernel with CONFIG_KASAN enabled  \n2. save follow program as test.c  \n  \n```  \n\\#include   \n\\#include   \n\\#include   \n  \n// If string length large than MAX_STRING_SIZE, the fetch_store_strlen()  \n// will return 0, cause __get_data_size() return shorter size, and  \n// store_trace_args() will not trigger out-of-bounds access.  \n// So make string length less than 4096.  \n\\#define STRLEN 4093  \n  \nvoid generate_string(char *str, int n)  \n{  \n    int i;  \n    for (i = 0; i < n; ++i)  \n    {  \n        char c = i % 26 + 'a';  \n        str[i] = c;  \n    }  \n    str[n-1] = '\\0';  \n}  \n  \nvoid print_string(char *str)  \n{  \n    printf(\"%s\\n\", str);  \n}  \n  \nint main()  \n{  \n    char tmp[STRLEN];  \n  \n    generate_string(tmp, STRLEN);  \n    print_string(tmp);  \n  \n    return 0;  \n}  \n```  \n3. compile program  \n`gcc -o test test.c`  \n  \n4. get the offset of `print_string()`  \n```  \nobjdump -t test | grep -w print_string  \n0000000000401199 g     F .text  000000000000001b              print_string  \n```  \n  \n5. configure uprobe with offset 0x1199  \n```  \noff=0x1199  \n  \ncd /sys/kernel/debug/tracing/  \necho \"p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\"  \n > uprobe_events  \necho 1 > events/uprobes/enable  \necho 1 > tracing_on  \n```  \n  \n6. run `test`, and kasan will report error.  \n==================================================================  \nBUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0  \nWrite of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18  \nHardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014  \nCall Trace:  \n   \n dump_stack_lvl+0x55/0x70  \n print_address_description.constprop.0+0x27/0x310  \n kasan_report+0x10f/0x120  \n ? strncpy_from_user+0x1d6/0x1f0  \n strncpy_from_user+0x1d6/0x1f0  \n ? rmqueue.constprop.0+0x70d/0x2ad0  \n process_fetch_insn+0xb26/0x1470  \n ? __pfx_process_fetch_insn+0x10/0x10  \n ? _raw_spin_lock+0x85/0xe0  \n ? __pfx__raw_spin_lock+0x10/0x10  \n ? __pte_offset_map+0x1f/0x2d0  \n ? unwind_next_frame+0xc5f/0x1f80  \n ? arch_stack_walk+0x68/0xf0  \n ? is_bpf_text_address+0x23/0x30  \n ? kernel_text_address.part.0+0xbb/0xd0  \n ? __kernel_text_address+0x66/0xb0  \n ? unwind_get_return_address+0x5e/0xa0  \n ? __pfx_stack_trace_consume_entry+0x10/0x10  \n ? arch_stack_walk+0xa2/0xf0  \n ? _raw_spin_lock_irqsave+0x8b/0xf0  \n ? __pfx__raw_spin_lock_irqsave+0x10/0x10  \n ? depot_alloc_stack+0x4c/0x1f0  \n ? _raw_spin_unlock_irqrestore+0xe/0x30  \n ? stack_depot_save_flags+0x35d/0x4f0  \n ? kasan_save_stack+0x34/0x50  \n ? kasan_save_stack+0x24/0x50  \n ? mutex_lock+0x91/0xe0  \n ? __pfx_mutex_lock+0x10/0x10  \n prepare_uprobe_buffer.part.0+0x2cd/0x500  \n uprobe_dispatcher+0x2c3/0x6a0  \n ? __pfx_uprobe_dispatcher+0x10/0x10  \n ? __kasan_slab_alloc+0x4d/0x90  \n handler_chain+0xdd/0x3e0  \n handle_swbp+0x26e/0x3d0  \n ? __pfx_handle_swbp+0x10/0x10  \n ? uprobe_pre_sstep_notifier+0x151/0x1b0  \n irqentry_exit_to_user_mode+0xe2/0x1b0  \n asm_exc_int3+0x39/0x40  \nRIP: 0033:0x401199  \nCode: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce  \nRSP: 002b:00007ffdf00576a8 EFLAGS: 00000206  \nRAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 000000000000[...]", "creation_timestamp": "2024-10-28T02:46:40.000000Z"}, {"uuid": "eb1d4e01-1d61-47b1-8c4c-22341ee483a8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50069", "type": "seen", "source": "https://t.me/cvedetector/9240", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50069 - Apple Pinctrl NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50069 \nPublished : Oct. 29, 2024, 1:15 a.m. | 38\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npinctrl: apple: check devm_kasprintf() returned value  \n  \ndevm_kasprintf() can return a NULL pointer on failure but this returned  \nvalue is not checked. Fix this lack and check the returned value.  \n  \nFound by code review. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-29T03:03:55.000000Z"}, {"uuid": "d9d534f9-b943-41b4-8101-ec9d2ce3f05d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50068", "type": "seen", "source": "https://t.me/cvedetector/9235", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50068 - Linux Kernel DAMON - Memory Leak\", \n  \"Content\": \"CVE ID : CVE-2024-50068 \nPublished : Oct. 29, 2024, 1:15 a.m. | 38\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets()  \n  \nThe sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not  \nfreed in damon_sysfs_test_add_targets(), which cause the following memory  \nleak, free it to fix it.  \n  \n unreferenced object 0xffffff80c2a8db80 (size 96):  \n   comm \"kunit_try_catch\", pid 187, jiffies 4294894363  \n   hex dump (first 32 bytes):  \n     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  \n     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  \n   backtrace (crc 0):  \n     [<0000000001e3714d] kmemleak_alloc+0x34/0x40  \n     [<000000008e6835c1] __kmalloc_cache_noprof+0x26c/0x2f4  \n     [<000000001286d9f8] damon_sysfs_test_add_targets+0x1cc/0x738  \n     [<0000000032ef8f77] kunit_try_run_case+0x13c/0x3ac  \n     [<00000000f3edea23] kunit_generic_run_threadfn_adapter+0x80/0xec  \n     [<00000000adf936cf] kthread+0x2e8/0x374  \n     [<0000000041bb1628] ret_from_fork+0x10/0x20 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-29T03:03:13.000000Z"}, {"uuid": "5ef79fae-ef51-406e-95ad-fc8dc6081f87", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50066", "type": "seen", "source": "https://t.me/CyberSecurityTechnologies/11678", "content": "#Kernel_Security\n1. Ksmbd vulnerability research\n(CVE-2024-50283, CVE-2024-50285, CVE-2024-50286)\nhttps://blog.doyensec.com/2025/01/07/ksmbd-1.html\n2. Memory-related CVEs Exploited in kernelCTF (CVE-2023-3269, CVE-2024-50066)\nhttps://u1f383.github.io/linux/2025/01/12/memory-related-cves-exploited-in-kernelctf.html", "creation_timestamp": "2025-01-14T16:21:53.000000Z"}, {"uuid": "e9b70222-eb88-4d6b-82db-09efb9b94ec7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50066", "type": "seen", "source": "Telegram/m-Xj-3GWHT1q4KLJ7889XAI4ZWw-pLDgVrZBokC5ik3llZa9", "content": "", "creation_timestamp": "2025-03-08T04:35:51.000000Z"}]}