Total
33822 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-39831 | 1 Linux | 1 Linux Kernel | 2025-12-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fbnic: Move phylink resume out of service_task and into open/close The fbnic driver was presenting with the following locking assert coming out of a PM resume: [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611) [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0 [ 42.208872][ T164] Modules linked in: [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full) [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0 [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 <0f> 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296 [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000 [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001 [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84 [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000 [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0 [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000 [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0 [ 42.213227][ T164] PKRU: 55555554 [ 42.213366][ T164] Call Trace: [ 42.213483][ T164] <TASK> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0 [ 42.213725][ T164] pci_reset_function+0x116/0x1d0 [ 42.213895][ T164] reset_store+0xa0/0x100 [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50 [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0 [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160 [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0 [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0 [ 42.214836][ T164] new_sync_write+0x308/0x6f0 [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740 [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0 [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260 [ 42.215440][ T164] ? ksys_write+0xff/0x200 [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0 [ 42.215742][ T164] vfs_write+0x65e/0xbb0 [ 42.215876][ T164] ksys_write+0xff/0x200 [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0 [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0 [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0 [ 42.216442][ T164] do_syscall_64+0xbb/0x360 [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986 A bit of digging showed that we were invoking the phylink_resume as a part of the fbnic_up path when we were enabling the service task while not holding the RTNL lock. We should be enabling this sooner as a part of the ndo_open path and then just letting the service task come online later. This will help to enforce the correct locking and brings the phylink interface online at the same time as the network interface, instead of at a later time. I tested this on QEMU to verify this was working by putting the system to sleep using "echo mem > /sys/power/state" to put the system to sleep in the guest and then using the command "system_wakeup" in the QEMU monitor. | |||||
| CVE-2025-39829 | 1 Linux | 1 Linux Kernel | 2025-12-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: <TASK> blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path. | |||||
| CVE-2025-39822 | 1 Linux | 1 Linux Kernel | 2025-12-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: fix signedness in this_len calculation When importing and using buffers, buf->len is considered unsigned. However, buf->len is converted to signed int when committing. This can lead to unexpected behavior if the buffer is large enough to be interpreted as a negative value. Make min_t calculation unsigned. | |||||
| CVE-2025-33191 | 1 Nvidia | 2 Dgx Os, Dgx Spark | 2025-12-02 | N/A | 5.7 MEDIUM |
| NVIDIA DGX Spark GB10 contains a vulnerability in OSROOT firmware, where an attacker could cause an invalid memory read. A successful exploit of this vulnerability might lead to denial of service. | |||||
| CVE-2025-33193 | 1 Nvidia | 2 Dgx Os, Dgx Spark | 2025-12-02 | N/A | 5.7 MEDIUM |
| NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper validation of integrity. A successful exploit of this vulnerability might lead to information disclosure. | |||||
| CVE-2025-30201 | 1 Wazuh | 1 Wazuh | 2025-12-02 | N/A | 7.7 HIGH |
| Wazuh is a free and open source platform used for threat prevention, detection, and response. Prior to version 4.13.0, a vulnerability in Wazuh Agent allows authenticated attackers to force NTLM authentication through malicious UNC paths in various agent configuration settings, potentially leading NTLM relay attacks that would result privilege escalation and remote code execution. This issue has been patched in version 4.13.0. | |||||
| CVE-2025-61619 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-61618 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-61617 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-61610 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-61609 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-61608 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-61607 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-3012 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In dpc modem, there is a possible system crash due to null pointer dereference. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-11133 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-11132 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed | |||||
| CVE-2025-63525 | 1 Shridharshukl | 1 Blood Bank Management System | 2025-12-02 | N/A | 9.6 CRITICAL |
| An issue was discovered in Blood Bank Management System 1.0 allowing authenticated attackers to perform actions with escalated privileges via crafted request to delete.php. | |||||
| CVE-2023-53171 | 1 Linux | 1 Linux Kernel | 2025-12-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task's mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch. | |||||
| CVE-2023-53175 | 1 Linux | 1 Linux Kernel | 2025-12-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hv_pci_restore_msi_msg() -> msi_lock_descs(&pdev->dev), because pdev->dev.msi.data is still NULL. Avoid the panic by checking if MSI-X/MSI is enabled. | |||||
| CVE-2023-53176 | 1 Linux | 1 Linux Kernel | 2025-12-02 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Reinit port->pm on port specific driver unbind When we unbind a serial port hardware specific 8250 driver, the generic serial8250 driver takes over the port. After that we see an oops about 10 seconds later. This can produce the following at least on some TI SoCs: Unhandled fault: imprecise external abort (0x1406) Internal error: : 1406 [#1] SMP ARM Turns out that we may still have the serial port hardware specific driver port->pm in use, and serial8250_pm() tries to call it after the port specific driver is gone: serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base] uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base] uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c disassociate_ctty from do_exit+0x744/0xaac do_exit from do_group_exit+0x40/0x8c do_group_exit from __wake_up_parent+0x0/0x1c Let's fix the issue by calling serial8250_set_defaults() in serial8250_unregister_port(). This will set the port back to using the serial8250 default functions, and sets the port->pm to point to serial8250_pm. | |||||