{"vulnerability": "cve-2025-2168", "sightings": [{"uuid": "a7336e68-c6ec-4680-95fc-4d33a7db2dc1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lgzy3yvwps2j", "content": "", "creation_timestamp": "2025-01-31T12:16:42.618633Z"}, {"uuid": "f0cfd2b0-f3ba-4d89-8732-05b1aa386cca", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21681", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lgzy43ac5m2e", "content": "", "creation_timestamp": "2025-01-31T12:16:45.115715Z"}, {"uuid": "9490b69b-709f-416e-8b72-850ab9ba744c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21682", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lgzy45fslt2i", "content": "", "creation_timestamp": "2025-01-31T12:16:47.346607Z"}, {"uuid": "575ade45-ada1-4508-b590-d070e012b9ec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21683", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lgzy47kwa72w", "content": "", "creation_timestamp": "2025-01-31T12:16:49.843681Z"}, {"uuid": "29252a41-9584-4d5d-bb56-b400a995a7f5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21684", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113973737079192703", "content": "", "creation_timestamp": "2025-02-09T11:40:13.344458Z"}, {"uuid": "b52cb5bc-9524-4af3-be46-50251e8e06ec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21685", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113973737095000853", "content": "", "creation_timestamp": "2025-02-09T11:40:13.523804Z"}, {"uuid": "31a38605-2dbe-4396-8465-bac84458db14", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21684", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lhqmawn3wx27", "content": "", "creation_timestamp": "2025-02-09T12:15:57.112240Z"}, {"uuid": "3bd8c66e-95be-4004-8430-381f17b8c01c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21685", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lhqmayyvmh22", "content": "", "creation_timestamp": "2025-02-09T12:15:59.706182Z"}, {"uuid": "33d06589-9000-4075-867a-bf86e0791bea", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21684", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113974127645069539", "content": "", "creation_timestamp": "2025-02-09T13:19:32.760782Z"}, {"uuid": "62a1580f-92b2-40a9-a3c7-4a0d2a6ef96c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21685", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lhqyhvpknj2t", "content": "", "creation_timestamp": "2025-02-09T15:54:36.270774Z"}, {"uuid": "3ba7163b-1c05-47e1-9618-611dac34971f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21684", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lhqyhw4okf2d", "content": "", "creation_timestamp": "2025-02-09T15:54:37.657716Z"}, {"uuid": "33840a03-f29a-43b3-832a-54d98bd2f5b5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21686", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lhtk5rexfe2i", "content": "", "creation_timestamp": "2025-02-10T16:16:22.848440Z"}, {"uuid": "5c904a24-1f73-4e62-822a-6d78c4451aa2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21687", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lhtk5tvnid2v", "content": "", "creation_timestamp": "2025-02-10T16:16:25.258024Z"}, {"uuid": "33eac18b-0e6f-4e69-af6c-e407c4c968ff", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21688", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lhtk5w7q2j2o", "content": "", "creation_timestamp": "2025-02-10T16:16:27.768060Z"}, {"uuid": "c5303120-9d2e-4ecc-9ad5-5018e1c262c5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21689", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lhtk5zehep2v", "content": "", "creation_timestamp": "2025-02-10T16:16:31.084995Z"}, {"uuid": "24d342ce-02d8-4d1b-b850-5fd52b880bdd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21686", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113980598265852945", "content": "", "creation_timestamp": "2025-02-10T16:45:06.498013Z"}, {"uuid": "38b3d7c3-ed16-4b7a-a91f-6759df6ada9e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21687", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113980651086155310", "content": "", "creation_timestamp": "2025-02-10T16:58:32.528784Z"}, {"uuid": "96284ccd-2552-455c-a742-413893329533", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21689", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lhtx7nufpp2t", "content": "", "creation_timestamp": "2025-02-10T20:10:06.672820Z"}, {"uuid": "b17ac895-b653-4576-b412-4be1c48dc7b0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21688", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lhtx7ok6pw2b", "content": "", "creation_timestamp": "2025-02-10T20:10:09.826777Z"}, {"uuid": "8de72b29-cdcb-42fd-a3cd-b43b4fa382ac", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21687", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lhtx7onu5w2h", "content": "", "creation_timestamp": "2025-02-10T20:10:10.436368Z"}, {"uuid": "24c0d8bf-ea6b-4d12-94d0-3d76d8609d15", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21686", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lhtx7ownt52n", "content": "", "creation_timestamp": "2025-02-10T20:10:11.609181Z"}, {"uuid": "0d774d9a-a8fe-41bc-81e6-61a5379c16bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3lrl3tzdzz22b", "content": "", "creation_timestamp": "2025-06-14T13:51:03.991614Z"}, {"uuid": "74e6727d-863e-4a11-b9fa-5534ca2d595e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3lrl5s2raj22b", "content": "", "creation_timestamp": "2025-06-14T14:25:46.978706Z"}, {"uuid": "421105ec-01b2-4de5-a13f-c879f97c77fd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3lrllhnxc522b", "content": "", "creation_timestamp": "2025-06-14T18:30:29.111961Z"}, {"uuid": "8a12151b-7c3e-4f2f-9b92-f409b064d4ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/pmloik.bsky.social/post/3lrmg2vvryg2a", "content": "", "creation_timestamp": "2025-06-15T02:26:30.590860Z"}, {"uuid": "8d564fd7-bad2-4486-935d-534f3b9a092d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2168", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lo3mskteel2e", "content": "", "creation_timestamp": "2025-05-01T05:56:17.328610Z"}, {"uuid": "ac004c15-215a-458a-b045-98c3496950d5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3lro4g6yaq22q", "content": "", "creation_timestamp": "2025-06-15T18:39:13.469096Z"}, {"uuid": "11e1c0ef-4487-43b0-bf7d-36a7d15f1a62", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3lro4wkikx22q", "content": "", "creation_timestamp": "2025-06-15T18:48:22.938973Z"}, {"uuid": "488bef9e-844d-486b-849d-64ace2dbccf3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21682", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "d9210fe1-c6bd-4a72-95f6-51302b7331a3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2025-21682", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "efc7f10b-d817-4d5a-bf19-e1cb4a859bb3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21687", "type": "seen", "source": "https://t.me/cvedetector/17575", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21687 - \"Linux VFIO Platform Out-of-Bounds Read/Write\"\", \n  \"Content\": \"CVE ID : CVE-2025-21687 \nPublished : Feb. 10, 2025, 4:15 p.m. | 1\u00a0hour, 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nvfio/platform: check the bounds of read/write syscalls  \n  \ncount and offset are passed from user space and not checked, only  \noffset is capped to 40 bits, which can be used to read/write out of  \nbounds of the device. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"10 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-10T18:45:50.000000Z"}, {"uuid": "51e65d30-8279-4977-b54c-824c26a3b453", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21686", "type": "seen", "source": "https://t.me/cvedetector/17574", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21686 - Linux Kernel io_uring Unprivileged Memory Corruption Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21686 \nPublished : Feb. 10, 2025, 4:15 p.m. | 1\u00a0hour, 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nio_uring/rsrc: require cloned buffers to share accounting contexts  \n  \nWhen IORING_REGISTER_CLONE_BUFFERS is used to clone buffers from uring  \ninstance A to uring instance B, where A and B use different MMs for  \naccounting, the accounting can go wrong:  \nIf uring instance A is closed before uring instance B, the pinned memory  \ncounters for uring instance B will be decremented, even though the pinned  \nmemory was originally accounted through uring instance A; so the MM of  \nuring instance B can end up with negative locked memory. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"10 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-10T18:45:49.000000Z"}, {"uuid": "eda32767-1ed9-40ac-923c-d0ec1a158f1e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21684", "type": "seen", "source": "https://t.me/cvedetector/17547", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21684 - Xilinx GPIO Lock Violation Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21684 \nPublished : Feb. 9, 2025, 12:15 p.m. | 22\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ngpio: xilinx: Convert gpio_lock to raw spinlock  \n  \nirq_chip functions may be called in raw spinlock context. Therefore, we  \nmust also use a raw spinlock for our own internal locking.  \n  \nThis fixes the following lockdep splat:  \n  \n[    5.349336] =============================  \n[    5.353349] [ BUG: Invalid wait context ]  \n[    5.357361] 6.13.0-rc5+ #69 Tainted: G        W  \n[    5.363031] -----------------------------  \n[    5.367045] kworker/u17:1/44 is trying to lock:  \n[    5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))  \n[    5.380079] other info that might help us debug this:  \n[    5.385138] context-{5:5}  \n[    5.387762] 5 locks held by kworker/u17:1/44:  \n[    5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)  \n[    5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)  \n[    5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)  \n[    5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)  \n[    5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)  \n[    5.436472] stack backtrace:  \n[    5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G        W          6.13.0-rc5+ #69  \n[    5.448690] Tainted: [W]=WARN  \n[    5.451656] Hardware name: xlnx,zynqmp (DT)  \n[    5.455845] Workqueue: events_unbound deferred_probe_work_func  \n[    5.461699] Call trace:  \n[    5.464147] show_stack+0x18/0x24 C  \n[    5.467821] dump_stack_lvl (lib/dump_stack.c:123)  \n[    5.471501] dump_stack (lib/dump_stack.c:130)  \n[    5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)  \n[    5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)  \n[    5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)  \n[    5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))  \n[    5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)  \n[    5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)  \n[    5.497645] irq_startup (kernel/irq/chip.c:270)  \n[    5.501143] __setup_irq (kernel/irq/manage.c:1807)  \n[    5.504728] request_threaded_irq (kernel/irq/manage.c:2208) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-09T14:19:35.000000Z"}, {"uuid": "8c547a35-646d-4013-844c-2f1fd32f36bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21689", "type": "seen", "source": "https://t.me/cvedetector/17568", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21689 - Linux Kernel USB Quatech2 Null Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2025-21689 \nPublished : Feb. 10, 2025, 4:15 p.m. | 1\u00a0hour, 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nUSB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()  \n  \nThis patch addresses a null-ptr-deref in qt2_process_read_urb() due to  \nan incorrect bounds check in the following:  \n  \n       if (newport > serial->num_ports) {  \n               dev_err(&port->dev,  \n                       \"%s - port change to invalid port: %i\\n\",  \n                       __func__, newport);  \n               break;  \n       }  \n  \nThe condition doesn't account for the valid range of the serial->port  \nbuffer, which is from 0 to serial->num_ports - 1. When newport is equal  \nto serial->num_ports, the assignment of \"port\" in the  \nfollowing code is out-of-bounds and NULL:  \n  \n       serial_priv->current_port = newport;  \n       port = serial->port[serial_priv->current_port];  \n  \nThe fix checks if newport is greater than or equal to serial->num_ports  \nindicating it is out-of-bounds. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"10 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-10T18:45:41.000000Z"}, {"uuid": "e962b8a1-e4ab-4667-85b3-e51b610f66a9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21688", "type": "seen", "source": "https://t.me/cvedetector/17566", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21688 - Raspberry Pi DRM V3D NULL Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2025-21688 \nPublished : Feb. 10, 2025, 4:15 p.m. | 1\u00a0hour, 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/v3d: Assign job pointer to NULL before signaling the fence  \n  \nIn commit e4b5ccd392b9 (\"drm/v3d: Ensure job pointer is set to NULL  \nafter job completion\"), we introduced a change to assign the job pointer  \nto NULL after completing a job, indicating job completion.  \n  \nHowever, this approach created a race condition between the DRM  \nscheduler workqueue and the IRQ execution thread. As soon as the fence is  \nsignaled in the IRQ execution thread, a new job starts to be executed.  \nThis results in a race condition where the IRQ execution thread sets the  \njob pointer to NULL simultaneously as the `run_job()` function assigns  \na new job to the pointer.  \n  \nThis race condition can lead to a NULL pointer dereference if the IRQ  \nexecution thread sets the job pointer to NULL after `run_job()` assigns  \nit to the new job. When the new job completes and the GPU emits an  \ninterrupt, `v3d_irq()` is triggered, potentially causing a crash.  \n  \n[  466.310099] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0  \n[  466.318928] Mem abort info:  \n[  466.321723]   ESR = 0x0000000096000005  \n[  466.325479]   EC = 0x25: DABT (current EL), IL = 32 bits  \n[  466.330807]   SET = 0, FnV = 0  \n[  466.333864]   EA = 0, S1PTW = 0  \n[  466.337010]   FSC = 0x05: level 1 translation fault  \n[  466.341900] Data abort info:  \n[  466.344783]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000  \n[  466.350285]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0  \n[  466.355350]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0  \n[  466.360677] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000089772000  \n[  466.367140] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000  \n[  466.375875] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP  \n[  466.382163] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc vc4 snd_soc_hdmi_codec drm_display_helper cec brcmfmac_wcc spidev rpivid_hevc(C) drm_client_lib brcmfmac hci_uart drm_dma_helper pisp_be btbcm brcmutil snd_soc_core aes_ce_blk v4l2_mem2mem bluetooth aes_ce_cipher snd_compress videobuf2_dma_contig ghash_ce cfg80211 gf128mul snd_pcm_dmaengine videobuf2_memops ecdh_generic sha2_ce ecc videobuf2_v4l2 snd_pcm v3d sha256_arm64 rfkill videodev snd_timer sha1_ce libaes gpu_sched snd videobuf2_common sha1_generic drm_shmem_helper mc rp1_pio drm_kms_helper raspberrypi_hwmon spi_bcm2835 gpio_keys i2c_brcmstb rp1 raspberrypi_gpiomem rp1_mailbox rp1_adc nvmem_rmem uio_pdrv_genirq uio i2c_dev drm ledtrig_pattern drm_panel_orientation_quirks backlight fuse dm_mod ip_tables x_tables ipv6  \n[  466.458429] CPU: 0 UID: 1000 PID: 2008 Comm: chromium Tainted: G         C         6.13.0-v8+ #18  \n[  466.467336] Tainted: [C]=CRAP  \n[  466.470306] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)  \n[  466.476157] pstate: 404000c9 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \n[  466.483143] pc : v3d_irq+0x118/0x2e0 [v3d]  \n[  466.487258] lr : __handle_irq_event_percpu+0x60/0x228  \n[  466.492327] sp : ffffffc080003ea0  \n[  466.495646] x29: ffffffc080003ea0 x28: ffffff80c0c94200 x27: 0000000000000000  \n[  466.502807] x26: ffffffd08dd81d7b x25: ffffff80c0c94200 x24: ffffff8003bdc200  \n[  466.509969] x23: 0000000000000001 x22: 00000000000000a7 x21: 0000000000000000  \n[  466.517130] x20: ffffff8041bb0000 x19: 0000000000000001 x18: 0000000000000000  \n[  466.524291] x17: ffffffafadfb0000 x16: ffffffc080000000 x15: 0000000000000000  \n[  466.531452] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000  \n[  466.538613] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffd08c527eb0  \n[  466.545777] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000[...]", "creation_timestamp": "2025-02-10T18:45:39.000000Z"}, {"uuid": "a773a339-821e-4b29-a312-3c9d6c4e8462", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21685", "type": "seen", "source": "https://t.me/cvedetector/17548", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21685 - Lenovo Yoga Tab 2 Pro 1380 Fastcharger Serdev NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21685 \nPublished : Feb. 9, 2025, 12:15 p.m. | 22\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nplatform/x86: lenovo-yoga-tab2-pro-1380-fastcharger: fix serdev race  \n  \nThe yt2_1380_fc_serdev_probe() function calls devm_serdev_device_open()  \nbefore setting the client ops via serdev_device_set_client_ops(). This  \nordering can trigger a NULL pointer dereference in the serdev controller's  \nreceive_buf handler, as it assumes serdev->ops is valid when  \nSERPORT_ACTIVE is set.  \n  \nThis is similar to the issue fixed in commit 5e700b384ec1  \n(\"platform/chrome: cros_ec_uart: properly fix race condition\") where  \ndevm_serdev_device_open() was called before fully initializing the  \ndevice.  \n  \nFix the race by ensuring client ops are set before enabling the port via  \ndevm_serdev_device_open().  \n  \nNote, serdev_device_set_baudrate() and serdev_device_set_flow_control()  \ncalls should be after the devm_serdev_device_open() call. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-09T14:19:36.000000Z"}, {"uuid": "3a20f092-7838-4971-b0c7-402e4d0a0237", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21681", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/3647", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21681\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix lockup on tx to unregistering netdev with carrier\n\nCommit in a fixes tag attempted to fix the issue in the following\nsequence of calls:\n\n    do_output\n    -> ovs_vport_send\n       -> dev_queue_xmit\n          -> __dev_queue_xmit\n             -> netdev_core_pick_tx\n                -> skb_tx_hash\n\nWhen device is unregistering, the 'dev->real_num_tx_queues' goes to\nzero and the 'while (unlikely(hash >= qcount))' loop inside the\n'skb_tx_hash' becomes infinite, locking up the core forever.\n\nBut unfortunately, checking just the carrier status is not enough to\nfix the issue, because some devices may still be in unregistering\nstate while reporting carrier status OK.\n\nOne example of such device is a net/dummy.  It sets carrier ON\non start, but it doesn't implement .ndo_stop to set the carrier off.\nAnd it makes sense, because dummy doesn't really have a carrier.\nTherefore, while this device is unregistering, it's still easy to hit\nthe infinite loop in the skb_tx_hash() from the OVS datapath.  There\nmight be other drivers that do the same, but dummy by itself is\nimportant for the OVS ecosystem, because it is frequently used as a\npacket sink for tcpdump while debugging OVS deployments.  And when the\nissue is hit, the only way to recover is to reboot.\n\nFix that by also checking if the device is running.  The running\nstate is handled by the net core during unregistering, so it covers\nunregistering case better, and we don't really need to send packets\nto devices that are not running anyway.\n\nWhile only checking the running state might be enough, the carrier\ncheck is preserved.  The running and the carrier states seem disjoined\nthroughout the code and different drivers.  And other core functions\nlike __dev_direct_xmit() check both before attempting to transmit\na packet.  So, it seems safer to check both flags in OVS as well.\n\ud83d\udccf Published: 2025-01-31T12:33:03Z\n\ud83d\udccf Modified: 2025-01-31T12:33:03Z\n\ud83d\udd17 References:\n1. https://nvd.nist.gov/vuln/detail/CVE-2025-21681\n2. https://git.kernel.org/stable/c/47e55e4b410f7d552e43011baa5be1aab4093990\n3. https://git.kernel.org/stable/c/82f433e8dd0629e16681edf6039d094b5518d8ed\n4. https://git.kernel.org/stable/c/ea966b6698785fb9cd0fdb867acd91b222e4723f\n5. https://git.kernel.org/stable/c/ea9e990356b7bee95440ba0e6e83cc4d701afaca", "creation_timestamp": "2025-01-31T13:14:58.000000Z"}, {"uuid": "607ed559-9e39-4029-96be-4446a1a93311", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21682", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/3646", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21682\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: always recalculate features after XDP clearing, fix null-deref\n\nRecalculate features when XDP is detached.\n\nBefore:\n  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp\n  # ip li set dev eth0 xdp off\n  # ethtool -k eth0 | grep gro\n  rx-gro-hw: off [requested on]\n\nAfter:\n  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp\n  # ip li set dev eth0 xdp off\n  # ethtool -k eth0 | grep gro\n  rx-gro-hw: on\n\nThe fact that HW-GRO doesn't get re-enabled automatically is just\na minor annoyance. The real issue is that the features will randomly\ncome back during another reconfiguration which just happens to invoke\nnetdev_update_features(). The driver doesn't handle reconfiguring\ntwo things at a time very robustly.\n\nStarting with commit 98ba1d931f61 (\"bnxt_en: Fix RSS logic in\n__bnxt_reserve_rings()\") we only reconfigure the RSS hash table\nif the \"effective\" number of Rx rings has changed. If HW-GRO is\nenabled \"effective\" number of rings is 2x what user sees.\nSo if we are in the bad state, with HW-GRO re-enablement \"pending\"\nafter XDP off, and we lower the rings by / 2 - the HW-GRO rings\ndoing 2x and the ethtool -L doing / 2 may cancel each other out,\nand the:\n\n  if (old_rx_rings != bp->hw_resc.resv_rx_rings &&\n\ncondition in __bnxt_reserve_rings() will be false.\nThe RSS map won't get updated, and we'll crash with:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000168\n  RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0\n    bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180\n    __bnxt_setup_vnic_p5+0x58/0x110\n    bnxt_init_nic+0xb72/0xf50\n    __bnxt_open_nic+0x40d/0xab0\n    bnxt_open_nic+0x2b/0x60\n    ethtool_set_channels+0x18c/0x1d0\n\nAs we try to access a freed ring.\n\nThe issue is present since XDP support was added, really, but\nprior to commit 98ba1d931f61 (\"bnxt_en: Fix RSS logic in\n__bnxt_reserve_rings()\") it wasn't causing major issues.\n\ud83d\udccf Published: 2025-01-31T12:33:03Z\n\ud83d\udccf Modified: 2025-01-31T12:33:03Z\n\ud83d\udd17 References:\n1. https://nvd.nist.gov/vuln/detail/CVE-2025-21682\n2. https://git.kernel.org/stable/c/08831a894d18abfaabb5bbde7c2069a7fb41dd93\n3. https://git.kernel.org/stable/c/f0aa6a37a3dbb40b272df5fc6db93c114688adcd", "creation_timestamp": "2025-01-31T13:14:57.000000Z"}, {"uuid": "23ce14d7-27ef-47bb-b1fd-1c4294a433c3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21683", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/3645", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21683\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix bpf_sk_select_reuseport() memory leak\n\nAs pointed out in the original comment, lookup in sockmap can return a TCP\nESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF\nset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb\ndoes not imply a non-refcounted socket.\n\nDrop sk's reference in both error paths.\n\nunreferenced object 0xffff888101911800 (size 2048):\n  comm \"test_progs\", pid 44109, jiffies 4297131437\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc 9336483b):\n    __kmalloc_noprof+0x3bf/0x560\n    __reuseport_alloc+0x1d/0x40\n    reuseport_alloc+0xca/0x150\n    reuseport_attach_prog+0x87/0x140\n    sk_reuseport_attach_bpf+0xc8/0x100\n    sk_setsockopt+0x1181/0x1990\n    do_sock_setsockopt+0x12b/0x160\n    __sys_setsockopt+0x7b/0xc0\n    __x64_sys_setsockopt+0x1b/0x30\n    do_syscall_64+0x93/0x180\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\ud83d\udccf Published: 2025-01-31T12:33:03Z\n\ud83d\udccf Modified: 2025-01-31T12:33:03Z\n\ud83d\udd17 References:\n1. https://nvd.nist.gov/vuln/detail/CVE-2025-21683\n2. https://git.kernel.org/stable/c/0ab52a8ca6e156a64c51b5e7456cac9a0ebfd9bf\n3. https://git.kernel.org/stable/c/b02e70be498b138e9c21701c2f33f4018ca7cd5e\n4. https://git.kernel.org/stable/c/b3af60928ab9129befa65e6df0310d27300942bf\n5. https://git.kernel.org/stable/c/cccd51dd22574216e64e5d205489e634f86999f3\n6. https://git.kernel.org/stable/c/d0a3b3d1176d39218b8edb2a2d03164942ab9ccd", "creation_timestamp": "2025-01-31T13:14:55.000000Z"}, {"uuid": "06a81dff-14fe-46a0-b799-2b3121226406", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21684", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/4891", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21684\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: xilinx: Convert gpio_lock to raw spinlock\n\nirq_chip functions may be called in raw spinlock context. Therefore, we\nmust also use a raw spinlock for our own internal locking.\n\nThis fixes the following lockdep splat:\n\n[    5.349336] =============================\n[    5.353349] [ BUG: Invalid wait context ]\n[    5.357361] 6.13.0-rc5+ #69 Tainted: G        W\n[    5.363031] -----------------------------\n[    5.367045] kworker/u17:1/44 is trying to lock:\n[    5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[    5.380079] other info that might help us debug this:\n[    5.385138] context-{5:5}\n[    5.387762] 5 locks held by kworker/u17:1/44:\n[    5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)\n[    5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)\n[    5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)\n[    5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)\n[    5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)\n[    5.436472] stack backtrace:\n[    5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G        W          6.13.0-rc5+ #69\n[    5.448690] Tainted: [W]=WARN\n[    5.451656] Hardware name: xlnx,zynqmp (DT)\n[    5.455845] Workqueue: events_unbound deferred_probe_work_func\n[    5.461699] Call trace:\n[    5.464147] show_stack+0x18/0x24 C\n[    5.467821] dump_stack_lvl (lib/dump_stack.c:123)\n[    5.471501] dump_stack (lib/dump_stack.c:130)\n[    5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)\n[    5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)\n[    5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)\n[    5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))\n[    5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)\n[    5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)\n[    5.497645] irq_startup (kernel/irq/chip.c:270)\n[    5.501143] __setup_irq (kernel/irq/manage.c:1807)\n[    5.504728] request_threaded_irq (kernel/irq/manage.c:2208)\n\ud83d\udccf Published: 2025-02-09T11:37:24.610Z\n\ud83d\udccf Modified: 2025-02-21T13:45:17.838Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/f0ed2d0abc021f56fa27dc6d0770535c1851a43b\n2. https://git.kernel.org/stable/c/b0111650ee596219bb5defa0ce1a1308e6e77ccf\n3. https://git.kernel.org/stable/c/9c035105c5537d2ecad6b9415e9417a1ffbd0a62\n4. https://git.kernel.org/stable/c/9860370c2172704b6b4f0075a0c2a29fd84af96a", "creation_timestamp": "2025-02-21T14:18:30.000000Z"}, {"uuid": "462cad22-dd75-449d-b522-d77574aa56f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21683", "type": "seen", "source": "https://t.me/cvedetector/16939", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21683 - Linux Kernel bpf SO_ATTACH_REUSEPORT_EBPF Memory Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21683 \nPublished : Jan. 31, 2025, 12:15 p.m. | 1\u00a0hour, 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Fix bpf_sk_select_reuseport() memory leak  \n  \nAs pointed out in the original comment, lookup in sockmap can return a TCP  \nESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF  \nset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb  \ndoes not imply a non-refcounted socket.  \n  \nDrop sk's reference in both error paths.  \n  \nunreferenced object 0xffff888101911800 (size 2048):  \n  comm \"test_progs\", pid 44109, jiffies 4297131437  \n  hex dump (first 32 bytes):  \n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  \n    80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  \n  backtrace (crc 9336483b):  \n    __kmalloc_noprof+0x3bf/0x560  \n    __reuseport_alloc+0x1d/0x40  \n    reuseport_alloc+0xca/0x150  \n    reuseport_attach_prog+0x87/0x140  \n    sk_reuseport_attach_bpf+0xc8/0x100  \n    sk_setsockopt+0x1181/0x1990  \n    do_sock_setsockopt+0x12b/0x160  \n    __sys_setsockopt+0x7b/0xc0  \n    __x64_sys_setsockopt+0x1b/0x30  \n    do_syscall_64+0x93/0x180  \n    entry_SYSCALL_64_after_hwframe+0x76/0x7e \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"31 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-31T15:22:35.000000Z"}, {"uuid": "aba20988-8575-402a-b5b4-8bbc2a20afd3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21682", "type": "seen", "source": "https://t.me/cvedetector/16938", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21682 - \"Broadcom bnxt: Null-dereference Vulnerability in XDP Handling\"\", \n  \"Content\": \"CVE ID : CVE-2025-21682 \nPublished : Jan. 31, 2025, 12:15 p.m. | 1\u00a0hour, 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \neth: bnxt: always recalculate features after XDP clearing, fix null-deref  \n  \nRecalculate features when XDP is detached.  \n  \nBefore:  \n  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp  \n  # ip li set dev eth0 xdp off  \n  # ethtool -k eth0 | grep gro  \n  rx-gro-hw: off [requested on]  \n  \nAfter:  \n  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp  \n  # ip li set dev eth0 xdp off  \n  # ethtool -k eth0 | grep gro  \n  rx-gro-hw: on  \n  \nThe fact that HW-GRO doesn't get re-enabled automatically is just  \na minor annoyance. The real issue is that the features will randomly  \ncome back during another reconfiguration which just happens to invoke  \nnetdev_update_features(). The driver doesn't handle reconfiguring  \ntwo things at a time very robustly.  \n  \nStarting with commit 98ba1d931f61 (\"bnxt_en: Fix RSS logic in  \n__bnxt_reserve_rings()\") we only reconfigure the RSS hash table  \nif the \"effective\" number of Rx rings has changed. If HW-GRO is  \nenabled \"effective\" number of rings is 2x what user sees.  \nSo if we are in the bad state, with HW-GRO re-enablement \"pending\"  \nafter XDP off, and we lower the rings by / 2 - the HW-GRO rings  \ndoing 2x and the ethtool -L doing / 2 may cancel each other out,  \nand the:  \n  \n  if (old_rx_rings != bp->hw_resc.resv_rx_rings &&  \n  \ncondition in __bnxt_reserve_rings() will be false.  \nThe RSS map won't get updated, and we'll crash with:  \n  \n  BUG: kernel NULL pointer dereference, address: 0000000000000168  \n  RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0  \n    bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180  \n    __bnxt_setup_vnic_p5+0x58/0x110  \n    bnxt_init_nic+0xb72/0xf50  \n    __bnxt_open_nic+0x40d/0xab0  \n    bnxt_open_nic+0x2b/0x60  \n    ethtool_set_channels+0x18c/0x1d0  \n  \nAs we try to access a freed ring.  \n  \nThe issue is present since XDP support was added, really, but  \nprior to commit 98ba1d931f61 (\"bnxt_en: Fix RSS logic in  \n__bnxt_reserve_rings()\") it wasn't causing major issues. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"31 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-31T15:22:34.000000Z"}, {"uuid": "bdc65f72-a753-4227-ab0e-3d9020c390ac", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21681", "type": "seen", "source": "https://t.me/cvedetector/16937", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21681 - Openvswitch Lockup Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21681 \nPublished : Jan. 31, 2025, 12:15 p.m. | 1\u00a0hour, 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nopenvswitch: fix lockup on tx to unregistering netdev with carrier  \n  \nCommit in a fixes tag attempted to fix the issue in the following  \nsequence of calls:  \n  \n    do_output  \n    -> ovs_vport_send  \n       -> dev_queue_xmit  \n          -> __dev_queue_xmit  \n             -> netdev_core_pick_tx  \n                -> skb_tx_hash  \n  \nWhen device is unregistering, the 'dev->real_num_tx_queues' goes to  \nzero and the 'while (unlikely(hash >= qcount))' loop inside the  \n'skb_tx_hash' becomes infinite, locking up the core forever.  \n  \nBut unfortunately, checking just the carrier status is not enough to  \nfix the issue, because some devices may still be in unregistering  \nstate while reporting carrier status OK.  \n  \nOne example of such device is a net/dummy.  It sets carrier ON  \non start, but it doesn't implement .ndo_stop to set the carrier off.  \nAnd it makes sense, because dummy doesn't really have a carrier.  \nTherefore, while this device is unregistering, it's still easy to hit  \nthe infinite loop in the skb_tx_hash() from the OVS datapath.  There  \nmight be other drivers that do the same, but dummy by itself is  \nimportant for the OVS ecosystem, because it is frequently used as a  \npacket sink for tcpdump while debugging OVS deployments.  And when the  \nissue is hit, the only way to recover is to reboot.  \n  \nFix that by also checking if the device is running.  The running  \nstate is handled by the net core during unregistering, so it covers  \nunregistering case better, and we don't really need to send packets  \nto devices that are not running anyway.  \n  \nWhile only checking the running state might be enough, the carrier  \ncheck is preserved.  The running and the carrier states seem disjoined  \nthroughout the code and different drivers.  And other core functions  \nlike __dev_direct_xmit() check both before attempting to transmit  \na packet.  So, it seems safer to check both flags in OVS as well. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"31 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-31T15:22:33.000000Z"}, {"uuid": "e830010d-f681-4bc9-b6f1-4e01daa7ccf5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21680", "type": "seen", "source": "https://t.me/cvedetector/16936", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21680 - \"QEMU Pktgen Array Out-of-Bounds Write Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21680 \nPublished : Jan. 31, 2025, 12:15 p.m. | 1\u00a0hour, 34\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npktgen: Avoid out-of-bounds access in get_imix_entries  \n  \nPassing a sufficient amount of imix entries leads to invalid access to the  \npkt_dev->imix_entries array because of the incorrect boundary check.  \n  \nUBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24  \nindex 20 is out of range for type 'imix_pkt [20]'  \nCPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121  \nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)  \nCall Trace:  \n  \ndump_stack_lvl lib/dump_stack.c:117  \n__ubsan_handle_out_of_bounds lib/ubsan.c:429  \nget_imix_entries net/core/pktgen.c:874  \npktgen_if_write net/core/pktgen.c:1063  \npde_write fs/proc/inode.c:334  \nproc_reg_write fs/proc/inode.c:346  \nvfs_write fs/read_write.c:593  \nksys_write fs/read_write.c:644  \ndo_syscall_64 arch/x86/entry/common.c:83  \nentry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130  \n  \nFound by Linux Verification Center (linuxtesting.org) with SVACE.  \n  \n[ fp: allow to fill the array completely; minor changelog cleanup ] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"31 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-31T15:22:32.000000Z"}, {"uuid": "3b862acc-c67a-4c93-ba66-4988854317fd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2168", "type": "seen", "source": "https://t.me/cvedetector/24186", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-2168 - Elementor Store Kit CSRF\", \n  \"Content\": \"CVE ID : CVE-2025-2168 \nPublished : May 1, 2025, 4:16 a.m. | 1\u00a0hour, 54\u00a0minutes ago \nDescription : The Ultimate Store Kit Elementor Addons, Woocommerce Builder, EDD Builder, Elementor Store Builder, Product Grid, Product Table, Woocommerce Slider plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 2.4.1. This is due to missing or incorrect nonce validation on the dismiss() function. This makes it possible for unauthenticated attackers to set arbitrary user meta values to `1` which can be leveraged to lock and administrator out of their site via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. \nSeverity: 4.3 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"01 May 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-05-01T08:58:44.000000Z"}, {"uuid": "229f3516-e366-4a9a-95e6-2b8b2c35b593", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21683", "type": "seen", "source": "Telegram/JDl9OD5TWx90S2Xla8iIm-SseFD2E78k-uVIN4XyFTXqabwl", "content": "", "creation_timestamp": "2025-02-06T02:40:19.000000Z"}, {"uuid": "22e77993-ef40-48c5-a907-d85df088970a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21689", "type": "seen", "source": "Telegram/fsWtqUSD5aBRR3Lo4HUEDMqt4tjMZxq8AaNS17pls181QAlh", "content": "", "creation_timestamp": "2025-02-21T22:10:25.000000Z"}, {"uuid": "0ad86d14-c333-45ed-b1e1-f851450dc062", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21688", "type": "seen", "source": "Telegram/YW3OBffYpJzt43dSoCFhkIXD7FgFDpWLUNVFG-0Mrg0Ms0Dq", "content": "", "creation_timestamp": "2025-02-21T22:10:25.000000Z"}, {"uuid": "7fd43e31-ef02-450c-94e6-0cb59f67a4d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21687", "type": "seen", "source": "Telegram/Gd989qsTJ7Cb3Jh0G76NtMxUjseZdwyFrhNVO6s03aGYeOr6", "content": "", "creation_timestamp": "2025-02-21T22:10:25.000000Z"}, {"uuid": "02d83a8c-b08f-4d90-819c-78f0860fe665", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21681", "type": "seen", "source": "Telegram/5ix6OMghR9M2BnL2v_FLM8N153J_avjMzjVJIwPbx-FrMseY", "content": "", "creation_timestamp": "2025-02-21T22:10:25.000000Z"}, {"uuid": "c850bb6d-bf57-4c3f-a5fc-1f2bc3a4d28f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21682", "type": "seen", "source": "https://www.hkcert.org/security-bulletin/debian-linux-kernel-multiple-vulnerabilities_20260506", "content": "", "creation_timestamp": "2026-05-05T20:00:00.000000Z"}]}