Total
4678 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-53168 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: ucsi_acpi: Increase the command completion timeout Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command completion timeout value") increased the timeout from 5 seconds to 60 seconds due to issues related to alternate mode discovery. After the alternate mode discovery switch to polled mode the timeout was reduced, but instead of being set back to 5 seconds it was reduced to 1 second. This is causing problems when using a Lenovo ThinkPad X1 yoga gen7 connected over Type-C to a LG 27UL850-W (charging DP over Type-C). When the monitor is already connected at boot the following error is logged: "PPM init failed (-110)", /sys/class/typec is empty and on unplugging the NULL pointer deref fixed earlier in this series happens. When the monitor is connected after boot the following error is logged instead: "GET_CONNECTOR_STATUS failed (-110)". Setting the timeout back to 5 seconds fixes both cases. | ||||
| CVE-2023-53167 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Fix null pointer dereference in tracing_err_log_open() Fix an issue in function 'tracing_err_log_open'. The function doesn't call 'seq_open' if the file is opened only with write permissions, which results in 'file->private_data' being left as null. If we then use 'lseek' on that opened file, 'seq_lseek' dereferences 'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic. Writing to this node requires root privileges, therefore this bug has very little security impact. Tracefs node: /sys/kernel/tracing/error_log Example Kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 Call trace: mutex_lock+0x30/0x110 seq_lseek+0x34/0xb8 __arm64_sys_lseek+0x6c/0xb8 invoke_syscall+0x58/0x13c el0_svc_common+0xc4/0x10c do_el0_svc+0x24/0x98 el0_svc+0x24/0x88 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1b4/0x1b8 Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02) ---[ end trace 561d1b49c12cf8a5 ]--- Kernel panic - not syncing: Oops: Fatal exception | ||||
| CVE-2022-50244 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() If device_register() fails in cxl_pci_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails. | ||||
| CVE-2025-38689 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Fix NULL dereference in avx512_status() Problem ------- With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status causes a warning and a NULL pointer dereference. This is because the AVX-512 timestamp code uses x86_task_fpu() but doesn't check it for NULL. CONFIG_X86_DEBUG_FPU addles that function for kernel threads (PF_KTHREAD specifically), making it return NULL. The point of the warning was to ensure that kernel threads only access task->fpu after going through kernel_fpu_begin()/_end(). Note: all kernel tasks exposed in /proc have a valid task->fpu. Solution -------- One option is to silence the warning and check for NULL from x86_task_fpu(). However, that warning is fairly fresh and seems like a defense against misuse of the FPU state in kernel threads. Instead, stop outputting AVX-512_elapsed_ms for kernel threads altogether. The data was garbage anyway because avx512_timestamp is only updated for user threads, not kernel threads. If anyone ever wants to track kernel thread AVX-512 use, they can come back later and do it properly, separate from this bug fix. [ dhansen: mostly rewrite changelog ] | ||||
| CVE-2025-38705 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix null pointer access Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference. | ||||
| CVE-2025-65502 | 2025-11-24 | 4.3 Medium | ||
| Null pointer dereference in add_ca_certs() in Cesanta Mongoose before 7.2 allows remote attackers to cause a denial of service via TLS initialization where SSL_CTX_get_cert_store() returns NULL. | ||||
| CVE-2025-65501 | 2025-11-24 | 4.3 Medium | ||
| Null pointer dereference in coap_dtls_info_callback() in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a DTLS handshake where SSL_get_app_data() returns NULL. | ||||
| CVE-2025-65500 | 2025-11-24 | 4.3 Medium | ||
| NULL pointer dereference in coap_dtls_generate_cookie() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS handshake that triggers SSL_get_SSL_CTX() to return NULL. | ||||
| CVE-2025-65498 | 2025-11-24 | 4.3 Medium | ||
| NULL pointer dereference in coap_dtls_generate_cookie() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS handshake that triggers SSL_get_SSL_CTX() to return NULL. | ||||
| CVE-2025-65497 | 2025-11-24 | 4.3 Medium | ||
| NULL pointer dereference in coap_dtls_generate_cookie() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS handshake that triggers SSL_get_SSL_CTX() to return NULL. | ||||
| CVE-2025-65496 | 2025-11-24 | 4.3 Medium | ||
| NULL pointer dereference in coap_dtls_generate_cookie() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS handshake that triggers SSL_get_SSL_CTX() to return NULL. | ||||
| CVE-2025-65494 | 2025-11-24 | 7.5 High | ||
| NULL pointer dereference in get_san_or_cn_from_cert() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted X.509 certificate that causes sk_GENERAL_NAME_value() to return NULL. | ||||
| CVE-2025-65493 | 2025-11-24 | 7.5 High | ||
| NULL pointer dereference in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS/TLS connection that triggers BIO_get_data() to return NULL. | ||||
| CVE-2025-22103 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan. | ||||
| CVE-2024-49998 | 1 Linux | 1 Linux Kernel | 2025-11-24 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up). | ||||
| CVE-2025-13425 | 1 Google | 1 Osv-scalibr | 2025-11-24 | 3.3 Low |
| A bug in the filesystem traversal fallback path causes fs/diriterate/diriterate.go:Next() to overindex an empty slice when ReadDir returns nil for an empty directory, resulting in a panic (index out of range) and an application crash (denial of service) in OSV-SCALIBR. | ||||
| CVE-2025-13397 | 1 Mruby | 1 Mruby | 2025-11-24 | 3.3 Low |
| A security vulnerability has been detected in mrubyc up to 3.4. This impacts the function mrbc_raw_realloc of the file src/alloc.c. Such manipulation of the argument ptr leads to null pointer dereference. An attack has to be approached locally. The name of the patch is 009111904807b8567262036bf45297c3da8f1c87. It is advisable to implement a patch to correct this issue. | ||||
| CVE-2025-64169 | 1 Wazuh | 1 Wazuh | 2025-11-24 | N/A |
| Wazuh is a free and open source platform used for threat prevention, detection, and response. From version 3.7.0 to before 4.12.0, fim_alert() implementation does not check whether oldsum->md5 is NULL or not before dereferencing it. A compromised agent can cause a crash of analysisd by sending a specially crafted message to the wazuh manager. This issue has been patched in version 4.12.0. | ||||
| CVE-2025-62609 | 1 Ml-explore | 1 Mlx | 2025-11-24 | 5.3 Medium |
| MLX is an array framework for machine learning on Apple silicon. Prior to version 0.29.4, there is a segmentation fault in mlx::core::load_gguf() when loading malicious GGUF files. Untrusted pointer from external gguflib library is dereferenced without validation, causing application crash. This issue has been patched in version 0.29.4. | ||||
| CVE-2025-55698 | 1 Microsoft | 9 Directx, Windows, Windows 11 and 6 more | 2025-11-22 | 7.7 High |
| Null pointer dereference in Windows DirectX allows an authorized attacker to deny service over a network. | ||||