Total
33786 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-61617 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2025-12-02 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 2 Blood Bank Management System Project, Shridharshukl | 2 Blood Bank Management System, Blood Bank Management System | 2025-12-02 | 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 | 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 | 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 | 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. | ||||
| CVE-2023-53181 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-resv: Stop leaking on krealloc() failure Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. | ||||
| CVE-2023-53182 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ACPICA: Avoid undefined behavior: applying zero offset to null pointer ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. | ||||
| CVE-2023-53185 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes A bad USB device is able to construct a service connection response message with target endpoint being ENDPOINT0 which is reserved for HTC_CTRL_RSVD_SVC and should not be modified to be used for any other services. Reject such service connection responses. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ||||
| CVE-2023-53193 | 1 Linux | 1 Linux Kernel | 2025-12-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini The gmc.ecc_irq is enabled by firmware per IFWI setting, and the host driver is not privileged to enable/disable the interrupt. So, it is meaningless to use the amdgpu_irq_put function in gmc_v10_0_hw_fini, which also leads to the call trace. [ 82.340264] Call Trace: [ 82.340265] <TASK> [ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu] [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu] [ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu] [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu] [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu] [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu] [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu] [ 82.341529] process_one_work+0x21d/0x3f0 [ 82.341535] worker_thread+0x1fa/0x3c0 [ 82.341538] ? process_one_work+0x3f0/0x3f0 [ 82.341540] kthread+0xff/0x130 [ 82.341544] ? kthread_complete_and_exit+0x20/0x20 [ 82.341547] ret_from_fork+0x22/0x30 | ||||
| CVE-2025-64312 | 1 Huawei | 1 Harmonyos | 2025-12-02 | 4.9 Medium |
| Permission control vulnerability in the file management module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-58305 | 1 Huawei | 1 Harmonyos | 2025-12-02 | 6.2 Medium |
| Identity authentication bypass vulnerability in the Gallery app. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-58304 | 1 Huawei | 1 Harmonyos | 2025-12-02 | 4.9 Medium |
| Permission control vulnerability in the file management module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||
| CVE-2025-58302 | 1 Huawei | 2 Emui, Harmonyos | 2025-12-02 | 8.4 High |
| Permission control vulnerability in the Settings module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | ||||