Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-37804 State: REJECTED Published: 2025-05-08T06:26:04.461Z Last Updated: 2025-05-20T13:54:16.401Z Description: No description available.
CVE ID: CVE-2025-37805 State: PUBLISHED Published: 2025-05-08T06:26:05.084Z Last Updated: 2025-11-03T19:55:35.422Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sound/virtio: Fix cancel_sync warnings on uninitialized work_structs Betty reported hitting the following warning: [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] __flush_work+0x8d0/0x914 [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc [ 8.713570][ T221] cancel_work_sync+0x24/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T22
/0x34 [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390 [ 8.714139][ T221] really_probe+0x1bc/0x4c8 ... It seems we're hitting the error path in virtsnd_probe(), which triggers a virtsnd_remove() which iterates over the substreams calling cancel_work_sync() on the elapsed_period work_struct. Looking at the code, from earlier in: virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or so
se_cfg() We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsnd_ctl_query_info() fails, we will exit without having initialized the elapsed_period work_struct. When that error path unwinds we then call virtsnd_remove() which as long as the substreams array is allocated, will iterate through calling cancel_work_sync() on the uninitialized work struct hitting this warning. Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this pa
hs we avoid trying to cleanup uninitialized data. Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing. Feedback or thoughts would be appreciated! Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e03b10c45c7675b6098190c6e7de1b656d8bcdbe - https://git.kernel.org/stable/c/54c7b864fbe4423a07b443a4ada0106052942116 - https://git.kernel.org/stable/c/5be9407b41eae20eef9140f5cfbfcbc3d01aaf45 - https://git.kernel.org/stable/c/66046b586c0aaa9332483bcdbd76e3305d6138e9 - https://git.kernel.org/stable/c/9908498ce929a5a052b79bb7942f9ea317312ce4 - https://git.kernel.org/stable/c/3c7df2e2734
- https://git.kernel.org/stable/c/9908498ce929a5a052b79bb7942f9ea317312ce4 - https://git.kernel.org/stable/c/3c7df2e27346eb40a0e86230db1ccab195c97cfe
CVE ID: CVE-2025-37806 State: PUBLISHED Published: 2025-05-08T06:26:05.689Z Last Updated: 2025-05-26T05:21:15.603Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Keep write operations atomic syzbot reported a NULL pointer dereference in __generic_file_write_iter. [1] Before the write operation is completed, the user executes ioctl[2] to clear the compress flag of the file, which causes the is_compressed() judgment to return 0, further causing the program to enter the wrong process and call the wrong ops ntfs_aops_cmpr, which triggers the null pointer dereference of write_begin. Use inode lock to synchronize ioctl and
ops ntfs_aops_cmpr, which triggers the null pointer dereference of write_begin. Use inode lock to synchronize ioctl and write to avoid this case. [1] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=000000011896d000 [0000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 Not tainted 6.13.0-rc3-
00000086000006 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055 sp : ffff80009d4978a0 x29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8 x26: 0000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68 x23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000 x20: 000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c x17: 0004060000000014 x16: ffff800083275834 x15
001000 x20: 000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c x17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001 x14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0 x11: 0000000000ff0100 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000 x2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0 Call trace: 0x0 (P) __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156 ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267 new_sync_write fs/read_write.c:586 [inline] vfs_write+0x920/0xcf4 fs/read_write.c:679 ksys_write+0x15c
ntfs3/file.c:1267 new_sync_write fs/read_write.c:586 [inline] vfs_write+0x920/0xcf4 fs/read_write.c:679 ksys_write+0x15c/0x26c fs/read_write.c:731 __do_sys_write fs/read_write.c:742 [inline] __se_sys_write fs/read_write.c:739 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:739 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 [2] ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20)
ndler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 [2] ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20) References: - https://git.kernel.org/stable/c/8db49e89a7f8b48ee59fa9ad32b6ed0879747df8 - https://git.kernel.org/stable/c/464139e18f619aa14fb921a61721862f43421c54 - https://git.kernel.org/stable/c/285cec318bf5a7a6c8ba999b2b6ec96f9a20590f
CVE ID: CVE-2025-37807 State: PUBLISHED Published: 2025-05-08T06:26:06.296Z Last Updated: 2025-05-26T05:21:16.806Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kmemleak warning for percpu hashmap Vlad Poenaru reported the following kmemleak issue: unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte ali
l_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak. In htab_map_alloc(), we already have htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->el
sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too. The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported. References: - https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe - https://git.kernel.org/stable/c/1
ferences: - https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe - https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df - https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286
CVE ID: CVE-2025-37808 State: PUBLISHED Published: 2025-05-08T06:26:06.886Z Last Updated: 2025-11-03T19:55:38.177Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: null - Use spin lock instead of mutex As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f7a5a5c8e1ec16a4b2041398abe95de0e14572ef - https://git.kernel.org/stable/c/e307c54ac8198bf09652c72603ba6e6d97798410 - https://git.kernel.org/stable/c/1dd4a8561d85dea545cf93f56efc48df8176e
table/c/e307c54ac8198bf09652c72603ba6e6d97798410 - https://git.kernel.org/stable/c/1dd4a8561d85dea545cf93f56efc48df8176e218 - https://git.kernel.org/stable/c/e27244cbe10658a66b8775be7f0acc4ad2f618d6 - https://git.kernel.org/stable/c/1b66a5920b7fc7cc6251192a3fcad115b6d75dd5 - https://git.kernel.org/stable/c/0486de3c1b8223138dcc614846bd76364f758de6 - https://git.kernel.org/stable/c/8cf2945512a8c0ef74ddd5b5a4f6b6a2fb1a4efb - https://git.kernel.org/stable/c/dcc47a028c24e793ce6d6efebfef1a1e92f80297
CVE ID: CVE-2025-37809 State: PUBLISHED Published: 2025-05-08T06:26:07.510Z Last Updated: 2025-05-26T05:21:19.579Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: class: Fix NULL pointer access Concurrent calls to typec_partner_unlink_device can lead to a NULL pointer dereference. This patch adds a mutex to protect USB device pointers and prevent this issue. The same mutex protects both the device pointers and the partner device registration. References: - https://git.kernel.org/stable/c/de7c24febd21413ea8f49f61b36338b676c02852 - https://git.kernel.org/stable/c/1fdde62411fe65640e69bc55ea027d5b7b2f0093 - https://git.k
1413ea8f49f61b36338b676c02852 - https://git.kernel.org/stable/c/1fdde62411fe65640e69bc55ea027d5b7b2f0093 - https://git.kernel.org/stable/c/ec27386de23a511008c53aa2f3434ad180a3ca9a
CVE ID: CVE-2025-37810 State: PUBLISHED Published: 2025-05-08T06:26:08.144Z Last Updated: 2025-11-03T19:55:40.941Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: check that event count does not exceed event buffer length The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_ev
Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/015c39f38e69a491d2abd5e98869a500a9459b3b - https://git.kernel.org/stable/c/b43225948b231b3f331194010f84512bee4d9f59 - https://git.kernel.org/stable/c/c0079630f268843a25ed75226169cba40e0d8880 - https://git.kernel.org/stable/c/a44547015287a19001384fe94dbff84c92ce4ee1 - https://git.kernel.org/stable/c/c4d80e41cb42008dce
://git.kernel.org/stable/c/a44547015287a19001384fe94dbff84c92ce4ee1 - https://git.kernel.org/stable/c/c4d80e41cb42008dceb35e5dbf52574d93beac0d - https://git.kernel.org/stable/c/52a7c9d930b95aa8b1620edaba4818040c32631f - https://git.kernel.org/stable/c/99d655119b870ee60e4dbf310aa9a1ed8d9ede3d - https://git.kernel.org/stable/c/63ccd26cd1f6600421795f6ca3e625076be06c9f
CVE ID: CVE-2025-37811 State: PUBLISHED Published: 2025-05-08T06:26:08.746Z Last Updated: 2025-11-03T19:55:42.330Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: ci_hdrc_imx: fix usbmisc handling usbmisc is an optional device property so it is totally valid for the corresponding data->usbmisc_data to have a NULL value. Check that before dereferencing the pointer. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8060b719676e8c0e5a2222c2977ba0458d9d9535 - https://git.kernel.org/stab
er: References: - https://git.kernel.org/stable/c/8060b719676e8c0e5a2222c2977ba0458d9d9535 - https://git.kernel.org/stable/c/0ee460498ced49196149197c9f6d29a10e5e0798 - https://git.kernel.org/stable/c/121e9f80ea5478bca3a8f3f26593fd66f87da649 - https://git.kernel.org/stable/c/887902ca73490f38c69fd6149ef361a041cf912f - https://git.kernel.org/stable/c/2aa87bd825377f5073b76701780a902cd0fc725a - https://git.kernel.org/stable/c/4e28f79e3dffa52d327b46d1a78dac16efb5810b
CVE ID: CVE-2025-37812 State: PUBLISHED Published: 2025-05-08T06:26:09.355Z Last Updated: 2025-11-03T19:55:45.167Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: Fix deadlock when using NCM gadget The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget"). Under PREEMPT_RT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link. The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent de
ause the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/eebfb64c624fc738b669100173344fb441c5e719 - https://git.kernel.org/stable/c/59a760e4796a3cd88d8b9d7706e0a638de677751 - https://git.kernel.org/stable/c/b96239582531775f2fdcb14de29bdb6870fd4c8c - https://git.kernel.org/stable/c/c27db84ed44e50ff90d9e3a2a25fae2e0a0fa015 - https://git.kernel.org/stable/c/48a62deb857f0694f611949015e70ad194d97159 - https://git.kernel.org/stable/c/74cd6e408a4c010e404832f0e4609d29bf1d0c41 - https://
eb857f0694f611949015e70ad194d97159 - https://git.kernel.org/stable/c/74cd6e408a4c010e404832f0e4609d29bf1d0c41 - https://git.kernel.org/stable/c/09e90a9689a4aac7a2f726dc2aa472b0b37937b7 - https://git.kernel.org/stable/c/a1059896f2bfdcebcdc7153c3be2307ea319501f
CVE ID: CVE-2025-37813 State: PUBLISHED Published: 2025-05-08T06:26:10.000Z Last Updated: 2025-05-26T05:21:24.931Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix invalid pointer dereference in Etron workaround This check is performed before prepare_transfer() and prepare_ring(), so enqueue can already point at the final link TRB of a segment. And indeed it will, some 0.4% of times this code is called. Then enqueue + 1 is an invalid pointer. It will crash the kernel right away or load some junk which may look like a link TRB and cause the real link TRB to be replaced with a NOOP. This wouldn't end well. Use a func
hich may look like a link TRB and cause the real link TRB to be replaced with a NOOP. This wouldn't end well. Use a functionally equivalent test which doesn't dereference the pointer and always gives correct result. Something has crashed my machine twice in recent days while playing with an Etron HC, and a control transfer stress test ran for confirmation has just crashed it again. The same test passes with this patch applied. References: - https://git.kernel.org/stable/c/142273a49f2c315eabdbdf5a71c15e479b75ca91 - https://git.kernel.org/stable/c/bce3055b08e303e28a8751f6073066f5c33a0744 - https://git.kernel.org/stable/c/0624e29c595b05e7a0e6d1c368f0a05799928e30 - https://git.kernel.org/stable/
66f5c33a0744 - https://git.kernel.org/stable/c/0624e29c595b05e7a0e6d1c368f0a05799928e30 - https://git.kernel.org/stable/c/1ea050da5562af9b930d17cbbe9632d30f5df43a
CVE ID: CVE-2025-37814 State: PUBLISHED Published: 2025-05-08T06:26:10.723Z Last Updated: 2025-05-26T05:21:26.387Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT This requirement was overeagerly loosened in commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as it turns out, (1) the logic I implemented there was inconsistent (apologies!), (2) TIOCL_SELMOUSEREPORT might actually be a small security risk after all, and (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse daemon (GPM or Consolation), which runs as CAP_SYS
l, and (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN already. In more detail: 1. The previous patch has inconsistent logic: In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), we checked for sel_mode == TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of this "mode" parameter were actually used as an additional way to pass an argument. So the patch did actually still require CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not require it if none of the mouse buttons bits are set. This logic is inconsistent and was not intentional. We should have the same pol
none of the mouse buttons bits are set. This logic is inconsistent and was not intentional. We should have the same policies for using TIOCL_SELMOUSEREPORT independent of the value of the "hidden" mouse button argument. I sent a separate documentation patch to the man page list with more details on TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can let an attacker simulate "keyboard" input to command line applications on the same terminal, like TIOCSTI and some other TIOCLINUX "selection mode" IOCTLs. By enabling mouse reporting on a terminal and then injecting mouse reports thr
other TIOCLINUX "selection mode" IOCTLs. By enabling mouse reporting on a terminal and then injecting mouse reports through TIOCL_SELMOUSEREPORT, an attacker can simulate mouse movements on the same terminal, similar to the TIOCSTI keystroke injection attacks that were previously possible with TIOCSTI and other TIOCL_SETSEL selection modes. Many programs (including libreadline/bash) are then prone to misinterpret these mouse reports as normal keyboard input because they do not expect input in the X11 mouse protocol form. The attacker does not have complete control over the escape sequence, but they can at least control the values of two consecutive bytes in the binary mouse reporting escape
escape sequence, but they can at least control the values of two consecutive bytes in the binary mouse reporting escape sequence. I went into more detail on that in the discussion at https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ It is not equally trivial to simulate arbitrary keystrokes as it was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be disabled")), but the general mechanism is there, and together with the small number of existing legit use cases (see below), it would be better to revert back to requiring CAP_SYS_ADMIN for TIOCL_SELMOUSEREPORT, as it was already the case before commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMI
REPORT, as it was already the case before commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or Consolation), and they are the only legit use case: To quote console_codes(4): The mouse tracking facility is intended to return xterm(1)-compatible mouse status reports. Because the console driver has no way to know the device or type of the mouse, these reports are returned in the console input stream only when the virtual terminal driver receives a mouse update ioctl. These ioctls must be generated by a mouse-aware user-mode application such as the gpm(8) daemon. Jared Finder has also confirmed in htt
st be generated by a mouse-aware user-mode application such as the gpm(8) daemon. Jared Finder has also confirmed in https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it would be difficult to find good reasons for doing that, given that it would interfere with the reports that GPM is sending. More information on the interaction between GPM, terminals and th ---truncated--- References: - https://git.kernel.org/stable/c/6f021bc0083b96125fdbed6a60d7b4396c4d6dac - https://git.kernel.org/stable/c/9b50c9c97db953de756a39af83d4be4d7f618aa6 - https://git.kernel.org/stable/c/ee6a44da3c87cf64d67dd02be8c0127a5bf56175
CVE ID: CVE-2025-37815 State: PUBLISHED Published: 2025-05-08T06:26:11.402Z Last Updated: 2025-11-03T19:55:46.585Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration Resolve kernel panic while accessing IRQ handler associated with the generated IRQ. This is done by acquiring the spinlock and storing the current interrupt state before handling the interrupt request using generic_handle_irq. A previous fix patch was submitted where 'generic_handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determi
handle_irq' was replaced with 'handle_nested_irq'. However, this change also causes the kernel panic where after determining which GPIO triggered the interrupt and attempting to call handle_nested_irq with the mapped IRQ number, leads to a failure in locating the registered handler. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1263d5f581908602c618c6665e683c4436383a09 - https://git.kernel.org/stable/c/62957f58ab3aa7fa792dc6ff3575624062539a4d - https://git.kernel.org/stable/c/12cc2193f2b9548e8ea5fbce8201b44158222edf - https://git.kernel.org/stable/c/4e02059dc91068bc5017b8546f9ec3b930f6d6a6 - https://git.kernel.org/stable/c/18eb77c75ed01439f96
//git.kernel.org/stable/c/4e02059dc91068bc5017b8546f9ec3b930f6d6a6 - https://git.kernel.org/stable/c/18eb77c75ed01439f96ae5c0f33461eb5134b907