| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| FRRouting/frr from v2.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the ospf_opaque_lsa_dump function at ospf_opaque.c. This vulnerability allows attackers to cause a Denial of Service (DoS) under specific malformed LSA conditions. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_ext_link_rmt_itf_addr function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_ext_link_adj_sid function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_link_info function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet. |
| In the Linux kernel, the following vulnerability has been resolved:
sfc: fix NULL dereferences in ef100_process_design_param()
Since cited commit, ef100_probe_main() and hence also
ef100_check_design_params() run before efx->net_dev is created;
consequently, we cannot netif_set_tso_max_size() or _segs() at this
point.
Move those netif calls to ef100_probe_netdev(), and also replace
netif_err within the design params code with pci_err. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE
There is a WARN_ON_ONCE to catch an unlikely situation when
domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless
happens we must avoid using a NULL pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
w1: fix NULL pointer dereference in probe
The w1_uart_probe() function calls w1_uart_serdev_open() (which includes
devm_serdev_device_open()) before setting the client ops via
serdev_device_set_client_ops(). This ordering can trigger a NULL pointer
dereference in the serdev controller's receive_buf handler, as it assumes
serdev->ops is valid when SERPORT_ACTIVE is set.
This is similar to the issue fixed in commit 5e700b384ec1
("platform/chrome: cros_ec_uart: properly fix race condition") where
devm_serdev_device_open() was called before fully initializing the
device.
Fix the race by ensuring client ops are set before enabling the port via
w1_uart_serdev_open(). |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix NULL dereference in SR-IOV VF creation error path
Clean up when virtfn setup fails to prevent NULL pointer dereference
during device removal. The kernel oops below occurred due to incorrect
error handling flow when pci_setup_device() fails.
Add pci_iov_scan_device(), which handles virtfn allocation and setup and
cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn't need
to call pci_stop_and_remove_bus_device(). This prevents accessing
partially initialized virtfn devices during removal.
BUG: kernel NULL pointer dereference, address: 00000000000000d0
RIP: 0010:device_del+0x3d/0x3d0
Call Trace:
pci_remove_bus_device+0x7c/0x100
pci_iov_add_virtfn+0xfa/0x200
sriov_enable+0x208/0x420
mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]
sriov_numvfs_store+0xae/0x1a0
[bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly] |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()
devm_kasprintf() returns NULL when memory allocation fails. Currently,
avs_component_probe() does not check for this case, which results in a
NULL pointer dereference. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_ext_link_lan_adj_sid function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_unknown_tlv function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_ext_pref_pref_sid function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet. |
| FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_ext_pref_pref_sid function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted LSA Update packet. |
| A missing validation check in FreeRTOS-Plus-TCP's UDP/IPv6 packet processing code can lead to an invalid pointer dereference when receiving a UDP/IPv6 packet with an incorrect IP version field in the packet header. This issue only affects applications using IPv6.
We recommend upgrading to the latest version and ensure any forked or derivative code is patched to incorporate the new fixes. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device
ethnl_req_get_phydev() is used to lookup a phy_device, in the case an
ethtool netlink command targets a specific phydev within a netdev's
topology.
It takes as a parameter a const struct nlattr *header that's used for
error handling :
if (!phydev) {
NL_SET_ERR_MSG_ATTR(extack, header,
"no phy matching phyindex");
return ERR_PTR(-ENODEV);
}
In the notify path after a ->set operation however, there's no request
attributes available.
The typical callsite for the above function looks like:
phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER],
info->extack);
So, when tb is NULL (such as in the ethnl notify path), we have a nice
crash.
It turns out that there's only the PLCA command that is in that case, as
the other phydev-specific commands don't have a notification.
This commit fixes the crash by passing the cmd index and the nlattr
array separately, allowing NULL-checking it directly inside the helper. |
| A vulnerability was detected in DCMTK up to 3.6.7. The impacted element is the function DcmQueryRetrieveConfig::readPeerList of the file /dcmqrcnf.cc of the component dcmqrscp. The manipulation results in null pointer dereference. The attack needs to be approached locally. The exploit is now public and may be used. Upgrading to version 3.6.8 is sufficient to resolve this issue. The patch is identified as 957fb31e5. Upgrading the affected component is advised. |
| The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. |
| An error in the ECMA-262 specification relating to Async Generators could have resulted in a type confusion, potentially leading to memory corruption and an exploitable crash. This vulnerability affects Firefox < 128, Firefox ESR < 115.13, Thunderbird < 115.13, and Thunderbird < 128. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: gpib: Fix Oops after disconnect in ni_usb
If the usb dongle is disconnected subsequent calls to the
driver cause a NULL dereference Oops as the bus_interface
is set to NULL on disconnect.
This problem was introduced by setting usb_dev from the bus_interface
for dev_xxx messages.
Previously bus_interface was checked for NULL only in the the functions
directly calling usb_fill_bulk_urb or usb_control_msg.
Check for valid bus_interface on all interface entry points
and return -ENODEV if it is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: gpib: Fix Oops after disconnect in agilent usb
If the agilent usb dongle is disconnected subsequent calls to the
driver cause a NULL dereference Oops as the bus_interface
is set to NULL on disconnect.
This problem was introduced by setting usb_dev from the bus_interface
for dev_xxx messages.
Previously bus_interface was checked for NULL only in the functions
directly calling usb_fill_bulk_urb or usb_control_msg.
Check for valid bus_interface on all interface entry points
and return -ENODEV if it is NULL. |
