| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: tas2781: bound firmware description string parsing
The TAS2781 firmware parser reads several variable-length description
strings with strlen() before checking that the string terminator is
present inside the firmware blob. A malformed firmware image without a
NUL terminator can therefore make the parser walk past the end of the
firmware buffer before the later size checks run.
Add a small bounded string-length helper and use it for all description
fields that are parsed from the firmware buffer. Keep the existing size
checks for the fixed bytes that follow each string. |
| The WP Directory Kit WordPress plugin before 1.5.5 does not perform authorization or nonce checks on one of its authenticated AJAX actions, allowing any authenticated user such as a Subscriber to disclose the site's user list and unpublished listings belonging to other users. |
| The GeoDirectory WordPress plugin before 2.8.169 does not perform any authorization check when returning map marker data for a single requested listing, allowing unauthenticated users to disclose the title and exact geographic coordinates of non-public (pending or draft) listings. |
| The WP Data Access WordPress plugin before 5.5.79 does not validate the column names it accepts on one of its unauthenticated AJAX actions, and the nonce guarding that action does not cover them, allowing unauthenticated attackers to read arbitrary columns of the database table the affected front-end form is bound to, including user password hashes where that table is the users table. |
| The WP MAPS PRO WordPress plugin before 6.1.3 does not perform a capability check in one of its AJAX actions, which is also available to unauthenticated users, and does not properly validate a user-controlled path before using it in a file inclusion, allowing unauthenticated attackers to include and execute arbitrary existing local PHP files on the server. |
| The HT Contact Form WordPress plugin before 2.9.3 does not perform any authorization check on the endpoint that returns a saved form draft, allowing unauthenticated users to read the personal data (name, email, phone, address) stored in form drafts. |
| In the Linux kernel, the following vulnerability has been resolved:
bonding: fix devconf_all NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the devconf_all is
never initialized because inet6_init() exits before addrconf_init() is
called which initializes it. bond_send_validate(), however, will still
call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to
NULL derefence of net->ipv6.devconf_all in ip6_pol_route().
BUG: kernel NULL pointer dereference, address: 000000000000000c
[...]
Workqueue: bond0 bond_arp_monitor [bonding]
RIP: 0010:ip6_pol_route+0x69/0x480
[...]
Call Trace:
<TASK>
? srso_return_thunk+0x5/0x5f
? __pfx_ip6_pol_route_output+0x10/0x10
fib6_rule_lookup+0xfe/0x260
? wakeup_preempt+0x8a/0x90
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? sched_balance_rq+0x369/0x810
ip6_route_output_flags+0xd7/0x170
bond_ns_send_all+0xde/0x280 [bonding]
bond_ab_arp_probe+0x296/0x320 [bonding]
? srso_return_thunk+0x5/0x5f
bond_activebackup_arp_mon+0xb4/0x2c0 [bonding]
process_one_work+0x196/0x370
worker_thread+0x1af/0x320
? srso_return_thunk+0x5/0x5f
? __pfx_worker_thread+0x10/0x10
kthread+0xe3/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x199/0x260
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Fix this by adding ipv6_mod_enabled() condition check in the caller. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: occ: validate poll response sensor blocks
The OCC poll response parser walks a counted list of sensor data blocks.
It used the static backing-array capacity as the parse boundary, but a
transport response makes only data_length bytes current and valid. A
truncated response can therefore make the parser consume a block header or
block extent outside the current response.
Use data_length as the parent boundary, prove the fixed poll header and
each current block header before reading them, and prove the complete block
before advancing. Keep parsed sensor metadata local until the complete
response has passed validation, then publish it. Propagate
malformed-response errors before publishing the OCC as active. |
| In the Linux kernel, the following vulnerability has been resolved:
wan: wanxl: Only reset hardware after BAR mapping
wanxl_pci_init_one() stores the freshly allocated card in driver data
before the PLX BAR is mapped. Several early probe failures then unwind
through wanxl_pci_remove_one(), including failure to allocate the coherent
status area or to restore the DMA mask.
wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and
wanxl_reset() dereferences card->plx. On those early failures card->plx
is still NULL, so the error path can dereference a NULL MMIO pointer.
Only issue the hardware reset once the BAR mapping exists. The remaining
cleanup in wanxl_pci_remove_one() already checks whether later resources
were allocated.
This issue was found by a static analysis checker and confirmed by
manual source review. |
| In the Linux kernel, the following vulnerability has been resolved:
nfp: Check resource mutex allocation
nfp_cpp_resource_find() allocates a CPP mutex handle for the matching
resource-table entry and then reports success. nfp_resource_try_acquire()
immediately passes that handle to nfp_cpp_mutex_trylock().
However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens
for a matching table entry, the resource lookup still returns success and
the following trylock dereferences a NULL mutex pointer while opening the
resource.
nfp_resource_acquire() already treats failure to allocate the table mutex
as -ENOMEM. Do the same for the resource mutex and fail the lookup before
publishing the rest of the resource handle.
This issue was found by a static analysis checker and confirmed by
manual source review. |
| In the Linux kernel, the following vulnerability has been resolved:
net: airoha: Fix DMA direction for NPU mailbox buffer
airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE,
but some callers expect the NPU to write response data back into the
same buffer:
- airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into
the buffer, then the caller reads it via memcpy()
- airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back
npu_stats_addr field in the response
On non-cache-coherent architectures like EN7581 (Cortex-A53 without
hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op
— it does not invalidate the CPU cache. If the NPU-written cache line
is still present in the CPU cache when the caller reads the buffer,
the CPU observes stale data instead of the NPU response.
This is a timing-sensitive bug: small mailbox buffers (~24 bytes)
typically fit in a single cache line and may survive in the cache
until the caller reads them, producing silent data corruption rather
than a crash. The bug is more likely to trigger when the caller reads
the response immediately after dma_unmap_single() without intervening
cache-evicting operations.
Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures
dma_unmap_single() invalidates the CPU cache on non-coherent systems.
The mailbox buffers are small so there is no performance concern. |
| Missing Authentication in Apache Ranger Download APIs on versions <= 2.8.0.
Users are recommended to upgrade to version 2.9.0, which fixes this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf) |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap()
mt76_connac_get_he_phy_cap routine can theoretically return NULL so
check cap pointer before dereferencing it. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: guard link STA in decap offload
mt7925_sta_set_decap_offload() iterates over the vif valid_links mask
when updating decap offload state for an MLO station. The station may not
have a link STA for every valid link of the vif, so mt792x_sta_to_link()
can return NULL for a link that belongs to the vif but not to the station.
The function currently dereferences mlink before checking whether the
link WCID is ready. If mlink is NULL, setting or clearing
MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer.
Skip links without a station link before touching mlink->wcid. |
| In the Linux kernel, the following vulnerability has been resolved:
rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst
is never initialized because inet6_init() exits before addrconf_init()
is called to initialize it. An attempt to bind an RDS socket to
an ipv6 address results in a crash in __ipv6_chk_addr_and_flags()
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0
Call Trace:
<TASK>
ipv6_chk_addr+0x3b/0x50
rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp]
rds_trans_get_preferred+0x15d/0x2d0 [rds]
? trace_hardirqs_on+0x2d/0x110
rds_bind+0x1433/0x1d60 [rds]
? rds_remove_bound+0xd50/0xd50 [rds]
? aa_af_perm+0x250/0x250
? __might_fault+0xde/0x190
? __sys_bind+0x1dc/0x210
__sys_bind+0x1dc/0x210
? __ia32_sys_socketpair+0x100/0x100
? restore_fpregs_from_fpstate+0x53/0x100
__x64_sys_bind+0x73/0xb0
? syscall_enter_from_user_mode+0x1c/0x50
do_syscall_64+0x34/0x80
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
RIP: 0033:0x7f47f8269ea9
</TASK>
The following code reproduces the issue:
struct sockaddr_in6 addr;
s = socket(PF_RDS, SOCK_SEQPACKET, 0);
memset(&addr, 0, sizeof(addr));
inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr);
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(PORT);
bind(s, &addr, sizeof(addr));
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller. |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: serialize udp bearer replicast list updates
tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with
list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs
from the encap receive softirq (via tipc_udp_rcast_disc()) without
rtnl_lock(), so it can race the cleanup delete and corrupt the list:
list_del corruption. prev->next should be ffff8880298d7ab8,
but was ffff88802449ad38. (prev=ffff888027e3ec98)
kernel BUG at lib/list_debug.c:62!
RIP: __list_del_entry_valid_or_report+0x17a/0x200
Workqueue: events cleanup_bearer
Call Trace:
cleanup_bearer (net/tipc/udp_media.c:811)
process_one_work (kernel/workqueue.c:3302)
worker_thread (kernel/workqueue.c:3466)
The bearer can be enabled from an unprivileged user namespace, as the
TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM.
Add a spinlock to struct udp_bearer and take it around the list_add_rcu()
in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so
the two writers can no longer corrupt the list.
Reject a duplicate peer under the same lock before allocating, and remove
tipc_udp_is_known_peer(). The old lockless pre-check in
tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer
could both find it absent and add it twice.
cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the
bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add()
and add a peer after cleanup_bearer() has already emptied the list, leaking
that entry when the bearer is freed. Mark the bearer disabled under
rcast_lock once the list is emptied and refuse further additions. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imagination: fix error checking of pvr_vm_context_lookup()
Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop
using IS_ERR() for checking the return value.
Using IS_ERR() leads to the kernel oops reported below. It can be
reproduced by passing an invalid VM context handle from userspace to the
DRM_IOCTL_PVR_CREATE_CONTEXT ioctl.
[ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148
[ 92.742042] Mem abort info:
[ 92.744890] ESR = 0x0000000096000004
[ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits
[ 92.754020] SET = 0, FnV = 0
[ 92.757154] EA = 0, S1PTW = 0
[ 92.760337] FSC = 0x04: level 0 translation fault
[ 92.765243] Data abort info:
[ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000
[ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000
[ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP
[ 92.803027] Modules linked in: powervr
[ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT
[ 92.861385] Hardware name: Texas Instruments AM68 SK (DT)
[ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr]
[ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr]
[ 92.884595] sp : ffff8000837fbb00
[ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8
[ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400
[ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800
[ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000
[ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
[ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298
[ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100
[ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c
[ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680
[ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[ 92.959088] Call trace:
[ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P)
[ 92.967173] pvr_context_create+0x190/0x410 [powervr]
[ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr]
[ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm]
[ 92.982127] drm_ioctl+0x1f8/0x4dc [drm]
[ 92.986098] __arm64_sys_ioctl+0xac/0x104
[ 92.990102] invoke_syscall+0x54/0x10c
[ 92.993842] el0_svc_common.constprop.0+0x40/0xe0
[ 92.998532] do_el0_svc+0x1c/0x28
[ 93.001835] el0_svc+0x38/0x11c
[ 93.004969] el0t_64_sync_handler+0xa0/0xe4
[ 93.009139] el0t_64_sync+0x198/0x19c
[ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400)
[ 93.018869] ---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO
The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks
up the bo_va for the buffer object in the caller's VM via
amdgpu_vm_bo_find(), but uses the returned pointer without checking it.
amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM,
which is the normal case for a BO that has never been mapped. The result
is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which
expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and
dereferences bo_va, causing a NULL pointer dereference.
This is reachable by any process able to issue the ioctl (render group)
simply by requesting mapping info for an unmapped BO.
Return -ENOENT when no bo_va is found, jumping to out_exec so the
drm_exec context and GEM object reference are released.
(cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9) |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()
In tipc_recvmsg(), the copy length is computed as:
copy = min_t(int, dlen - offset, buflen);
buflen is size_t but min_t(int, ...) casts it to int. When buflen
exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it
wraps negative, wins the comparison, and the negative copy length
propagates to simple_copy_to_iter() where int-to-size_t promotion
makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the
same pattern.
Kernel panic - not syncing: kernel: panic_on_warn set ...
RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521)
Call Trace:
__skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402)
skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534)
tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934)
io_recvmsg+0x47e/0xda0
Fix by changing min_t(int, ...) to min_t(size_t, ...) in both
functions. The result is always <= (dlen - offset), which is bounded
by TIPC maximum message size (0x1ffff bytes), so the implicit
narrowing on assignment to int copy is always safe. |
