{"vulnerability": "CVE-2025-2197", "sightings": [{"uuid": "17ab2099-6092-43aa-9b89-9fc5d7353e2b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2197", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lmywmxy5t42l", "content": "", "creation_timestamp": "2025-04-17T10:48:56.585685Z"}, {"uuid": "55339203-bb60-4f0e-a402-0a1893573408", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21976", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "9029a327-14b4-4fed-a680-02f1ebe2880c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21972", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "a04bb09a-4a93-4848-85a3-3f29097b3fd9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2025-21976", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "78577bbc-cd06-4c68-b059-54ab0eb44b33", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2197", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/12204", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-2197\n\ud83d\udd25 CVSS Score: 4.3 (cvssV3_1, Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L)\n\ud83d\udd39 Description: Browser is affected by type confusion vulnerability, successful exploitation of this vulnerability may affect service availability.\n\ud83d\udccf Published: 2025-04-17T09:25:46.870Z\n\ud83d\udccf Modified: 2025-04-17T09:25:46.870Z\n\ud83d\udd17 References:\n1. https://www.honor.com/global/security/cve-2025-2197/", "creation_timestamp": "2025-04-17T09:59:08.000000Z"}, {"uuid": "ffc029c6-1cc9-4f3b-aecc-01241ef9c3d5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2197", "type": "seen", "source": "https://t.me/cvedetector/23226", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-2197 - \"Mozilla Browser Type Confusion RCE\"\", \n  \"Content\": \"CVE ID : CVE-2025-2197 \nPublished : April 17, 2025, 10:15 a.m. | 1\u00a0hour, 58\u00a0minutes ago \nDescription : Browser is affected by type confusion vulnerability, successful exploitation of this vulnerability may affect service availability. \nSeverity: 4.3 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-17T14:39:04.000000Z"}, {"uuid": "66117da7-4845-4e11-8e25-b652993397a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21973", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/21797", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21973 - Here is the title: ASUS PRIME Z690-P D4 bnxt_en NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21973 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \neth: bnxt: fix kernel panic in the bnxt_get_queue_stats{rx | tx}  \n  \nWhen qstats-get operation is executed, callbacks of netdev_stats_ops  \nare called. The bnxt_get_queue_stats{rx | tx} collect per-queue stats  \nfrom sw_stats in the rings.  \nBut {rx | tx | cp}_ring are allocated when the interface is up.  \nSo, these rings are not allocated when the interface is down.  \n  \nThe qstats-get is allowed even if the interface is down. However,  \nthe bnxt_get_queue_stats{rx | tx}() accesses cp_ring and tx_ring  \nwithout null check.  \nSo, it needs to avoid accessing rings if the interface is down.  \n  \nReproducer:  \n ip link set $interface down  \n ./cli.py --spec netdev.yaml --dump qstats-get  \nOR  \n ip link set $interface down  \n python ./stats.py  \n  \nSplat looks like:  \n BUG: kernel NULL pointer dereference, address: 0000000000000000  \n #PF: supervisor read access in kernel mode  \n #PF: error_code(0x0000) - not-present page  \n PGD 1680fa067 P4D 1680fa067 PUD 16be3b067 PMD 0  \n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI  \n CPU: 0 UID: 0 PID: 1495 Comm: python3 Not tainted 6.14.0-rc4+ #32 5cd0f999d5a15c574ac72b3e4b907341  \n Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021  \n RIP: 0010:bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en]  \n Code: c6 87 b5 18 00 00 02 eb a2 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 01  \n RSP: 0018:ffffabef43cdb7e0 EFLAGS: 00010282  \n RAX: 0000000000000000 RBX: ffffffffc04c8710 RCX: 0000000000000000  \n RDX: ffffabef43cdb858 RSI: 0000000000000000 RDI: ffff8d504e850000  \n RBP: ffff8d506c9f9c00 R08: 0000000000000004 R09: ffff8d506bcd901c  \n R10: 0000000000000015 R11: ffff8d506bcd9000 R12: 0000000000000000  \n R13: ffffabef43cdb8c0 R14: ffff8d504e850000 R15: 0000000000000000  \n FS:  00007f2c5462b080(0000) GS:ffff8d575f600000(0000) knlGS:0000000000000000  \n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n CR2: 0000000000000000 CR3: 0000000167fd0000 CR4: 00000000007506f0  \n PKRU: 55555554  \n Call Trace:  \n    \n  ? __die+0x20/0x70  \n  ? page_fault_oops+0x15a/0x460  \n  ? sched_balance_find_src_group+0x58d/0xd10  \n  ? exc_page_fault+0x6e/0x180  \n  ? asm_exc_page_fault+0x22/0x30  \n  ? bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en cdd546fd48563c280cfd30e9647efa420db07bf1]  \n  netdev_nl_stats_by_netdev+0x2b1/0x4e0  \n  ? xas_load+0x9/0xb0  \n  ? xas_find+0x183/0x1d0  \n  ? xa_find+0x8b/0xe0  \n  netdev_nl_qstats_get_dumpit+0xbf/0x1e0  \n  genl_dumpit+0x31/0x90  \n  netlink_dump+0x1a8/0x360 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:45:19.000000Z"}, {"uuid": "5874978e-0871-48ff-8e1e-f731af30feed", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21972", "type": "seen", "source": "https://t.me/cvedetector/21796", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21972 - Linux Kernel MCTP Net Fragment Reassembly Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21972 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: mctp: unshare packets when reassembling  \n  \nEnsure that the frag_list used for reassembly isn't shared with other  \npackets. This avoids incorrect reassembly when packets are cloned, and  \nprevents a memory leak due to circular references between fragments and  \ntheir skb_shared_info.  \n  \nThe upcoming MCTP-over-USB driver uses skb_clone which can trigger the  \nproblem - other MCTP drivers don't share SKBs.  \n  \nA kunit test is added to reproduce the issue. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:45:18.000000Z"}, {"uuid": "73ffd174-9b77-4365-8e9a-c48fbfe4fb0b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21970", "type": "seen", "source": "https://t.me/cvedetector/21795", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21970 - \"mlx5 Bridge LAG State Check Crash\"\", \n  \"Content\": \"CVE ID : CVE-2025-21970 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet/mlx5: Bridge, fix the crash caused by LAG state check  \n  \nWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event is  \ntriggered. Driver finds the lower devices (PFs) to flush all the  \noffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns  \nfalse if one of PF is unloaded. In such case,  \nmlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of  \nthe alive PF, and the flush is skipped.  \n  \nBesides, the bridge fdb entry's lastuse is updated in mlx5 bridge  \nevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can be  \nignored in this case because the upper interface for bond is deleted,  \nand the entry will never be aged because lastuse is never updated.  \n  \nTo make things worse, as the entry is alive, mlx5 bridge workqueue  \nkeeps sending that event, which is then handled by kernel bridge  \nnotifier. It causes the following crash when accessing the passed bond  \nnetdev which is already destroyed.  \n  \nTo fix this issue, remove such checks. LAG state is already checked in  \ncommit 15f8f168952f (\"net/mlx5: Bridge, verify LAG state when adding  \nbond to bridge\"), driver still need to skip offload if LAG becomes  \ninvalid state after initialization.  \n  \n Oops: stack segment: 0000 [#1] SMP  \n CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G           OE      6.11.0_mlnx #1  \n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE  \n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014  \n Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core]  \n RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge]  \n Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7  \n RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297  \n RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff  \n RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0  \n RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8  \n R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60  \n R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000  \n FS:  0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000  \n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0  \n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n PKRU: 55555554  \n Call Trace:  \n    \n  ? __die_body+0x1a/0x60  \n  ? die+0x38/0x60  \n  ? do_trap+0x10b/0x120  \n  ? do_error_trap+0x64/0xa0  \n  ? exc_stack_segment+0x33/0x50  \n  ? asm_exc_stack_segment+0x22/0x30  \n  ? br_switchdev_event+0x2c/0x110 [bridge]  \n  ? sched_balance_newidle.isra.149+0x248/0x390  \n  notifier_call_chain+0x4b/0xa0  \n  atomic_notifier_call_chain+0x16/0x20  \n  mlx5_esw_bridge_update+0xec/0x170 [mlx5_core]  \n  mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core]  \n  process_scheduled_works+0x81/0x390  \n  worker_thread+0x106/0x250  \n  ? bh_worker+0x110/0x110  \n  kthread+0xb7/0xe0  \n  ? kthread_park+0x80/0x80  \n  ret_from_fork+0x2d/0x50  \n  ? kthread_park+0x80/0x80  \n  ret_from_fork_asm+0x11/0x20 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:45:17.000000Z"}, {"uuid": "af9fbb42-cf9f-4248-a075-e198a12d997d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21971", "type": "seen", "source": "https://t.me/cvedetector/21794", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21971 - \"Linux Kernel net_sched TC_H_ROOT Class Creation Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21971 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet_sched: Prevent creation of classes with TC_H_ROOT  \n  \nThe function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination  \ncondition when traversing up the qdisc tree to update parent backlog  \ncounters. However, if a class is created with classid TC_H_ROOT, the  \ntraversal terminates prematurely at this class instead of reaching the  \nactual root qdisc, causing parent statistics to be incorrectly maintained.  \nIn case of DRR, this could lead to a crash as reported by Mingi Cho.  \n  \nPrevent the creation of any Qdisc class with classid TC_H_ROOT  \n(0xFFFFFFFF) across all qdisc types, as suggested by Jamal. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:44:41.000000Z"}, {"uuid": "a19d1137-13c4-4553-95af-97fafc5d1353", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21978", "type": "seen", "source": "https://t.me/cvedetector/21790", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21978 - Hyper-V DRM Address Space Leak\", \n  \"Content\": \"CVE ID : CVE-2025-21978 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/hyperv: Fix address space leak when Hyper-V DRM device is removed  \n  \nWhen a Hyper-V DRM device is probed, the driver allocates MMIO space for  \nthe vram, and maps it cacheable. If the device removed, or in the error  \npath for device probing, the MMIO space is released but no unmap is done.  \nConsequently the kernel address space for the mapping is leaked.  \n  \nFix this by adding iounmap() calls in the device removal path, and in the  \nerror path during device probing. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:44:38.000000Z"}, {"uuid": "248bcd9c-382c-4c90-ad0a-f6c7e0e217d6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21977", "type": "seen", "source": "https://t.me/cvedetector/21788", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21977 - Linux Hyper-V Framebuffer Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21977 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs  \n  \nGen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer  \ndevice. When the kdump kernel runs in such a VM, loading the efifb  \ndriver may hang because of accessing the framebuffer at the wrong  \nmemory address.  \n  \nThe scenario occurs when the hyperv_fb driver in the original kernel  \nmoves the framebuffer to a different MMIO address because of conflicts  \nwith an already-running efifb or simplefb driver. The hyperv_fb driver  \nthen informs Hyper-V of the change, which is allowed by the Hyper-V FB  \nVMBus device protocol. However, when the kexec command loads the kdump  \nkernel into crash memory via the kexec_file_load() system call, the  \nsystem call doesn't know the framebuffer has moved, and it sets up the  \nkdump screen_info using the original framebuffer address. The transition  \nto the kdump kernel does not go through the Hyper-V host, so Hyper-V  \ndoes not reset the framebuffer address like it would do on a reboot.  \nWhen efifb tries to run, it accesses a non-existent framebuffer  \naddress, which traps to the Hyper-V host. After many such accesses,  \nthe Hyper-V host thinks the guest is being malicious, and throttles  \nthe guest to the point that it runs very slowly or appears to have hung.  \n  \nWhen the kdump kernel is loaded into crash memory via the kexec_load()  \nsystem call, the problem does not occur. In this case, the kexec command  \nbuilds the screen_info table itself in user space from data returned  \nby the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the  \nnew framebuffer location.  \n  \nThis problem was originally reported in 2020 [1], resulting in commit  \n3cb73bc3fa2a (\"hyperv_fb: Update screen_info after removing old  \nframebuffer\"). This commit solved the problem by setting orig_video_isVGA  \nto 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb  \ndriver did not try to load, and no hang occurred. But in 2024, commit  \nc25a19afb81c (\"fbdev/hyperv_fb: Do not clear global screen_info\")  \neffectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference  \nto 3cb73bc3fa2a, so perhaps it was done without knowing the implications  \nthat were reported with 3cb73bc3fa2a. In any case, as of commit  \nc25a19afb81c, the original problem came back again.  \n  \nInterestingly, the hyperv_drm driver does not have this problem because  \nit never moves the framebuffer. The difference is that the hyperv_drm  \ndriver removes any conflicting framebuffers *before* allocating an MMIO  \naddress, while the hyperv_fb drivers removes conflicting framebuffers  \n*after* allocating an MMIO address. With the \"after\" ordering, hyperv_fb  \nmay encounter a conflict and move the framebuffer to a different MMIO  \naddress. But the conflict is essentially bogus because it is removed  \na few lines of code later.  \n  \nRather than fix the problem with the approach from 2020 in commit  \n3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so  \nconflicting framebuffers are removed before allocating an MMIO address.  \nThen the default framebuffer MMIO address should always be available, and  \nthere's never any confusion about which framebuffer address the kdump  \nkernel should use -- it's always the original address provided by  \nthe Hyper-V host. This approach is already used by the hyperv_drm  \ndriver, and is consistent with the usage guidelines at the head of  \nthe module with the function aperture_remove_conflicting_devices().  \n  \nThis approach also solves a related minor problem when kexec_load()  \nis used to load the kdump kernel. With current code, unbinding and  \nrebinding the hyperv_fb driver could result in the framebuffer moving  \nback to the default framebuffer address, be[...]", "creation_timestamp": "2025-04-01T19:44:33.000000Z"}, {"uuid": "057da391-2123-459b-91b6-714555a8c9d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21979", "type": "seen", "source": "https://t.me/cvedetector/21780", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21979 - \"Linux Kernel WiFi cfg80211 Use-After-Free Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21979 \nPublished : April 1, 2025, 4:15 p.m. | 1\u00a0hour, 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nwifi: cfg80211: cancel wiphy_work before freeing wiphy  \n  \nA wiphy_work can be queued from the moment the wiphy is allocated and  \ninitialized (i.e. wiphy_new_nm). When a wiphy_work is queued, the  \nrdev::wiphy_work is getting queued.  \n  \nIf wiphy_free is called before the rdev::wiphy_work had a chance to run,  \nthe wiphy memory will be freed, and then when it eventally gets to run  \nit'll use invalid memory.  \n  \nFix this by canceling the work before freeing the wiphy. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 Apr 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-04-01T19:44:23.000000Z"}]}