| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, a null-pointer dereference (NPD) in CIccTagLut16::Write() can be triggered when processing a crafted ICC profile (embedded in a TIFF and extracted during iccTiffDump). This issue has been patched in version 2.3.1.6. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, there is an Undefined Behavior (UB) issue in IccTagLut.cpp where the code performs member access through a null pointer of type CIccApplyCLUT. This issue has been patched in version 2.3.1.6. |
| The issue was addressed with improved checks. This issue is fixed in Safari 18.5, iOS 18.5 and iPadOS 18.5, iPadOS 17.7.7, macOS Sequoia 15.5, tvOS 18.5, visionOS 2.5, watchOS 11.5. Processing maliciously crafted web content may lead to an unexpected process crash. |
| The issue was addressed with improved checks. This issue is fixed in iOS 18.4 and iPadOS 18.4, iPadOS 17.7.6, macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.4, visionOS 2.4, watchOS 11.4. An attacker on the local network may cause an unexpected app termination. |
| A null pointer dereference was addressed with improved input validation. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5, tvOS 18.3, visionOS 2.3. An attacker on the local network may be able to cause a denial-of-service. |
| A null pointer dereference was addressed with improved input validation. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.6, macOS Sequoia 15.3, macOS Sonoma 14.7.5, macOS Ventura 13.7.5. An attacker on the local network may be able to cause a denial-of-service. |
| A null pointer dereference was addressed with improved input validation. This issue is fixed in iOS 18.7.7 and iPadOS 18.7.7, iOS 26.4 and iPadOS 26.4, macOS Sequoia 15.7.5, macOS Sonoma 14.8.5, macOS Tahoe 26.4, tvOS 26.4, visionOS 26.4, watchOS 26.4. A user in a privileged network position may be able to cause a denial-of-service. |
| A null pointer dereference was addressed with improved input validation. This issue is fixed in iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4, tvOS 18.4, visionOS 2.4. An attacker on the local network may be able to cause a denial-of-service. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: Fix PTP NULL pointer dereference during VSI rebuild
Fix race condition where PTP periodic work runs while VSI is being
rebuilt, accessing NULL vsi->rx_rings.
The sequence was:
1. ice_ptp_prepare_for_reset() cancels PTP work
2. ice_ptp_rebuild() immediately queues PTP work
3. VSI rebuild happens AFTER ice_ptp_rebuild()
4. PTP work runs and accesses NULL vsi->rx_rings
Fix: Keep PTP work cancelled during rebuild, only queue it after
VSI rebuild completes in ice_rebuild().
Added ice_ptp_queue_work() helper function to encapsulate the logic
for queuing PTP work, ensuring it's only queued when PTP is supported
and the state is ICE_PTP_READY.
Error log:
[ 121.392544] ice 0000:60:00.1: PTP reset successful
[ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 121.392712] #PF: supervisor read access in kernel mode
[ 121.392720] #PF: error_code(0x0000) - not-present page
[ 121.392727] PGD 0
[ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI
[ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)
[ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC
[ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]
[ 121.393042] Call Trace:
[ 121.393047] <TASK>
[ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice]
[ 121.393202] kthread_worker_fn+0xa2/0x260
[ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]
[ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10
[ 121.393371] kthread+0x10d/0x230
[ 121.393382] ? __pfx_kthread+0x10/0x10
[ 121.393393] ret_from_fork+0x273/0x2b0
[ 121.393407] ? __pfx_kthread+0x10/0x10
[ 121.393417] ret_from_fork_asm+0x1a/0x30
[ 121.393432] </TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: Fix RSS LUT NULL ptr issue after soft reset
During soft reset, the RSS LUT is freed and not restored unless the
interface is up. If an ethtool command that accesses the rss lut is
attempted immediately after reset, it will result in NULL ptr
dereference. Also, there is no need to reset the rss lut if the soft reset
does not involve queue count change.
After soft reset, set the RSS LUT to default values based on the updated
queue count only if the reset was a result of a queue count change and
the LUT was not configured by the user. In all other cases, don't touch
the LUT.
Steps to reproduce:
** Bring the interface down (if up)
ifconfig eth1 down
** update the queue count (eg., 27->20)
ethtool -L eth1 combined 20
** display the RSS LUT
ethtool -x eth1
[82375.558338] BUG: kernel NULL pointer dereference, address: 0000000000000000
[82375.558373] #PF: supervisor read access in kernel mode
[82375.558391] #PF: error_code(0x0000) - not-present page
[82375.558408] PGD 0 P4D 0
[82375.558421] Oops: Oops: 0000 [#1] SMP NOPTI
<snip>
[82375.558516] RIP: 0010:idpf_get_rxfh+0x108/0x150 [idpf]
[82375.558786] Call Trace:
[82375.558793] <TASK>
[82375.558804] rss_prepare.isra.0+0x187/0x2a0
[82375.558827] rss_prepare_data+0x3a/0x50
[82375.558845] ethnl_default_doit+0x13d/0x3e0
[82375.558863] genl_family_rcv_msg_doit+0x11f/0x180
[82375.558886] genl_rcv_msg+0x1ad/0x2b0
[82375.558902] ? __pfx_ethnl_default_doit+0x10/0x10
[82375.558920] ? __pfx_genl_rcv_msg+0x10/0x10
[82375.558937] netlink_rcv_skb+0x58/0x100
[82375.558957] genl_rcv+0x2c/0x50
[82375.558971] netlink_unicast+0x289/0x3e0
[82375.558988] netlink_sendmsg+0x215/0x440
[82375.559005] __sys_sendto+0x234/0x240
[82375.559555] __x64_sys_sendto+0x28/0x30
[82375.560068] x64_sys_call+0x1909/0x1da0
[82375.560576] do_syscall_64+0x7a/0xfa0
[82375.561076] ? clear_bhb_loop+0x60/0xb0
[82375.561567] entry_SYSCALL_64_after_hwframe+0x76/0x7e
<snip> |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: Fix RSS LUT NULL pointer crash on early ethtool operations
The RSS LUT is not initialized until the interface comes up, causing
the following NULL pointer crash when ethtool operations like rxhash on/off
are performed before the interface is brought up for the first time.
Move RSS LUT initialization from ndo_open to vport creation to ensure LUT
is always available. This enables RSS configuration via ethtool before
bringing the interface up. Simplify LUT management by maintaining all
changes in the driver's soft copy and programming zeros to the indirection
table when rxhash is disabled. Defer HW programming until the interface
comes up if it is down during rxhash and LUT configuration changes.
Steps to reproduce:
** Load idpf driver; interfaces will be created
modprobe idpf
** Before bringing the interfaces up, turn rxhash off
ethtool -K eth2 rxhash off
[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000
[89408.371908] #PF: supervisor read access in kernel mode
[89408.371924] #PF: error_code(0x0000) - not-present page
[89408.371940] PGD 0 P4D 0
[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI
<snip>
[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130
[89408.372310] Call Trace:
[89408.372317] <TASK>
[89408.372326] ? idpf_set_features+0xfc/0x180 [idpf]
[89408.372363] __netdev_update_features+0x295/0xde0
[89408.372384] ethnl_set_features+0x15e/0x460
[89408.372406] genl_family_rcv_msg_doit+0x11f/0x180
[89408.372429] genl_rcv_msg+0x1ad/0x2b0
[89408.372446] ? __pfx_ethnl_set_features+0x10/0x10
[89408.372465] ? __pfx_genl_rcv_msg+0x10/0x10
[89408.372482] netlink_rcv_skb+0x58/0x100
[89408.372502] genl_rcv+0x2c/0x50
[89408.372516] netlink_unicast+0x289/0x3e0
[89408.372533] netlink_sendmsg+0x215/0x440
[89408.372551] __sys_sendto+0x234/0x240
[89408.372571] __x64_sys_sendto+0x28/0x30
[89408.372585] x64_sys_call+0x1909/0x1da0
[89408.372604] do_syscall_64+0x7a/0xfa0
[89408.373140] ? clear_bhb_loop+0x60/0xb0
[89408.373647] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[89408.378887] </TASK>
<snip> |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: detach and close netdevs while handling a reset
Protect the reset path from callbacks by setting the netdevs to detached
state and close any netdevs in UP state until the reset handling has
completed. During a reset, the driver will de-allocate resources for the
vport, and there is no guarantee that those will recover, which is why the
existing vport_ctrl_lock does not provide sufficient protection.
idpf_detach_and_close() is called right before reset handling. If the
reset handling succeeds, the netdevs state is recovered via call to
idpf_attach_and_open(). If the reset handling fails the netdevs remain
down. The detach/down calls are protected with RTNL lock to avoid racing
with callbacks. On the recovery side the attach can be done without
holding the RTNL lock as there are no callbacks expected at that point,
due to detach/close always being done first in that flow.
The previous logic restoring the netdevs state based on the
IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence
the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is
still being used to restore the state of the netdevs following the reset,
but has no use outside of the reset handling flow.
idpf_init_hard_reset() is converted to void, since it was used as such and
there is no error handling being done based on its return value.
Before this change, invoking hard and soft resets simultaneously will
cause the driver to lose the vport state:
ip -br a
<inf> UP
echo 1 > /sys/class/net/ens801f0/device/reset& \
ethtool -L ens801f0 combined 8
ip -br a
<inf> DOWN
ip link set <inf> up
ip -br a
<inf> DOWN
Also in case of a failure in the reset path, the netdev is left
exposed to external callbacks, while vport resources are not
initialized, leading to a crash on subsequent ifup/down:
[408471.398966] idpf 0000:83:00.0: HW reset detected
[408471.411744] idpf 0000:83:00.0: Device HW Reset initiated
[408472.277901] idpf 0000:83:00.0: The driver was unable to contact the device's firmware. Check that the FW is running. Driver state= 0x2
[408508.125551] BUG: kernel NULL pointer dereference, address: 0000000000000078
[408508.126112] #PF: supervisor read access in kernel mode
[408508.126687] #PF: error_code(0x0000) - not-present page
[408508.127256] PGD 2aae2f067 P4D 0
[408508.127824] Oops: Oops: 0000 [#1] SMP NOPTI
...
[408508.130871] RIP: 0010:idpf_stop+0x39/0x70 [idpf]
...
[408508.139193] Call Trace:
[408508.139637] <TASK>
[408508.140077] __dev_close_many+0xbb/0x260
[408508.140533] __dev_change_flags+0x1cf/0x280
[408508.140987] netif_change_flags+0x26/0x70
[408508.141434] dev_change_flags+0x3d/0xb0
[408508.141878] devinet_ioctl+0x460/0x890
[408508.142321] inet_ioctl+0x18e/0x1d0
[408508.142762] ? _copy_to_user+0x22/0x70
[408508.143207] sock_do_ioctl+0x3d/0xe0
[408508.143652] sock_ioctl+0x10e/0x330
[408508.144091] ? find_held_lock+0x2b/0x80
[408508.144537] __x64_sys_ioctl+0x96/0xe0
[408508.144979] do_syscall_64+0x79/0x3d0
[408508.145415] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[408508.145860] RIP: 0033:0x7f3e0bb4caff |
| LibJWT is a C JSON Web Token Library. Starting in version 3.0.0 and prior to version 3.3.0, the JWK parsing for RSA-PSS did not protect against a NULL value when expecting to parse JSON string values. A specially crafted JWK file could exploit this behavior by using integers in places where the code expected a string. This was fixed in v3.3.0. A workaround is available. Users importing keys through a JWK file should not do so from untrusted sources. Use the `jwk2key` tool to check for validity of a JWK file. Likewise, if possible, do not use JWK files with RSA-PSS keys. |
| NanoMQ MQTT Broker (NanoMQ) is an all-around Edge Messaging Platform. In NanoMQ version 0.24.6, after enabling auth.http_auth (HTTP authentication), when a client connects to the broker using MQTT CONNECT without providing username/password, and the configuration params uses the placeholders %u / %P (e.g., username="%u", password="%P"), the HTTP request construction phase enters auth_http.c:set_data(). This results in calling strlen() on a NULL pointer, causing a SIGSEGV crash. This crash can be triggered remotely, resulting in a denial of service. This issue has been patched in version 0.24.7. |
| Null pointer dereference in Windows Local Security Authority Subsystem Service (LSASS) allows an unauthorized attacker to deny service over a network. |
| When the ngx_mail_auth_http_module module is enabled on NGINX Plus or NGINX Open Source, undisclosed requests can cause worker processes to terminate. This issue may occur when (1) CRAM-MD5 or APOP authentication is enabled, and (2) the authentication server permits retry by returning the Auth-Wait response header. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| Ella Core is a 5G core designed for private networks. Versions prior to 1.7.0 panic when processing Authentication Response and Authentication Failure NAS message missing IEs. An attacker able to send crafted NAS messages to Ella Core can crash the process, causing service disruption for all connected subscribers. No authentication is required. Version 1.7.0 added IE presence verification to NAS message handling. |
| Ella Core is a 5G core designed for private networks. Versions prior to 1.7.0 panic when processing a specially crafted NGAP LocationReport message. An attacker able to send crafted NGAP messages to Ella Core can crash the process, causing service disruption for all connected subscribers. Version 1.7.0 adds guards in NGAP Location Report handler. |
| Null pointer dereference in Windows Remote Access Connection Manager allows an unauthorized attacker to deny service locally. |
| In the Linux kernel, the following vulnerability has been resolved:
icmp: fix NULL pointer dereference in icmp_tag_validation()
icmp_tag_validation() unconditionally dereferences the result of
rcu_dereference(inet_protos[proto]) without checking for NULL.
The inet_protos[] array is sparse -- only about 15 of 256 protocol
numbers have registered handlers. When ip_no_pmtu_disc is set to 3
(hardened PMTU mode) and the kernel receives an ICMP Fragmentation
Needed error with a quoted inner IP header containing an unregistered
protocol number, the NULL dereference causes a kernel panic in
softirq context.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143)
Call Trace:
<IRQ>
icmp_rcv (net/ipv4/icmp.c:1527)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)
ip_local_deliver_finish (net/ipv4/ip_input.c:242)
ip_local_deliver (net/ipv4/ip_input.c:262)
ip_rcv (net/ipv4/ip_input.c:573)
__netif_receive_skb_one_core (net/core/dev.c:6164)
process_backlog (net/core/dev.c:6628)
handle_softirqs (kernel/softirq.c:561)
</IRQ>
Add a NULL check before accessing icmp_strict_tag_validation. If the
protocol has no registered handler, return false since it cannot
perform strict tag validation. |
