Total
4932 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-6535 | 2 Linux, Redhat | 16 Linux Kernel, Codeready Linux Builder Eus, Codeready Linux Builder Eus For Power Little Endian Eus and 13 more | 2025-11-04 | N/A | 6.5 MEDIUM |
| A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service. | |||||
| CVE-2023-6356 | 3 Debian, Linux, Redhat | 17 Debian Linux, Linux Kernel, Codeready Linux Builder Eus and 14 more | 2025-11-04 | N/A | 6.5 MEDIUM |
| A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service. | |||||
| CVE-2023-49936 | 1 Schedmd | 1 Slurm | 2025-11-04 | N/A | 7.5 HIGH |
| An issue was discovered in SchedMD Slurm 22.05.x, 23.02.x, and 23.11.x. A NULL pointer dereference leads to denial of service. The fixed versions are 22.05.11, 23.02.7, and 23.11.1. | |||||
| CVE-2023-46838 | 3 Debian, Fedoraproject, Linux | 3 Debian Linux, Fedora, Linux Kernel | 2025-11-04 | N/A | 7.5 HIGH |
| Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code. | |||||
| CVE-2023-45931 | 1 Mesa3d | 1 Mesa | 2025-11-04 | N/A | 7.5 HIGH |
| Mesa 23.0.4 was discovered to contain a NULL pointer dereference in check_xshm() for the has_error state. NOTE: this is disputed because there is no scenario in which the vulnerability was demonstrated. | |||||
| CVE-2023-45920 | 1 Xfig Project | 1 Xfig | 2025-11-04 | N/A | 4.2 MEDIUM |
| Xfig v3.2.8 was discovered to contain a NULL pointer dereference when calling XGetWMHints(). NOTE: this is disputed because it is not expected that an X application should continue to run when there is arbitrary anomalous behavior from the X server or window manager. | |||||
| CVE-2023-45913 | 1 Mesa3d | 1 Mesa | 2025-11-04 | N/A | 6.2 MEDIUM |
| Mesa v23.0.4 was discovered to contain a NULL pointer dereference via the function dri2GetGlxDrawableFromXDrawableId(). This vulnerability is triggered when the X11 server sends an DRI2_BufferSwapComplete event unexpectedly when the application is using DRI3. NOTE: this is disputed because there is no scenario in which the vulnerability was demonstrated. | |||||
| CVE-2023-43279 | 2 Broadcom, Fedoraproject | 2 Tcpreplay, Fedora | 2025-11-04 | N/A | 6.5 MEDIUM |
| Null Pointer Dereference in mask_cidr6 component at cidr.c in Tcpreplay 4.4.4 allows attackers to crash the application via crafted tcprewrite command. | |||||
| CVE-2025-37784 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: ti: icss-iep: Fix possible NULL pointer dereference for perout request The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icss_iep_exit(), results in NULL pointer dereference for perout. To fix the null pointer dereference issue, the icss_iep_perout_enable_hw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptp_perout_request structure, as its contents are irrelevant in this case. | |||||
| CVE-2025-37792 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: Prevent potential NULL dereference The btrtl_initialize() function checks that rtl_load_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch: drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR' | |||||
| CVE-2024-38637 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: greybus: lights: check return of get_channel_from_mode If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru | |||||
| CVE-2024-38633 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Update uart_driver_registered on driver removal The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. | |||||
| CVE-2024-38612 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 9.8 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. | |||||
| CVE-2024-38559 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 4.4 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. | |||||
| CVE-2024-36014 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/arm/malidp: fix a possible null pointer dereference In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. | |||||
| CVE-2024-26998 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: serial: core: Clearing the circular buffer before NULLifying it The circular buffer is NULLified in uart_tty_port_shutdown() under the spin lock. However, the PM or other timer based callbacks may still trigger after this event without knowning that buffer pointer is not valid. Since the serial code is a bit inconsistent in checking the buffer state (some rely on the head-tail positions, some on the buffer pointer), it's better to have both aligned, i.e. buffer pointer to be NULL and head-tail possitions to be the same, meaning it's empty. This will prevent asynchronous calls to dereference NULL pointer as reported recently in 8250 case: BUG: kernel NULL pointer dereference, address: 00000cf5 Workqueue: pm pm_runtime_work EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) ... ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809) __start_tx (drivers/tty/serial/8250/8250_port.c:1551) serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654) serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63) __rpm_callback (drivers/base/power/runtime.c:393) ? serial_port_remove (drivers/tty/serial/serial_port.c:50) rpm_suspend (drivers/base/power/runtime.c:447) The proposed change will prevent ->start_tx() to be called during suspend on shut down port. | |||||
| CVE-2024-26924 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-04 | N/A | 5.9 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano) | |||||
| CVE-2025-37748 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix NULL pointer deference in mtk_iommu_device_group Currently, mtk_iommu calls during probe iommu_device_register before the hw_list from driver data is initialized. Since iommu probing issue fix, it leads to NULL pointer dereference in mtk_iommu_device_group when hw_list is accessed with list_first_entry (not null safe). So, change the call order to ensure iommu_device_register is called after the driver data are initialized. | |||||
| CVE-2025-37758 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe() devm_ioremap() returns NULL on error. Currently, pxa_ata_probe() does not check for this case, which can result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. | |||||
| CVE-2025-22099 | 1 Linux | 1 Linux Kernel | 2025-11-04 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init devm_kasprintf() calls can return null pointers on failure. But some return values were not checked in zynqmp_audio_init(). Add NULL check in zynqmp_audio_init(), avoid referencing null pointers in the subsequent code. | |||||