Total
4678 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-60019 | 1 Redhat | 1 Enterprise Linux | 2025-11-21 | 3.7 Low |
| glib-networking's OpenSSL backend fails to properly check the return value of memory allocation routines. An out of memory condition could potentially result in writing to an invalid memory location. | ||||
| CVE-2025-4476 | 1 Redhat | 1 Enterprise Linux | 2025-11-21 | 4.3 Medium |
| A denial-of-service vulnerability has been identified in the libsoup HTTP client library. This flaw can be triggered when a libsoup client receives a 401 (Unauthorized) HTTP response containing a specifically crafted domain parameter within the WWW-Authenticate header. Processing this malformed header can lead to a crash of the client application using libsoup. An attacker could exploit this by setting up a malicious HTTP server. If a user's application using the vulnerable libsoup library connects to this malicious server, it could result in a denial-of-service. Successful exploitation requires tricking a user's client application into connecting to the attacker's malicious server. | ||||
| CVE-2023-7042 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-21 | 4.4 Medium |
| A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service. | ||||
| CVE-2023-6679 | 3 Fedoraproject, Linux, Redhat | 4 Fedora, Linux Kernel, Enterprise Linux and 1 more | 2025-11-21 | 5.5 Medium |
| A null pointer dereference vulnerability was found in dpll_pin_parent_pin_set() in drivers/dpll/dpll_netlink.c in the Digital Phase Locked Loop (DPLL) subsystem in the Linux kernel. This issue could be exploited to trigger a denial of service. | ||||
| CVE-2022-50181 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: virtio-gpu: fix a missing check to avoid NULL dereference 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. [ kraxel: minor codestyle fixup ] | ||||
| CVE-2025-38092 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: use list_first_entry_or_null for opinfo_get_list() The list_first_entry() macro never returns NULL. If the list is empty then it returns an invalid pointer. Use list_first_entry_or_null() to check if the list is empty. | ||||
| CVE-2022-50144 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: soundwire: revisit driver bind/unbind and callbacks In the SoundWire probe, we store a pointer from the driver ops into the 'slave' structure. This can lead to kernel oopses when unbinding codec drivers, e.g. with the following sequence to remove machine driver and codec driver. /sbin/modprobe -r snd_soc_sof_sdw /sbin/modprobe -r snd_soc_rt711 The full details can be found in the BugLink below, for reference the two following examples show different cases of driver ops/callbacks being invoked after the driver .remove(). kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150 kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence] kernel: RIP: 0010:mutex_lock+0x19/0x30 kernel: Call Trace: kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae] kernel: ? newidle_balance+0x26a/0x400 kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: BUG: unable to handle page fault for address: ffffffffc07654c8 kernel: Workqueue: pm pm_runtime_work kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus] kernel: Call Trace: kernel: <TASK> kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd] kernel: ? dpm_sysfs_remove+0x60/0x60 This was not detected earlier in Intel tests since the tests first remove the parent PCI device and shut down the bus. The sequence above is a corner case which keeps the bus operational but without a driver bound. While trying to solve this kernel oopses, it became clear that the existing SoundWire bus does not deal well with the unbind case. Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields") added a 'probed' status variable and a 'probe_complete' struct completion. This status is however not reset on remove and likewise the 'probe complete' is not re-initialized, so the bind/unbind/bind test cases would fail. The timeout used before the 'update_status' callback was also a bad idea in hindsight, there should really be no timing assumption as to if and when a driver is bound to a device. An initial draft was based on device_lock() and device_unlock() was tested. This proved too complicated, with deadlocks created during the suspend-resume sequences, which also use the same device_lock/unlock() as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS caused spurious resumes and the use of device_lock() caused hangs during suspend. After multiple weeks or testing and painful reverse-engineering of deadlocks on different devices, we looked for alternatives that did not interfere with the device core. A bus notifier was used successfully to keep track of DRIVER_BOUND and DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests, but it can still be defeated with a theoretical corner case where the memory is freed by a .remove while the callback is in use. The notifier only helps make sure the driver callbacks are valid, but not that the memory allocated in probe remains valid while the callbacks are invoked. This patch suggests the introduction of a new 'sdw_dev_lock' mutex protecting probe/remove and all driver callbacks. Since this mutex is 'local' to SoundWire only, it does not interfere with existing locks and does not create deadlocks. In addition, this patch removes the 'probe_complete' completion, instead we directly invoke the 'update_status' from the probe routine. That removes any sort of timing dependency and a much better support for the device/driver model, the driver could be bound before the bus started, or eons after the bus started and the hardware would be properly initialized in all cases. BugLink: https://github.com/thesofproject/linux/is ---truncated--- | ||||
| CVE-2022-50145 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: sf-pdma: Add multithread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 64 > /sys/module/dmatest/parameters/threads_per_chan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one. With current fixes a descriptor changes its value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. Now it is just possible to queue a descriptor for further processing. | ||||
| CVE-2025-38121 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: avoid panic on init failure In case of an error during init, in_hw_restart will be set, but it will never get cleared. Instead, we will retry to init again, and then we will act like we are in a restart when we are actually not. This causes (among others) to a NULL pointer dereference when canceling rx_omi::finished_work, that was not even initialized, because we thought that we are in hw_restart. Set in_hw_restart to true only if the fw is running, then we know that FW was loaded successfully and we are not going to the retry loop. | ||||
| CVE-2025-38123 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Fix napi rx poll issue When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic. BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: <IRQ> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 </IRQ> | ||||
| CVE-2025-38130 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/connector: only call HDMI audio helper plugged cb if non-null On driver remove, sound/soc/codecs/hdmi-codec.c calls the plugged_cb with NULL as the callback function and codec_dev, as seen in its hdmi_remove function. The HDMI audio helper then happily tries calling said null function pointer, and produces an Oops as a result. Fix this by only executing the callback if fn is non-null. This means the .plugged_cb and .plugged_cb_dev members still get appropriately cleared. | ||||
| CVE-2025-2487 | 1 Redhat | 4 Directory Server, Directory Server Eus, Enterprise Linux and 1 more | 2025-11-20 | 4.9 Medium |
| A flaw was found in the 389-ds-base LDAP Server. This issue occurs when issuing a Modify DN LDAP operation through the ldap protocol, when the function return value is not tested and a NULL pointer is dereferenced. If a privileged user performs a ldap MODDN operation after a failed operation, it could lead to a Denial of Service (DoS) or system crash. | ||||
| CVE-2025-31181 | 2 Gnuplot, Redhat | 2 Gnuplot, Enterprise Linux | 2025-11-20 | 6.2 Medium |
| A flaw was found in gnuplot. The X11_graphics() function may lead to a segmentation fault and cause a system crash. | ||||
| CVE-2025-31180 | 2 Gnuplot, Redhat | 2 Gnuplot, Enterprise Linux | 2025-11-20 | 6.2 Medium |
| A flaw was found in gnuplot. The CANVAS_text() function may lead to a segmentation fault and cause a system crash. | ||||
| CVE-2025-31179 | 2 Gnuplot, Redhat | 2 Gnuplot, Enterprise Linux | 2025-11-20 | 6.2 Medium |
| A flaw was found in gnuplot. The xstrftime() function may lead to a segmentation fault, causing a system crash. | ||||
| CVE-2025-31178 | 2 Gnuplot, Redhat | 2 Gnuplot, Enterprise Linux | 2025-11-20 | 6.2 Medium |
| A flaw was found in gnuplot. The GetAnnotateString() function may lead to a segmentation fault and cause a system crash. | ||||
| CVE-2025-31176 | 2 Gnuplot, Redhat | 2 Gnuplot, Enterprise Linux | 2025-11-20 | 6.2 Medium |
| A flaw was found in gnuplot. The plot3d_points() function may lead to a segmentation fault and cause a system crash. | ||||
| CVE-2025-38156 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7996_mmio_wed_init() | ||||
| CVE-2025-38155 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init(). | ||||
| CVE-2025-38134 | 1 Linux | 1 Linux Kernel | 2025-11-20 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: acpi: Prevent null pointer dereference in usb_acpi_add_usb4_devlink() As demonstrated by the fix for update_port_device_state, commit 12783c0b9e2c ("usb: core: Prevent null pointer dereference in update_port_device_state"), usb_hub_to_struct_hub() can return NULL in certain scenarios, such as during hub driver unbind or teardown race conditions, even if the underlying usb_device structure exists. Plus, all other places that call usb_hub_to_struct_hub() in the same file do check for NULL return values. If usb_hub_to_struct_hub() returns NULL, the subsequent access to hub->ports[udev->portnum - 1] will cause a null pointer dereference. | ||||