{"vulnerability": "cve-2025-2182", "sightings": [{"uuid": "e59fce01-ee44-4fe8-b4b4-7c2b65082f7f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2182", "type": "seen", "source": "https://infosec.exchange/users/cR0w/statuses/115022455470697008", "content": "", "creation_timestamp": "2025-08-13T16:43:06.726454Z"}, {"uuid": "b4022e3e-bb1a-43fc-a816-dca16d1367fd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21824", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lj6v7yuwue27", "content": "", "creation_timestamp": "2025-02-27T21:58:58.883067Z"}, {"uuid": "72bd9c98-e54c-4db4-9583-fc6459b847ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21823", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lj6v7zgtxb2p", "content": "", "creation_timestamp": "2025-02-27T21:59:01.800382Z"}, {"uuid": "bb9c4e0c-10cf-4860-bbe2-2cee7bbb0afc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21820", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lj6v7zkjek25", "content": "", "creation_timestamp": "2025-02-27T21:59:02.425404Z"}, {"uuid": "46b1d0cb-f311-40af-aa08-cd91d89c4ad7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lj6v7zrmvs25", "content": "", "creation_timestamp": "2025-02-27T21:59:03.539144Z"}, {"uuid": "3ef391ce-aa72-4b63-8ce1-af7406e56bed", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/114080058424766855", "content": "", "creation_timestamp": "2025-02-28T06:19:08.185744Z"}, {"uuid": "26149e47-822d-4d10-b639-323dc80b40ee", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21822", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lj6v7ynavd2p", "content": "", "creation_timestamp": "2025-02-27T21:58:57.764668Z"}, {"uuid": "7fb11455-bd05-43f5-ae32-ea1b6aae7b60", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2182", "type": "seen", "source": "https://security.paloaltonetworks.com/CVE-2025-2182", "content": "", "creation_timestamp": "2025-08-13T14:00:00.000000Z"}, {"uuid": "9ba68840-6d54-425a-8584-93670e91b6bc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2182", "type": "seen", "source": "https://bsky.app/profile/ripjyr.bsky.social/post/3lwcjc3yyo623", "content": "", "creation_timestamp": "2025-08-13T19:03:33.156454Z"}, {"uuid": "492cffb7-3d7a-40af-b509-dda26fe349fb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21829", "type": "seen", "source": "MISP/4937e86f-f5bd-4d09-8bda-88a7440077f3", "content": "", "creation_timestamp": "2025-08-18T13:31:23.000000Z"}, {"uuid": "1fbf3e46-5bfe-4805-9191-b66ff3c4e57d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21829", "type": "seen", "source": "MISP/4937e86f-f5bd-4d09-8bda-88a7440077f3", "content": "", "creation_timestamp": "2025-08-19T02:47:43.000000Z"}, {"uuid": "a5b49f1c-1ec5-4f30-b09f-62ee575a61e0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "https://gist.github.com/Darkcrai86/7d67117cadf6bb8cb79ee0dd11fe0bb6", "content": "", "creation_timestamp": "2025-08-28T17:43:23.000000Z"}, {"uuid": "6e6c04d9-a284-4393-ba53-5d8ce9a83a95", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "MISP/24306fae-b16b-4478-9297-d2973cdb583c", "content": "", "creation_timestamp": "2025-08-22T14:52:23.000000Z"}, {"uuid": "f21af7b1-d47e-4412-9ffb-a3ac77cfee29", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "0f665645-9d62-45bd-903c-1f304eef66c3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "cefafb7f-c246-44d0-9700-cdbe2c7d5e6b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21825", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "0bb23691-1bfd-4aec-8093-11dda743af63", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2025-21820", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "3e7fb3ba-a6e9-4836-a8a3-0a154cd44a2c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21821", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/5786", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21821\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omap: use threaded IRQ for LCD DMA\n\nWhen using touchscreen and framebuffer, Nokia 770 crashes easily with:\n\n    BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000\n    Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd\n    CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2\n    Hardware name: Nokia 770\n    Call trace:\n     unwind_backtrace from show_stack+0x10/0x14\n     show_stack from dump_stack_lvl+0x54/0x5c\n     dump_stack_lvl from __schedule_bug+0x50/0x70\n     __schedule_bug from __schedule+0x4d4/0x5bc\n     __schedule from schedule+0x34/0xa0\n     schedule from schedule_preempt_disabled+0xc/0x10\n     schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4\n     __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4\n     clk_prepare_lock from clk_set_rate+0x18/0x154\n     clk_set_rate from sossi_read_data+0x4c/0x168\n     sossi_read_data from hwa742_read_reg+0x5c/0x8c\n     hwa742_read_reg from send_frame_handler+0xfc/0x300\n     send_frame_handler from process_pending_requests+0x74/0xd0\n     process_pending_requests from lcd_dma_irq_handler+0x50/0x74\n     lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130\n     __handle_irq_event_percpu from handle_irq_event+0x28/0x68\n     handle_irq_event from handle_level_irq+0x9c/0x170\n     handle_level_irq from generic_handle_domain_irq+0x2c/0x3c\n     generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c\n     omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c\n     generic_handle_arch_irq from call_with_stack+0x1c/0x24\n     call_with_stack from __irq_svc+0x94/0xa8\n    Exception stack(0xc5255da0 to 0xc5255de8)\n    5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248\n    5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94\n    5de0: 60000013 ffffffff\n     __irq_svc from clk_prepare_lock+0x4c/0xe4\n     clk_prepare_lock from clk_get_rate+0x10/0x74\n     clk_get_rate from uwire_setup_transfer+0x40/0x180\n     uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c\n     spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664\n     spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498\n     __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8\n     __spi_sync from spi_sync+0x24/0x40\n     spi_sync from ads7846_halfd_read_state+0x5c/0x1c0\n     ads7846_halfd_read_state from ads7846_irq+0x58/0x348\n     ads7846_irq from irq_thread_fn+0x1c/0x78\n     irq_thread_fn from irq_thread+0x120/0x228\n     irq_thread from kthread+0xc8/0xe8\n     kthread from ret_from_fork+0x14/0x28\n\nAs a quick fix, switch to a threaded IRQ which provides a stable system.\n\ud83d\udccf Published: 2025-02-27T20:06:12.722Z\n\ud83d\udccf Modified: 2025-02-27T20:06:12.722Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/7bbbd311dd503653a2cc86d9226740883051dc92\n2. https://git.kernel.org/stable/c/fb6a5edb60921887d7d10619fcdcbee9759552cb\n3. https://git.kernel.org/stable/c/aa8e22cbedeb626f2a6bda0aea362353d627cd0a\n4. https://git.kernel.org/stable/c/8392ea100f0b86c234c739c6662f39f0ccc0cefd\n5. https://git.kernel.org/stable/c/e4b6b665df815b4841e71b72f06446884e8aad40", "creation_timestamp": "2025-02-27T20:25:52.000000Z"}, {"uuid": "b8e25c10-705a-4ad7-bc84-25353440870d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21822", "type": "seen", "source": "https://t.me/cvedetector/19092", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21822 - Linux Kernel PTP Vulnerability - Use After Free\", \n  \"Content\": \"CVE ID : CVE-2025-21822 \nPublished : Feb. 27, 2025, 8:16 p.m. | 1\u00a0hour, 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nptp: vmclock: Set driver data before its usage  \n  \nIf vmclock_ptp_register() fails during probing, vmclock_remove() is  \ncalled to clean up the ptp clock and misc device.  \nIt uses dev_get_drvdata() to access the vmclock state.  \nHowever the driver data is not yet set at this point.  \n  \nAssign the driver data earlier. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-27T23:27:46.000000Z"}, {"uuid": "26b6f1fa-8264-43ef-9532-3fead3cda1a0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21824", "type": "seen", "source": "https://t.me/cvedetector/19087", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21824 - NVIDIA Host1x Use of Uninitialized Mutex\", \n  \"Content\": \"CVE ID : CVE-2025-21824 \nPublished : Feb. 27, 2025, 8:16 p.m. | 1\u00a0hour, 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ngpu: host1x: Fix a use of uninitialized mutex  \n  \ncommit c8347f915e67 (\"gpu: host1x: Fix boot regression for Tegra\")  \ncaused a use of uninitialized mutex leading to below warning when  \nCONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_LOCK_ALLOC are enabled.  \n  \n[   41.662843] ------------[ cut here ]------------  \n[   41.663012] DEBUG_LOCKS_WARN_ON(lock->magic != lock)  \n[   41.663035] WARNING: CPU: 4 PID: 794 at kernel/locking/mutex.c:587 __mutex_lock+0x670/0x878  \n[   41.663458] Modules linked in: rtw88_8822c(+) bluetooth(+) rtw88_pci rtw88_core mac80211 aquantia libarc4 crc_itu_t cfg80211 tegra194_cpufreq dwmac_tegra(+) arm_dsu_pmu stmmac_platform stmmac pcs_xpcs rfkill at24 host1x(+) tegra_bpmp_thermal ramoops reed_solomon fuse loop nfnetlink xfs mmc_block rpmb_core ucsi_ccg ina3221 crct10dif_ce xhci_tegra ghash_ce lm90 sha2_ce sha256_arm64 sha1_ce sdhci_tegra pwm_fan sdhci_pltfm sdhci gpio_keys rtc_tegra cqhci mmc_core phy_tegra_xusb i2c_tegra tegra186_gpc_dma i2c_tegra_bpmp spi_tegra114 dm_mirror dm_region_hash dm_log dm_mod  \n[   41.665078] CPU: 4 UID: 0 PID: 794 Comm: (udev-worker) Not tainted 6.11.0-29.31_1538613708.el10.aarch64+debug #1  \n[   41.665838] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.3.0-gcid-35594366 02/26/2024  \n[   41.672555] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \n[   41.679636] pc : __mutex_lock+0x670/0x878  \n[   41.683834] lr : __mutex_lock+0x670/0x878  \n[   41.688035] sp : ffff800084b77090  \n[   41.691446] x29: ffff800084b77160 x28: ffffdd4bebf7b000 x27: ffffdd4be96b1000  \n[   41.698799] x26: 1fffe0002308361c x25: 1ffff0001096ee18 x24: 0000000000000000  \n[   41.706149] x23: 0000000000000000 x22: 0000000000000002 x21: ffffdd4be6e3c7a0  \n[   41.713500] x20: ffff800084b770f0 x19: ffff00011841b1e8 x18: 0000000000000000  \n[   41.720675] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720  \n[   41.728023] x14: 0000000000000000 x13: 0000000000000001 x12: ffff6001a96eaab3  \n[   41.735375] x11: 1fffe001a96eaab2 x10: ffff6001a96eaab2 x9 : ffffdd4be4838bbc  \n[   41.742723] x8 : 00009ffe5691554e x7 : ffff000d4b755593 x6 : 0000000000000001  \n[   41.749985] x5 : ffff000d4b755590 x4 : 1fffe0001d88f001 x3 : dfff800000000000  \n[   41.756988] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ec478000  \n[   41.764251] Call trace:  \n[   41.766695]  __mutex_lock+0x670/0x878  \n[   41.770373]  mutex_lock_nested+0x2c/0x40  \n[   41.774134]  host1x_intr_start+0x54/0xf8 [host1x]  \n[   41.778863]  host1x_runtime_resume+0x150/0x228 [host1x]  \n[   41.783935]  pm_generic_runtime_resume+0x84/0xc8  \n[   41.788485]  __rpm_callback+0xa0/0x478  \n[   41.792422]  rpm_callback+0x15c/0x1a8  \n[   41.795922]  rpm_resume+0x698/0xc08  \n[   41.799597]  __pm_runtime_resume+0xa8/0x140  \n[   41.803621]  host1x_probe+0x810/0xbc0 [host1x]  \n[   41.807909]  platform_probe+0xcc/0x1a8  \n[   41.811845]  really_probe+0x188/0x800  \n[   41.815347]  __driver_probe_device+0x164/0x360  \n[   41.819810]  driver_probe_device+0x64/0x1a8  \n[   41.823834]  __driver_attach+0x180/0x490  \n[   41.827773]  bus_for_each_dev+0x104/0x1a0  \n[   41.831797]  driver_attach+0x44/0x68  \n[   41.835296]  bus_add_driver+0x23c/0x4e8  \n[   41.839235]  driver_register+0x15c/0x3a8  \n[   41.843170]  __platform_register_drivers+0xa4/0x208  \n[   41.848159]  tegra_host1x_init+0x4c/0xff8 [host1x]  \n[   41.853147]  do_one_initcall+0xd4/0x380  \n[   41.856997]  do_init_module+0x1dc/0x698  \n[   41.860758]  load_module+0xc70/0x1300  \n[   41.864435]  __do_sys_init_module+0x1a8/0x1d0  \n[   41.868721]  __arm64_sys_init_module+0x74/0xb0  \n[   41.873183]  invoke_syscall.constprop.0+0xdc/0x1e8  \n[   41.877997]  do_el0_svc+0x154/0x1d0  \n[   41.881671]  el0_svc+0x54/0x140  \n[   41.884820]  el0t_[...]", "creation_timestamp": "2025-02-27T23:27:06.000000Z"}, {"uuid": "091971c8-2227-4b25-81cd-df568d53c0a3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21823", "type": "seen", "source": "https://t.me/cvedetector/19086", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21823 - Batman-adv Linux Kernel RCU List Iterator Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21823 \nPublished : Feb. 27, 2025, 8:16 p.m. | 1\u00a0hour, 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbatman-adv: Drop unmanaged ELP metric worker  \n  \nThe ELP worker needs to calculate new metric values for all neighbors  \n\"reachable\" over an interface. Some of the used metric sources require  \nlocks which might need to sleep. This sleep is incompatible with the RCU  \nlist iterator used for the recorded neighbors. The initial approach to work  \naround of this problem was to queue another work item per neighbor and then  \nrun this in a new context.  \n  \nEven when this solved the RCU vs might_sleep() conflict, it has a major  \nproblems: Nothing was stopping the work item in case it is not needed  \nanymore - for example because one of the related interfaces was removed or  \nthe batman-adv module was unloaded - resulting in potential invalid memory  \naccesses.  \n  \nDirectly canceling the metric worker also has various problems:  \n  \n* cancel_work_sync for a to-be-deactivated interface is called with  \n  rtnl_lock held. But the code in the ELP metric worker also tries to use  \n  rtnl_lock() - which will never return in this case. This also means that  \n  cancel_work_sync would never return because it is waiting for the worker  \n  to finish.  \n* iterating over the neighbor list for the to-be-deactivated interface is  \n  currently done using the RCU specific methods. Which means that it is  \n  possible to miss items when iterating over it without the associated  \n  spinlock - a behaviour which is acceptable for a periodic metric check  \n  but not for a cleanup routine (which must \"stop\" all still running  \n  workers)  \n  \nThe better approch is to get rid of the per interface neighbor metric  \nworker and handle everything in the interface worker. The original problems  \nare solved by:  \n  \n* creating a list of neighbors which require new metric information inside  \n  the RCU protected context, gathering the metric according to the new list  \n  outside the RCU protected context  \n* only use rcu_trylock inside metric gathering code to avoid a deadlock  \n  when the cancel_delayed_work_sync is called in the interface removal code  \n  (which is called with the rtnl_lock held) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-27T23:27:02.000000Z"}, {"uuid": "99e66984-ceef-46d6-a639-dc5cd21a3f92", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21821", "type": "seen", "source": "https://t.me/cvedetector/19084", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21821 - Nokia 770 fbdev Omap Touchscreen DMA Scheduling Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21821 \nPublished : Feb. 27, 2025, 8:16 p.m. | 1\u00a0hour, 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfbdev: omap: use threaded IRQ for LCD DMA  \n  \nWhen using touchscreen and framebuffer, Nokia 770 crashes easily with:  \n  \n    BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000  \n    Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd  \n    CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2  \n    Hardware name: Nokia 770  \n    Call trace:  \n     unwind_backtrace from show_stack+0x10/0x14  \n     show_stack from dump_stack_lvl+0x54/0x5c  \n     dump_stack_lvl from __schedule_bug+0x50/0x70  \n     __schedule_bug from __schedule+0x4d4/0x5bc  \n     __schedule from schedule+0x34/0xa0  \n     schedule from schedule_preempt_disabled+0xc/0x10  \n     schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4  \n     __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4  \n     clk_prepare_lock from clk_set_rate+0x18/0x154  \n     clk_set_rate from sossi_read_data+0x4c/0x168  \n     sossi_read_data from hwa742_read_reg+0x5c/0x8c  \n     hwa742_read_reg from send_frame_handler+0xfc/0x300  \n     send_frame_handler from process_pending_requests+0x74/0xd0  \n     process_pending_requests from lcd_dma_irq_handler+0x50/0x74  \n     lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130  \n     __handle_irq_event_percpu from handle_irq_event+0x28/0x68  \n     handle_irq_event from handle_level_irq+0x9c/0x170  \n     handle_level_irq from generic_handle_domain_irq+0x2c/0x3c  \n     generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c  \n     omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c  \n     generic_handle_arch_irq from call_with_stack+0x1c/0x24  \n     call_with_stack from __irq_svc+0x94/0xa8  \n    Exception stack(0xc5255da0 to 0xc5255de8)  \n    5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248  \n    5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94  \n    5de0: 60000013 ffffffff  \n     __irq_svc from clk_prepare_lock+0x4c/0xe4  \n     clk_prepare_lock from clk_get_rate+0x10/0x74  \n     clk_get_rate from uwire_setup_transfer+0x40/0x180  \n     uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c  \n     spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664  \n     spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498  \n     __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8  \n     __spi_sync from spi_sync+0x24/0x40  \n     spi_sync from ads7846_halfd_read_state+0x5c/0x1c0  \n     ads7846_halfd_read_state from ads7846_irq+0x58/0x348  \n     ads7846_irq from irq_thread_fn+0x1c/0x78  \n     irq_thread_fn from irq_thread+0x120/0x228  \n     irq_thread from kthread+0xc8/0xe8  \n     kthread from ret_from_fork+0x14/0x28  \n  \nAs a quick fix, switch to a threaded IRQ which provides a stable system. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-27T23:27:00.000000Z"}, {"uuid": "1ec2330f-9648-4973-bd53-7c0a50eec740", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21820", "type": "seen", "source": "https://t.me/cvedetector/19082", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21820 - Xilinx tty UART Lock Deadlock Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21820 \nPublished : Feb. 27, 2025, 8:16 p.m. | 1\u00a0hour, 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntty: xilinx_uartps: split sysrq handling  \n  \nlockdep detects the following circular locking dependency:  \n  \nCPU 0                      CPU 1  \n========================== ============================  \ncdns_uart_isr()            printk()  \n  uart_port_lock(port)       console_lock()  \n        cdns_uart_console_write()  \n                               if (!port->sysrq)  \n                                 uart_port_lock(port)  \n  uart_handle_break()  \n    port->sysrq = ...  \n  uart_handle_sysrq_char()  \n    printk()  \n      console_lock()  \n  \nThe fixed commit attempts to avoid this situation by only taking the  \nport lock in cdns_uart_console_write if port->sysrq unset. However, if  \n(as shown above) cdns_uart_console_write runs before port->sysrq is set,  \nthen it will try to take the port lock anyway. This may result in a  \ndeadlock.  \n  \nFix this by splitting sysrq handling into two parts. We use the prepare  \nhelper under the port lock and defer handling until we release the lock. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-27T23:26:58.000000Z"}, {"uuid": "aee2b136-abbc-486e-aaac-9deac5f8d322", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21822", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/5785", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21822\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nptp: vmclock: Set driver data before its usage\n\nIf vmclock_ptp_register() fails during probing, vmclock_remove() is\ncalled to clean up the ptp clock and misc device.\nIt uses dev_get_drvdata() to access the vmclock state.\nHowever the driver data is not yet set at this point.\n\nAssign the driver data earlier.\n\ud83d\udccf Published: 2025-02-27T20:06:13.422Z\n\ud83d\udccf Modified: 2025-02-27T20:06:13.422Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/6dbd8b91a065d1d8001446a28e72cd140f9acef0\n2. https://git.kernel.org/stable/c/f7d07cd4f77d77f366c8ffbb8ba8b61f614e5fce", "creation_timestamp": "2025-02-27T20:25:48.000000Z"}, {"uuid": "a6050887-ea65-4be1-944b-c4ee89b6e76a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21823", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/5784", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21823\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\"reachable\" over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n  rtnl_lock held. But the code in the ELP metric worker also tries to use\n  rtnl_lock() - which will never return in this case. This also means that\n  cancel_work_sync would never return because it is waiting for the worker\n  to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n  currently done using the RCU specific methods. Which means that it is\n  possible to miss items when iterating over it without the associated\n  spinlock - a behaviour which is acceptable for a periodic metric check\n  but not for a cleanup routine (which must \"stop\" all still running\n  workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n  the RCU protected context, gathering the metric according to the new list\n  outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n  when the cancel_delayed_work_sync is called in the interface removal code\n  (which is called with the rtnl_lock held)\n\ud83d\udccf Published: 2025-02-27T20:06:14.074Z\n\ud83d\udccf Modified: 2025-02-27T20:06:14.074Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/781a06fd265a8151f7601122d9c2e985663828ff\n2. https://git.kernel.org/stable/c/a7aa2317285806640c844acd4cd2cd768e395264\n3. https://git.kernel.org/stable/c/0fdc3c166ac17b26014313fa2b93696354511b24\n4. https://git.kernel.org/stable/c/af264c2a9adc37f4bdf88ca7f3affa15d8c7de9e\n5. https://git.kernel.org/stable/c/8c8ecc98f5c65947b0070a24bac11e12e47cc65d", "creation_timestamp": "2025-02-27T20:25:47.000000Z"}, {"uuid": "4578a80a-d9e5-4fee-810a-8bd6ffe93d9d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21820", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/5788", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21820\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ntty: xilinx_uartps: split sysrq handling\n\nlockdep detects the following circular locking dependency:\n\nCPU 0                      CPU 1\n========================== ============================\ncdns_uart_isr()            printk()\n  uart_port_lock(port)       console_lock()\n        cdns_uart_console_write()\n                               if (!port->sysrq)\n                                 uart_port_lock(port)\n  uart_handle_break()\n    port->sysrq = ...\n  uart_handle_sysrq_char()\n    printk()\n      console_lock()\n\nThe fixed commit attempts to avoid this situation by only taking the\nport lock in cdns_uart_console_write if port->sysrq unset. However, if\n(as shown above) cdns_uart_console_write runs before port->sysrq is set,\nthen it will try to take the port lock anyway. This may result in a\ndeadlock.\n\nFix this by splitting sysrq handling into two parts. We use the prepare\nhelper under the port lock and defer handling until we release the lock.\n\ud83d\udccf Published: 2025-02-27T20:04:17.930Z\n\ud83d\udccf Modified: 2025-02-27T20:04:17.930Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/de5bd24197bd9ee37ec1e379a3d882bbd15c5065\n2. https://git.kernel.org/stable/c/8ea0e7b3d7b8f2f0fc9db491ff22a0abe120801c\n3. https://git.kernel.org/stable/c/9b88a7c4584ba67267a051069b8abe44fc9595b2\n4. https://git.kernel.org/stable/c/4410dba9807a17a93f649a9f5870ceaf30a675a3\n5. https://git.kernel.org/stable/c/b06f388994500297bb91be60ffaf6825ecfd2afe", "creation_timestamp": "2025-02-27T20:25:53.000000Z"}, {"uuid": "4a7457bb-1c03-4c93-94d0-df9aa573db99", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21829", "type": "seen", "source": "https://t.me/cvedetector/19722", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21829 - \"RDMA/RXE Memory Corruption Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21829 \nPublished : March 6, 2025, 5:15 p.m. | 1\u00a0hour ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nRDMA/rxe: Fix the warning \"__rxe_cleanup+0x12c/0x170 [rdma_rxe]\"  \n  \nThe Call Trace is as below:  \n\"  \n    \n  ? show_regs.cold+0x1a/0x1f  \n  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]  \n  ? __warn+0x84/0xd0  \n  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]  \n  ? report_bug+0x105/0x180  \n  ? handle_bug+0x46/0x80  \n  ? exc_invalid_op+0x19/0x70  \n  ? asm_exc_invalid_op+0x1b/0x20  \n  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]  \n  ? __rxe_cleanup+0x124/0x170 [rdma_rxe]  \n  rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe]  \n  ib_destroy_qp_user+0x118/0x190 [ib_core]  \n  rdma_destroy_qp.cold+0x43/0x5e [rdma_cm]  \n  rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core]  \n  rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server]  \n  process_one_work+0x21d/0x3f0  \n  worker_thread+0x4a/0x3c0  \n  ? process_one_work+0x3f0/0x3f0  \n  kthread+0xf0/0x120  \n  ? kthread_complete_and_exit+0x20/0x20  \n  ret_from_fork+0x22/0x30  \n    \n\"  \nWhen too many rdma resources are allocated, rxe needs more time to  \nhandle these rdma resources. Sometimes with the current timeout, rxe  \ncan not release the rdma resources correctly.  \n  \nCompared with other rdma drivers, a bigger timeout is used. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"06 Mar 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-03-06T19:41:41.000000Z"}]}