{"vulnerability": "cve-2024-4999", "sightings": [{"uuid": "e2d48b4a-0f1d-49f6-ad0a-689a8104882b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49997", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "90d86819-f286-462c-8b20-5f0e524f01c0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49993", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "6a3c2bf2-a104-4168-ab45-79dd655f00db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49995", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "4f9ac4e9-0a14-44d3-a68c-ba43c5f835b5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-49991", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "7e4eb89e-06db-4f2a-aa68-a5396044b46b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-49990", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "bea62aac-9fbb-492e-a0c8-2384564aeeb7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-49992", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "82cb0ef9-3437-4073-9a38-814b9af04f80", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-49991", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "3c0fd3ba-5a24-480b-b3b5-5a069aca9992", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-49992", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "84bc0f63-9bc4-4562-aa0e-4576444a02cb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-49994", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "36bf29a4-1cf4-4062-bcdb-bf6c445c1cbb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49991", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/16647", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2024-49991\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer\n\nPass pointer reference to amdgpu_bo_unref to clear the correct pointer,\notherwise amdgpu_bo_unref clear the local variable, the original pointer\nnot set to NULL, this could cause use-after-free bug.\n\ud83d\udccf Published: 2024-10-21T18:02:33.805Z\n\ud83d\udccf Modified: 2025-05-16T07:25:09.614Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/e7831613cbbcd9058d3658fbcdc5d5884ceb2e0c\n2. https://git.kernel.org/stable/c/30ceb873cc2e97348d9da2265b2d1ddf07f682e1\n3. https://git.kernel.org/stable/c/71f3240f82987f0f070ea5bed559033de7d4c0e1\n4. https://git.kernel.org/stable/c/6c9289806591807e4e3be9a23df8ee2069180055\n5. https://git.kernel.org/stable/c/c86ad39140bbcb9dc75a10046c2221f657e8083b", "creation_timestamp": "2025-05-16T07:33:58.000000Z"}, {"uuid": "f26899b6-2786-4937-9369-9729b328df19", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49993", "type": "seen", "source": "https://t.me/cvedetector/8514", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49993 - Intel VT-d IOMMU Lockup Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-49993 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \niommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count  \n  \nIf qi_submit_sync() is invoked with 0 invalidation descriptors (for  \ninstance, for DMA draining purposes), we can run into a bug where a  \nsubmitting thread fails to detect the completion of invalidation_wait.  \nSubsequently, this led to a soft lockup. Currently, there is no impact  \nby this bug on the existing users because no callers are submitting  \ninvalidations with 0 descriptors. This fix will enable future users  \n(such as DMA drain) calling qi_submit_sync() with 0 count.  \n  \nSuppose thread T1 invokes qi_submit_sync() with non-zero descriptors, while  \nconcurrently, thread T2 calls qi_submit_sync() with zero descriptors. Both  \nthreads then enter a while loop, waiting for their respective descriptors  \nto complete. T1 detects its completion (i.e., T1's invalidation_wait status  \nchanges to QI_DONE by HW) and proceeds to call reclaim_free_desc() to  \nreclaim all descriptors, potentially including adjacent ones of other  \nthreads that are also marked as QI_DONE.  \n  \nDuring this time, while T2 is waiting to acquire the qi->q_lock, the IOMMU  \nhardware may complete the invalidation for T2, setting its status to  \nQI_DONE. However, if T1's execution of reclaim_free_desc() frees T2's  \ninvalidation_wait descriptor and changes its status to QI_FREE, T2 will  \nnot observe the QI_DONE status for its invalidation_wait and will  \nindefinitely remain stuck.  \n  \nThis soft lockup does not occur when only non-zero descriptors are  \nsubmitted.In such cases, invalidation descriptors are interspersed among  \nwait descriptors with the status QI_IN_USE, acting as barriers. These  \nbarriers prevent the reclaim code from mistakenly freeing descriptors  \nbelonging to other submitters.  \n  \nConsidered the following example timeline:  \n T1   T2  \n========================================  \n ID1  \n WD1  \n while(WD1!=QI_DONE)  \n unlock  \n    lock  \n WD1=QI_DONE*  WD2  \n    while(WD2!=QI_DONE)  \n    unlock  \n lock  \n WD1==QI_DONE?  \n ID1=QI_DONE  WD2=DONE*  \n reclaim()  \n ID1=FREE  \n WD1=FREE  \n WD2=FREE  \n unlock  \n    soft lockup! T2 never sees QI_DONE in WD2  \n  \nWhere:  \nID = invalidation descriptor  \nWD = wait descriptor  \n* Written by hardware  \n  \nThe root of the problem is that the descriptor status QI_DONE flag is used  \nfor two conflicting purposes:  \n1. signal a descriptor is ready for reclaim (to be freed)  \n2. signal by the hardware that a wait descriptor is complete  \n  \nThe solution (in this patch) is state separation by using QI_FREE flag  \nfor #1.  \n  \nOnce a thread's invalidation descriptors are complete, their status would  \nbe set to QI_FREE. The reclaim_free_desc() function would then only  \nfree descriptors marked as QI_FREE instead of those marked as  \nQI_DONE. This change ensures that T2 (from the previous example) will  \ncorrectly observe the completion of its invalidation_wait (marked as  \nQI_DONE). \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-21T21:02:02.000000Z"}, {"uuid": "dfa9a982-3d9c-4084-afe1-82ec4bc9a37e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49992", "type": "seen", "source": "https://t.me/cvedetector/8513", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49992 - \"Linux Kernel DRM Use-After-Free Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-49992 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/stm: Avoid use-after-free issues with crtc and plane  \n  \nltdc_load() calls functions drm_crtc_init_with_planes(),  \ndrm_universal_plane_init() and drm_encoder_init(). These functions  \nshould not be called with parameters allocated with devm_kzalloc()  \nto avoid use-after-free issues [1].  \n  \nUse allocations managed by the DRM framework.  \n  \nFound by Linux Verification Center (linuxtesting.org).  \n  \n[1]  \n \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-21T21:02:01.000000Z"}, {"uuid": "739dd3ae-e7b6-4cc6-a844-db950ee41843", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49991", "type": "seen", "source": "https://t.me/cvedetector/8512", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49991 - AMD KFD Pass Pointer Use-After-Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-49991 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer  \n  \nPass pointer reference to amdgpu_bo_unref to clear the correct pointer,  \notherwise amdgpu_bo_unref clear the local variable, the original pointer  \nnot set to NULL, this could cause use-after-free bug. \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-21T21:02:00.000000Z"}, {"uuid": "c70d254f-59ba-442b-91d4-db812e7bea32", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49990", "type": "seen", "source": "https://t.me/cvedetector/8522", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49990 - Linux DRM XE HDCP Null Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2024-49990 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/xe/hdcp: Check GSC structure validity  \n  \nSometimes xe_gsc is not initialized when checked at HDCP capability  \ncheck. Add gsc structure check to avoid null pointer error. \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-21T21:02:15.000000Z"}, {"uuid": "374d7e27-4256-4111-9384-5482244ca4b6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49999", "type": "seen", "source": "https://t.me/cvedetector/8520", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49999 - IBM AFS NULL Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2024-49999 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nafs: Fix the setting of the server responding flag  \n  \nIn afs_wait_for_operation(), we set transcribe the call responded flag to  \nthe server record that we used after doing the fileserver iteration loop -  \nbut it's possible to exit the loop having had a response from the server  \nthat we've discarded (e.g. it returned an abort or we started receiving  \ndata, but the call didn't complete).  \n  \nThis means that op->server might be NULL, but we don't check that before  \nattempting to set the server flag. \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-21T21:02:10.000000Z"}, {"uuid": "d7076e53-4db5-41a3-a262-1cc96b9c2a91", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49998", "type": "seen", "source": "https://t.me/cvedetector/8519", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49998 - Samsung Lan9303 DSA Driver Uninitialized Driver Data Manipulation\", \n  \"Content\": \"CVE ID : CVE-2024-49998 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: dsa: improve shutdown sequence  \n  \nAlexander Sverdlin presents 2 problems during shutdown with the  \nlan9303 driver. One is specific to lan9303 and the other just happens  \nto reproduce there.  \n  \nThe first problem is that lan9303 is unique among DSA drivers in that it  \ncalls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown,  \nnot remove):  \n  \nphy_state_machine()  \n-> ...  \n   -> dsa_user_phy_read()  \n      -> ds->ops->phy_read()  \n         -> lan9303_phy_read()  \n            -> chip->ops->phy_read()  \n               -> lan9303_mdio_phy_read()  \n                  -> dev_get_drvdata()  \n  \nBut we never stop the phy_state_machine(), so it may continue to run  \nafter dsa_switch_shutdown(). Our common pattern in all DSA drivers is  \nto set drvdata to NULL to suppress the remove() method that may come  \nafterwards. But in this case it will result in an NPD.  \n  \nThe second problem is that the way in which we set  \ndp->conduit->dsa_ptr = NULL; is concurrent with receive packet  \nprocessing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL,  \nbut afterwards, rather than continuing to use that non-NULL value,  \ndev->dsa_ptr is dereferenced again and again without NULL checks:  \ndsa_conduit_find_user() and many other places. In between dereferences,  \nthere is no locking to ensure that what was valid once continues to be  \nvalid.  \n  \nBoth problems have the common aspect that closing the conduit interface  \nsolves them.  \n  \nIn the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN  \nevent in dsa_user_netdevice_event() which closes user ports as well.  \ndsa_port_disable_rt() calls phylink_stop(), which synchronously stops  \nthe phylink state machine, and ds->ops->phy_read() will thus no longer  \ncall into the driver after this point.  \n  \nIn the second case, dev_close(conduit) should do this, as per  \nDocumentation/networking/driver.rst:  \n  \n| Quiescence  \n| ----------  \n|  \n| After the ndo_stop routine has been called, the hardware must  \n| not receive or transmit any data.  All in flight packets must  \n| be aborted. If necessary, poll or wait for completion of  \n| any reset commands.  \n  \nSo it should be sufficient to ensure that later, when we zeroize  \nconduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call  \non this conduit.  \n  \nThe addition of the netif_device_detach() function is to ensure that  \nioctls, rtnetlinks and ethtool requests on the user ports no longer  \npropagate down to the driver - we're no longer prepared to handle them.  \n  \nThe race condition actually did not exist when commit 0650bf52b31f  \n(\"net: dsa: be compatible with masters which unregister on shutdown\")  \nfirst introduced dsa_switch_shutdown(). It was created later, when we  \nstopped unregistering the user interfaces from a bad spot, and we just  \nreplaced that sequence with a racy zeroization of conduit->dsa_ptr  \n(one which doesn't ensure that the interfaces aren't up). \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-21T21:02:09.000000Z"}, {"uuid": "6391098a-e91a-4479-a415-a02b5e768e24", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49997", "type": "seen", "source": "https://t.me/cvedetector/8518", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49997 - Amazon Danube Linux Ethernet Mac Zero-Length Padding Memory Disclosure Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-49997 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: ethernet: lantiq_etop: fix memory disclosure  \n  \nWhen applying padding, the buffer is not zeroed, which results in memory  \ndisclosure. The mentioned data is observed on the wire. This patch uses  \nskb_put_padto() to pad Ethernet frames properly. The mentioned function  \nzeroes the expanded buffer.  \n  \nIn case the packet cannot be padded it is silently dropped. Statistics  \nare also not incremented. This driver does not support statistics in the  \nold 32-bit format or the new 64-bit format. These will be added in the  \nfuture. In its current form, the patch should be easily backported to  \nstable versions.  \n  \nEthernet MACs on Amazon-SE and Danube cannot do padding of the packets  \nin hardware, so software padding must be applied. \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-21T21:02:08.000000Z"}, {"uuid": "a0aeec41-2003-46f2-b801-899b371f2d97", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49996", "type": "seen", "source": "https://t.me/cvedetector/8517", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49996 - CIFS Linux Kernel Buffer Overflow\", \n  \"Content\": \"CVE ID : CVE-2024-49996 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncifs: Fix buffer overflow when parsing NFS reparse points  \n  \nReparseDataLength is sum of the InodeType size and DataBuffer size.  \nSo to get DataBuffer size it is needed to subtract InodeType's size from  \nReparseDataLength.  \n  \nFunction cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer  \nat position after the end of the buffer because it does not subtract  \nInodeType size from the length. Fix this problem and correctly subtract  \nvariable len.  \n  \nMember InodeType is present only when reparse buffer is large enough. Check  \nfor ReparseDataLength before accessing InodeType to prevent another invalid  \nmemory access.  \n  \nMajor and minor rdev values are present also only when reparse buffer is  \nlarge enough. Check for reparse buffer size before calling reparse_mkdev(). \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-21T21:02:07.000000Z"}, {"uuid": "57041ff5-f4b3-48bd-a411-c581242c9c46", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49995", "type": "seen", "source": "https://t.me/cvedetector/8516", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49995 - Linux Kernel TIPC String Buffer Overrun ( strcpy/strscpy Buffer Overflow)\", \n  \"Content\": \"CVE ID : CVE-2024-49995 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntipc: guard against string buffer overrun  \n  \nSmatch reports that copying media_name and if_name to name_parts may  \noverwrite the destination.  \n  \n .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16)  \n .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16)  \n  \nThis does seem to be the case so guard against this possibility by using  \nstrscpy() and failing if truncation occurs.  \n  \nIntroduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\")  \n  \nCompile tested only. \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-21T21:02:06.000000Z"}, {"uuid": "d6778188-82ec-4bb0-9e45-26a8e329a8bf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-49994", "type": "seen", "source": "https://t.me/cvedetector/8515", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-49994 - \"Linux Kernel BLKSECDISCARD Integer Overflow Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-49994 \nPublished : Oct. 21, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nblock: fix integer overflow in BLKSECDISCARD  \n  \nI independently rediscovered  \n  \n commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155  \n block: fix overflow in blk_ioctl_discard()  \n  \nbut for secure erase.  \n  \nSame problem:  \n  \n uint64_t r[2] = {512, 18446744073709551104ULL};  \n ioctl(fd, BLKSECDISCARD, r);  \n  \nwill enter near infinite loop inside blkdev_issue_secure_erase():  \n  \n a.out: attempt to access beyond end of device  \n loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048  \n bio_check_eod: 3286214 callbacks suppressed \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-21T21:02:03.000000Z"}, {"uuid": "a1da8ac2-e72c-4464-a8d2-d598b3bcdfd4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-49998", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260506", "content": "", "creation_timestamp": "2026-05-05T20:00:00.000000Z"}]}