| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| JavaScript::Minifier::XS versions before 0.16 for Perl crash with a NULL pointer dereference when the first meaningful token of the input is a slash.
The regexp versus division disambiguator in JsTokenizeString (XS.xs) inspects the previous token's last byte to choose between a regexp literal and a division operator. When a slash is the first meaningful token, with the start of input or only whitespace and comments before it, there is no valid preceding token: the walk back over whitespace and comment nodes runs off the head of the node list to NULL, and the byte lookup reads through a NULL contents pointer at an underflowed length index. The following identifier check dereferences the same NULL pointer.
The crash is reachable through the public minify() API, so input as small as a single slash byte crashes the calling process. A service that minifies untrusted or third-party JavaScript can be crashed by a remote request, causing denial of service. |
| Woodpecker before 3.15.0 registers the /api/orgs/lookup/*org_full_name endpoint without authentication middleware, and the LookupOrg handler unconditionally dereferences the session user (user.ForgeID, via ForgeFromUser) when selecting the forge to query. For an unauthenticated request session.User returns nil, so any unauthenticated HTTP request triggers a NULL pointer dereference in the handler. The panic is recovered by gin recovery middleware and the server continues serving (returning HTTP 500), but each request writes a multi-line panic stack trace to the error log. A low-bandwidth unauthenticated attacker can repeatedly probe the endpoint to flood the logs (about 37 lines per request), inflating disk usage and downstream log-ingestion cost and burying legitimate log events. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix a potential NPD in cleanup_prefix_route()
addrconf_get_prefix_route() can return the fib6_null_entry sentinel
entry which has a NULL fib6_table pointer. Therefore, before setting the
route's expiration time, check that we are not working with this entry,
as otherwise a NPD will be triggered [1].
Note that the other callers of addrconf_get_prefix_route() are not
susceptible to this bug:
1. addrconf_prefix_rcv(): Requests a route with the 'RTF_ADDRCONF |
RTF_PREFIX_RT' flags which are not set on fib6_null_entry.
2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid
possible NULL deref in modify_prefix_route()").
3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for
fib6_null_entry and returns an error.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[...]
Call Trace:
<TASK>
__kasan_check_byte (mm/kasan/common.c:573)
lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1))
_raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1))
cleanup_prefix_route (net/ipv6/addrconf.c:1280)
ipv6_del_addr (net/ipv6/addrconf.c:1342)
inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119)
inet6_rtm_deladdr (net/ipv6/addrconf.c:4812)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6997)
netlink_rcv_skb (net/netlink/af_netlink.c:2555)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1899)
__sock_sendmsg (net/socket.c:802 (discriminator 4))
____sys_sendmsg (net/socket.c:2698)
___sys_sendmsg (net/socket.c:2752)
__sys_sendmsg (net/socket.c:2784)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ps883x: Fix Oops at unbind
When trying to unbind a device in order to bind to it vfio-platform as:
echo bc0000.geniqup > /sys/bus/platform/devices/bc0000.geniqup/driver/unbind
I get the following Oops:
[ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
[ 436.487762] Mem abort info:
[ 436.490716] ESR = 0x0000000096000004
[ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits
[ 436.500071] SET = 0, FnV = 0
[ 436.503250] EA = 0, S1PTW = 0
[ 436.506505] FSC = 0x04: level 0 translation fault
[ 436.511533] Data abort info:
[ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000
[ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000
[ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP
[ 436.550374] Modules linked in:
[ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT
[ 436.564440] Tainted: [W]=WARN
[ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025
[ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 436.581841] pc : ps883x_retimer_remove+0x14/0x94
[ 436.586605] lr : i2c_device_remove+0x28/0x84
[ 436.591017] sp : ffff8000847137c0
That's because the ps883x_retimer_remove() retrieves the driver data
from i2c_get_clientdata() which was never set at probe. So, add
i2c_set_clientdata() at the end of the probe. |
| A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. If a remote attacker gains an administrator account, they can then exploit the vulnerability to launch a denial-of-service (DoS) attack.
We have already fixed the vulnerability in the following versions:
QTS 5.2.9.3492 build 20260507 and later
QuTS hero h5.2.9.3499 build 20260514 and later
QuTS hero h5.3.4.3500 build 20260520 and later
QuTS hero h6.0.0.3459 build 20260409 and later |
| An unauthenticated
NULL pointer dereference vulnerability exists in IEEE8021x_upload.cgi in GeoVision
GV-LPC2011 and GV-LPC2211 V1.12 and earlier. The vulnerability is caused by
improper validation of multipart upload headers when processing
certificate-related upload fields. A remote attacker may exploit this
vulnerability by sending a malformed multipart request, causing the affected
CGI process to crash and resulting in a denial of service. |
| An unauthenticated
NULL pointer dereference vulnerability exists in the HTTP request parsing logic
of multiple CGI components in GeoVision GV-LPC2011 and GV-LPC2211 V1.12 and
earlier. The vulnerability is caused by improper validation of required HTTP
request metadata before it is used by the affected components. A remote attacker
may exploit this vulnerability by sending a specially crafted HTTP request,
causing the affected process to crash and resulting in a denial of service. |
| In the Linux kernel, the following vulnerability has been resolved:
net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
If queue entry list allocation fails in airoha_qdma_init_tx_queue routine,
airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference
accessing the queue entry array. The issue is due to the early ndesc
initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc
initialization at end of airoha_qdma_init_tx routine. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: pinconf-generic: Fully validate 'pinmux' property
The pinconf_generic_parse_dt_pinmux() assumes that the 'pinmux' property
is not empty when present. This might be not true. With that, the allocator
will give a special value in return and not NULL which lead to the crash
when trying to access that (invalid) memory. Fix that by fully validating
'pinmux' value, including its length. |
| In the Linux kernel, the following vulnerability has been resolved:
reset: amlogic: t7: Fix null reset ops
Fix missing reset ops causing kernel null pointer dereference.
This SOC's reset is currently not used yet. |
| Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.26.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the envoy.filters.http.grpc_stats filter crashes (null pointer dereference / segfault) when a Connect protocol request (Content-Type: application/connect+proto or application/connect+json) hits a direct_response route. A single unauthenticated HTTP request crashes the Envoy process. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3. |
| Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.37.0 until 1.37.5 and 1.38.3, when the %REQUESTED_SERVER_NAME(X:Y)% is used in log format and host related options is specified, like HOST_FIRST, SNI_FIRST, it's possible to crash Envoy when the specified host header is missing in the request headers. This vulnerability is fixed in 1.37.5 and 1.38.3. |
| In the Linux kernel, the following vulnerability has been resolved:
iomap: avoid potential null folio->mapping deref during error reporting
When a buffered read fails, iomap_finish_folio_read() reports the error
with fserror_report_io(folio->mapping->host, ...). This is called after
ifs->read_bytes_pending has been decremented by the bytes attempted to
be read.
For a folio split across multiple read completions, the folio is only
guaranteed to stay locked while read_bytes_pending > 0. Once
iomap_finish_folio_read() decrements read_bytes_pending, another
in-flight read can complete and end the read on the folio, which unlocks
it. This allows truncate logic to run and detach the folio (set
folio->mapping to NULL). The error reporting path then can dereference a
NULL folio->mapping. As reported by Sam Sun, this is the race that can
occur:
CPU0: failed completion CPU1: final completion CPU2: truncate
----------------------- ---------------------- --------------
read_bytes_pending -= len
finished = false
/* preempted before
fserror_report_io() */
read_bytes_pending -= len
finished = true
folio_end_read()
truncate clears
folio->mapping
fserror_report_io(
folio->mapping->host, ...)
^ NULL deref
Fix this by reporting the error first before decrementing
ifs->read_bytes_pending. |
| In the Linux kernel, the following vulnerability has been resolved:
batman-adv: dat: handle forward allocation error
batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb
for each DHT candidate, but does not check the return value before passing
it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences
the skb unconditionally, so a failed allocation triggers a NULL pointer
dereference.
Skip forwarding to the current DHT candidate on allocation failure. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths
bpf_selem_unlink_nofail() sets SDATA(selem)->smap to NULL before
removing the selem from the storage hlist. A concurrent RCU reader in
bpf_sk_storage_clone() can observe the selem still on the list with
smap already NULL, causing a NULL pointer dereference.
general protection fault, probably for non-canonical address 0xdffffc000000000a:
KASAN: null-ptr-deref in range [0x0000000000000050-0x0000000000000057]
RIP: 0010:bpf_sk_storage_clone+0x1cd/0xaa0 net/core/bpf_sk_storage.c:174
Call Trace:
<IRQ>
sk_clone+0xfed/0x1980 net/core/sock.c:2591
inet_csk_clone_lock+0x30/0x760 net/ipv4/inet_connection_sock.c:1222
tcp_create_openreq_child+0x35/0x2680 net/ipv4/tcp_minisocks.c:571
tcp_v4_syn_recv_sock+0x123/0xf90 net/ipv4/tcp_ipv4.c:1729
tcp_check_req+0x8e1/0x2580 include/net/tcp.h:855
tcp_v4_rcv+0x1845/0x3b80 net/ipv4/tcp_ipv4.c:2347
Add a NULL check for smap in bpf_sk_storage_clone().
bpf_sk_storage_diag_put_all() has the same issue. Add a NULL check
and pass the validated smap directly to diag_get(), which is refactored
to take smap as a parameter instead of reading it internally.
bpf_sk_storage_diag_put() uses diag->maps[i] which is always valid
under its refcount, so diag->maps[i] is passed directly to diag_get(). |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: eip93 - fix hmac setkey algo selection
eip93_hmac_setkey() allocates a temporary ahash transform for
computing HMAC ipad/opad key material. The allocation uses the
driver-specific cra_driver_name (e.g. "sha256-eip93") but passes
CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.
Since the EIP93 hash algorithms are the only ones registered
under those driver names and they are inherently async, the
lookup is self-contradictory and always fails with -ENOENT.
When called from the AEAD setkey path, this failure leaves the
SA record partially initialized with zeroed digest fields. A
subsequent crypto operation then dereferences a NULL pointer in
the request context, resulting in a kernel panic:
```
pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]
lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]
sp : ffffffc082feb820
x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000
x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980
x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0
x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000
x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009
x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0
Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)
```
The reported symbol eip93_aead_handle_result+0xc8c is a
resolution artifact from static functions being merged under
the nearest exported symbol. Decoding the faulting sequence:
```
910142b6 ADD X22, X21, #0x50
f94012e0 LDR X0, [X23, #0x20]
f9002aa0 STR X0, [X21, #0x50]
f90006d3 STR X19, [X22, #0x8]
f9400740 LDR X0, [X26, #0x8]
```
The faulting LDR at [X26, #0x8] is loading ctx->flags
(offset 8 in eip93_hash_ctx), where ctx has been resolved
to NULL from a partially initialized or unreachable
transform context following the failed setkey.
Fix this by dropping the CRYPTO_ALG_ASYNC mask from the
crypto_alloc_ahash() call. The code already handles async
completion correctly via crypto_wait_req(), so there is no
requirement to restrict the lookup to synchronous algorithms.
Note that hashing a single 64-byte block through the hardware
is likely slower than doing it in software due to the DMA
round-trip overhead, but offloading it may still spare CPU
cycles on the slower embedded cores where this IP is found.
[Detailed investigation report of this bug] |
| Integer overflow in Mojo in Google Chrome prior to 149.0.7827.201 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a malicious file. (Chromium security severity: High) |
| In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Clear rel_deadline when initializing forked entities
A yield-triggered crash can happen when a newly forked sched_entity
enters the fair class with se->rel_deadline unexpectedly set.
The failing sequence is:
1. A task is forked while se->rel_deadline is still set.
2. __sched_fork() initializes vruntime, vlag and other sched_entity
state, but does not clear rel_deadline.
3. On the first enqueue, enqueue_entity() calls place_entity().
4. Because se->rel_deadline is set, place_entity() treats se->deadline
as a relative deadline and converts it to an absolute deadline by
adding the current vruntime.
5. However, the forked entity's deadline is not a valid inherited
relative deadline for this new scheduling instance, so the conversion
produces an abnormally large deadline.
6. If the task later calls sched_yield(), yield_task_fair() advances
se->vruntime to se->deadline.
7. The inflated vruntime is then used by the following enqueue path,
where the vruntime-derived key can overflow when multiplied by the
entity weight.
8. This corrupts cfs_rq->sum_w_vruntime, breaks EEVDF eligibility
calculation, and can eventually make all entities appear ineligible.
pick_next_entity() may then return NULL unexpectedly, leading to a
later NULL dereference.
A captured trace shows the effect clearly. Before yield, the entity's
vruntime was around:
9834017729983308
After yield_task_fair() executed:
se->vruntime = se->deadline
the vruntime jumped to:
19668035460670230
and the deadline was later advanced further to:
19668035463470230
This shows that the deadline had already become abnormally large before
yield_task_fair() copied it into vruntime.
rel_deadline is only meaningful when se->deadline really carries a
relative deadline that still needs to be placed against vruntime. A
freshly forked sched_entity should not inherit or retain this state.
Clear se->rel_deadline in __sched_fork(), together with the other
sched_entity runtime state, so that the first enqueue does not interpret
the new entity's deadline as a stale relative deadline. |
| In the Linux kernel, the following vulnerability has been resolved:
net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
If queue entry or DMA descriptor list allocation fails in
airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a
NULL pointer dereference running netif_napi_del() for RX queue NAPIs
since netif_napi_add() has never been executed to this particular RX NAPI.
The issue is due to the early ndesc initialization in
airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc
value to check if the queue is properly initialized. Fix the issue moving
ndesc initialization at end of airoha_qdma_init_tx routine.
Move page_pool allocation after descriptor list allocation in order to
avoid memory leaks if desc allocation fails. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu: Fix NULL group->domain dereference in pci_dev_reset_iommu_done()
Local sashiko review pointed it out that group->domain could be NULL when
a default domain fails to allocate during the first probe, which can crash
at domain->ops->attach_dev dereference in __iommu_attach_device() invoked
by pci_dev_reset_iommu_done().
pci_dev_reset_iommu_prepare() is fine as an old_domain pointer can be NULL.
Skip the re-attach in pci_dev_reset_iommu_done() to fix the bug. |
