| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A physical attack vulnerability exists in certain Moxa industrial computers using TPM-backed LUKS full-disk encryption on Moxa Industrial Linux 3, where the discrete TPM is connected to the CPU via an SPI bus. Exploitation requires invasive physical access, including opening the device and attaching external equipment to the SPI bus to capture TPM communications. If successful, the captured data may allow offline decryption of eMMC contents. This attack cannot be performed through brief or opportunistic physical access and requires extended physical access, possession of the device, appropriate equipment, and sufficient time for signal capture and analysis. Remote exploitation is not possible. |
| Caido is a web security auditing toolkit. Prior to 0.55.0, Caido blocks non whitelisted domains to reach out through the 8080 port, and shows Host/IP is not allowed to connect to Caido on all endpoints. But this is bypassable by injecting a X-Forwarded-Host: 127.0.0.1:8080 header. This vulnerability is fixed in 0.55.0. |
| The PixelYourSite – Your smart PIXEL (TAG) & API Manager plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'pysTrafficSource' parameter and the 'pys_landing_page' parameter in all versions up to, and including, 11.2.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| A Denial of Service (DoS) vulnerability was discovered in the TON Lite Server before v2024.09. The vulnerability arises from the handling of external arguments passed to locally executed "get methods." An attacker can inject a constructed Continuation object (an internal TVM type) that is normally restricted within the VM. When the TVM executes this malicious continuation, it consumes excessive CPU resources while accruing disproportionately low virtual gas costs. This "free" computation allows an attacker to monopolize the Lite Server's processing power, significantly reducing its throughput and causing a denial of service for legitimate users acting through the gateway. |
| A State Pollution vulnerability was discovered in the TON Virtual Machine (TVM) before v2025.04. The issue exists in the RUNVM instruction logic (VmState::run_child_vm), which is responsible for initializing child virtual machines. The operation moves critical resources (specifically libraries and log) from the parent state to a new child state in a non-atomic manner. If an Out-of-Gas (OOG) exception occurs after resources are moved but before the state transition is finalized, the parent VM retains a corrupted state where these resources are emptied/invalid. Because RUNVM supports gas isolation, the parent VM continues execution with this corrupted state, leading to unexpected behavior or denial of service within the contract's context. |
| The Starfish Review Generation & Marketing for WordPress plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the 'srm_restore_options_defaults' function in all versions up to, and including, 3.1.19. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/nvm: Fix double-free on aux add failure
After a successful auxiliary_device_init(), aux_dev->dev.release
(xe_nvm_release_dev()) is responsible for the kfree(nvm). When
there is failure with auxiliary_device_add(), driver will call
auxiliary_device_uninit(), which call put_device(). So that the
.release callback will be triggered to free the memory associated
with the auxiliary_device.
Move the kfree(nvm) into the auxiliary_device_init() failure path
and remove the err goto path to fix below error.
"
[ 13.232905] ==================================================================
[ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]
[ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273
[ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)
...
[ 13.233125] Call Trace:
[ 13.233126] <TASK>
[ 13.233127] dump_stack_lvl+0x7f/0xc0
[ 13.233132] print_report+0xce/0x610
[ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0
[ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]
...
"
v2: drop err goto path. (Alexander)
(cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215) |
| In the Linux kernel, the following vulnerability has been resolved:
mm/shmem, swap: fix race of truncate and swap entry split
The helper for shmem swap freeing is not handling the order of swap
entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it
gets the entry order before that using xa_get_order without lock
protection, and it may get an outdated order value if the entry is split
or changed in other ways after the xa_get_order and before the
xa_cmpxchg_irq.
And besides, the order could grow and be larger than expected, and cause
truncation to erase data beyond the end border. For example, if the
target entry and following entries are swapped in or freed, then a large
folio was added in place and swapped out, using the same entry, the
xa_cmpxchg_irq will still succeed, it's very unlikely to happen though.
To fix that, open code the Xarray cmpxchg and put the order retrieval and
value checking in the same critical section. Also, ensure the order won't
exceed the end border, skip it if the entry goes across the border.
Skipping large swap entries crosses the end border is safe here. Shmem
truncate iterates the range twice, in the first iteration,
find_lock_entries already filtered such entries, and shmem will swapin the
entries that cross the end border and partially truncate the folio (split
the folio or at least zero part of it). So in the second loop here, if we
see a swap entry that crosses the end order, it must at least have its
content erased already.
I observed random swapoff hangs and kernel panics when stress testing
ZSWAP with shmem. After applying this patch, all problems are gone. |
| In the Linux kernel, the following vulnerability has been resolved:
octeon_ep: Fix memory leak in octep_device_setup()
In octep_device_setup(), if octep_ctrl_net_init() fails, the function
returns directly without unmapping the mapped resources and freeing the
allocated configuration memory.
Fix this by jumping to the unsupported_dev label, which performs the
necessary cleanup. This aligns with the error handling logic of other
paths in this function.
Compile tested only. Issue found using a prototype static analysis tool
and code review. |
| In the Linux kernel, the following vulnerability has been resolved:
perf: sched: Fix perf crash with new is_user_task() helper
In order to do a user space stacktrace the current task needs to be a user
task that has executed in user space. It use to be possible to test if a
task is a user task or not by simply checking the task_struct mm field. If
it was non NULL, it was a user task and if not it was a kernel task.
But things have changed over time, and some kernel tasks now have their
own mm field.
An idea was made to instead test PF_KTHREAD and two functions were used to
wrap this check in case it became more complex to test if a task was a
user task or not[1]. But this was rejected and the C code simply checked
the PF_KTHREAD directly.
It was later found that not all kernel threads set PF_KTHREAD. The io-uring
helpers instead set PF_USER_WORKER and this needed to be added as well.
But checking the flags is still not enough. There's a very small window
when a task exits that it frees its mm field and it is set back to NULL.
If perf were to trigger at this moment, the flags test would say its a
user space task but when perf would read the mm field it would crash with
at NULL pointer dereference.
Now there are flags that can be used to test if a task is exiting, but
they are set in areas that perf may still want to profile the user space
task (to see where it exited). The only real test is to check both the
flags and the mm field.
Instead of making this modification in every location, create a new
is_user_task() helper function that does all the tests needed to know if
it is safe to read the user space memory or not.
[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/ |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not strictly require dirty metadata threshold for metadata writepages
[BUG]
There is an internal report that over 1000 processes are
waiting at the io_schedule_timeout() of balance_dirty_pages(), causing
a system hang and trigger a kernel coredump.
The kernel is v6.4 kernel based, but the root problem still applies to
any upstream kernel before v6.18.
[CAUSE]
From Jan Kara for his wisdom on the dirty page balance behavior first.
This cgroup dirty limit was what was actually playing the role here
because the cgroup had only a small amount of memory and so the dirty
limit for it was something like 16MB.
Dirty throttling is responsible for enforcing that nobody can dirty
(significantly) more dirty memory than there's dirty limit. Thus when
a task is dirtying pages it periodically enters into balance_dirty_pages()
and we let it sleep there to slow down the dirtying.
When the system is over dirty limit already (either globally or within
a cgroup of the running task), we will not let the task exit from
balance_dirty_pages() until the number of dirty pages drops below the
limit.
So in this particular case, as I already mentioned, there was a cgroup
with relatively small amount of memory and as a result with dirty limit
set at 16MB. A task from that cgroup has dirtied about 28MB worth of
pages in btrfs btree inode and these were practically the only dirty
pages in that cgroup.
So that means the only way to reduce the dirty pages of that cgroup is
to writeback the dirty pages of btrfs btree inode, and only after that
those processes can exit balance_dirty_pages().
Now back to the btrfs part, btree_writepages() is responsible for
writing back dirty btree inode pages.
The problem here is, there is a btrfs internal threshold that if the
btree inode's dirty bytes are below the 32M threshold, it will not
do any writeback.
This behavior is to batch as much metadata as possible so we won't write
back those tree blocks and then later re-COW them again for another
modification.
This internal 32MiB is higher than the existing dirty page size (28MiB),
meaning no writeback will happen, causing a deadlock between btrfs and
cgroup:
- Btrfs doesn't want to write back btree inode until more dirty pages
- Cgroup/MM doesn't want more dirty pages for btrfs btree inode
Thus any process touching that btree inode is put into sleep until
the number of dirty pages is reduced.
Thanks Jan Kara a lot for the analysis of the root cause.
[ENHANCEMENT]
Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on the
btree_inode"), btrfs btree inode pages will only be charged to the root
cgroup which should have a much larger limit than btrfs' 32MiB
threshold.
So it should not affect newer kernels.
But for all current LTS kernels, they are all affected by this problem,
and backporting the whole AS_KERNEL_FILE may not be a good idea.
Even for newer kernels I still think it's a good idea to get
rid of the internal threshold at btree_writepages(), since for most cases
cgroup/MM has a better view of full system memory usage than btrfs' fixed
threshold.
For internal callers using btrfs_btree_balance_dirty() since that
function is already doing internal threshold check, we don't need to
bother them.
But for external callers of btree_writepages(), just respect their
requests and write back whatever they want, ignoring the internal
btrfs threshold to avoid such deadlock on btree inode dirty page
balancing. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop
Currently this is checked before running the pending work. Normally this
is quite fine, as work items either end up blocking (which will create a
new worker for other items), or they complete fairly quickly. But syzbot
reports an issue where io-wq takes seemingly forever to exit, and with a
bit of debugging, this turns out to be because it queues a bunch of big
(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't
support ->read_iter(), loop_rw_iter() ends up handling them. Each read
returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of
these pending, processing the whole chain can take a long time. Easily
longer than the syzbot uninterruptible sleep timeout of 140 seconds.
This then triggers a complaint off the io-wq exit path:
INFO: task syz.4.135:6326 blocked for more than 143 seconds.
Not tainted syzkaller #0
Blocked by coredump.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5256 [inline]
__schedule+0x1139/0x6150 kernel/sched/core.c:6863
__schedule_loop kernel/sched/core.c:6945 [inline]
schedule+0xe7/0x3a0 kernel/sched/core.c:6960
schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75
do_wait_for_common kernel/sched/completion.c:100 [inline]
__wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121
io_wq_exit_workers io_uring/io-wq.c:1328 [inline]
io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356
io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203
io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651
io_uring_files_cancel include/linux/io_uring.h:19 [inline]
do_exit+0x2ce/0x2bd0 kernel/exit.c:911
do_group_exit+0xd3/0x2a0 kernel/exit.c:1112
get_signal+0x2671/0x26d0 kernel/signal.c:3034
arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]
do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa02738f749
RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098
RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98
There's really nothing wrong here, outside of processing these reads
will take a LONG time. However, we can speed up the exit by checking the
IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will
exit the ring after queueing up all of these reads. Then once the first
item is processed, io-wq will simply cancel the rest. That should avoid
syzbot running into this complaint again. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().
syzbot reported various memory leaks related to NFC, struct
nfc_llcp_sock, sk_buff, nfc_dev, etc. [0]
The leading log hinted that nfc_llcp_send_ui_frame() failed
to allocate skb due to sock_error(sk) being -ENXIO.
ENXIO is set by nfc_llcp_socket_release() when struct
nfc_llcp_local is destroyed by local_cleanup().
The problem is that there is no synchronisation between
nfc_llcp_send_ui_frame() and local_cleanup(), and skb
could be put into local->tx_queue after it was purged in
local_cleanup():
CPU1 CPU2
---- ----
nfc_llcp_send_ui_frame() local_cleanup()
|- do { '
|- pdu = nfc_alloc_send_skb(..., &err)
| .
| |- nfc_llcp_socket_release(local, false, ENXIO);
| |- skb_queue_purge(&local->tx_queue); |
| ' |
|- skb_queue_tail(&local->tx_queue, pdu); |
... |
|- pdu = nfc_alloc_send_skb(..., &err) |
^._________________________________.'
local_cleanup() is called for struct nfc_llcp_local only
after nfc_llcp_remove_local() unlinks it from llcp_devices.
If we hold local->tx_queue.lock then, we can synchronise
the thread and nfc_llcp_send_ui_frame().
Let's do that and check list_empty(&local->list) before
queuing skb to local->tx_queue in nfc_llcp_send_ui_frame().
[0]:
[ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6)
[ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
BUG: memory leak
unreferenced object 0xffff8881272f6800 (size 1024):
comm "syz.0.17", pid 6096, jiffies 4294942766
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............
backtrace (crc da58d84d):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4979 [inline]
slab_alloc_node mm/slub.c:5284 [inline]
__do_kmalloc_node mm/slub.c:5645 [inline]
__kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658
kmalloc_noprof include/linux/slab.h:961 [inline]
sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239
sk_alloc+0x36/0x360 net/core/sock.c:2295
nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979
llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044
nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31
__sock_create+0x1a9/0x340 net/socket.c:1605
sock_create net/socket.c:1663 [inline]
__sys_socket_create net/socket.c:1700 [inline]
__sys_socket+0xb9/0x1a0 net/socket.c:1747
__do_sys_socket net/socket.c:1761 [inline]
__se_sys_socket net/socket.c:1759 [inline]
__x64_sys_socket+0x1b/0x30 net/socket.c:1759
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
BUG: memory leak
unreferenced object 0xffff88810fbd9800 (size 240):
comm "syz.0.17", pid 6096, jiffies 4294942850
hex dump (first 32 bytes):
68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h.......
00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'....
backtrace (crc 6cc652b1):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4979 [inline]
slab_alloc_node mm/slub.c:5284 [inline]
kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336
__alloc_skb+0x203/0x240 net/core/skbuff.c:660
alloc_skb include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0x69/0x3f0 net/core/sk
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix race condition against transaction list
The list of transaction is enumerated without acquiring card lock when
processing AR response event. This causes a race condition bug when
processing AT request completion event concurrently.
This commit fixes the bug by put timer start for split transaction
expiration into the scope of lock. The value of jiffies in card structure
is referred before acquiring the lock. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: Set __nocfi on swsusp_arch_resume()
A DABT is reported[1] on an android based system when resume from hiberate.
This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*()
and does not have a CFI hash, but swsusp_arch_resume() will attempt to
verify the CFI hash when calling a copy of swsusp_arch_suspend_exit().
Given that there's an existing requirement that the entrypoint to
swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text
section, we cannot fix this by marking swsusp_arch_suspend_exit() with
SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in
swsusp_arch_resume().
Mark swsusp_arch_resume() as __nocfi to disable the CFI check.
[1]
[ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc
[ 22.991934][ T1] Mem abort info:
[ 22.991934][ T1] ESR = 0x0000000096000007
[ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits
[ 22.991934][ T1] SET = 0, FnV = 0
[ 22.991934][ T1] EA = 0, S1PTW = 0
[ 22.991934][ T1] FSC = 0x07: level 3 translation fault
[ 22.991934][ T1] Data abort info:
[ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
[ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper
[ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP
[ 22.991934][ T1] Dumping ftrace buffer:
[ 22.991934][ T1] (ftrace buffer empty)
[ 22.991934][ T1] Modules linked in:
[ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419
[ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT)
[ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344
[ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344
[ 22.991934][ T1] sp : ffffffc08006b960
[ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000
[ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820
[ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000
[ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058
[ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004
[ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000
[ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000
[ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b
[ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530
[ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000
[ 22.991934][ T1] Call trace:
[ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344
[ 22.991934][ T1] hibernation_restore+0x158/0x18c
[ 22.991934][ T1] load_image_and_restore+0xb0/0xec
[ 22.991934][ T1] software_resume+0xf4/0x19c
[ 22.991934][ T1] software_resume_initcall+0x34/0x78
[ 22.991934][ T1] do_one_initcall+0xe8/0x370
[ 22.991934][ T1] do_initcall_level+0xc8/0x19c
[ 22.991934][ T1] do_initcalls+0x70/0xc0
[ 22.991934][ T1] do_basic_setup+0x1c/0x28
[ 22.991934][ T1] kernel_init_freeable+0xe0/0x148
[ 22.991934][ T1] kernel_init+0x20/0x1a8
[ 22.991934][ T1] ret_from_fork+0x10/0x20
[ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)
[catalin.marinas@arm.com: commit log updated by Mark Rutland] |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: TC, delete flows only for existing peers
When deleting TC steering flows, iterate only over actual devcom
peers instead of assuming all possible ports exist. This avoids
touching non-existent peers and ensures cleanup is limited to
devices the driver is currently connected to.
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 133c8a067 P4D 0
Oops: Oops: 0002 [#1] SMP
CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]
Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49
RSP: 0018:ff11000143867528 EFLAGS: 00010246
RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000
RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0
RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002
R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78
R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0
FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0
Call Trace:
<TASK>
mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]
mlx5e_flow_put+0x25/0x50 [mlx5_core]
mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]
tc_setup_cb_reoffload+0x20/0x80
fl_reoffload+0x26f/0x2f0 [cls_flower]
? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]
? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]
tcf_block_playback_offloads+0x9e/0x1c0
tcf_block_unbind+0x7b/0xd0
tcf_block_setup+0x186/0x1d0
tcf_block_offload_cmd.isra.0+0xef/0x130
tcf_block_offload_unbind+0x43/0x70
__tcf_block_put+0x85/0x160
ingress_destroy+0x32/0x110 [sch_ingress]
__qdisc_destroy+0x44/0x100
qdisc_graft+0x22b/0x610
tc_get_qdisc+0x183/0x4d0
rtnetlink_rcv_msg+0x2d7/0x3d0
? rtnl_calcit.isra.0+0x100/0x100
netlink_rcv_skb+0x53/0x100
netlink_unicast+0x249/0x320
? __alloc_skb+0x102/0x1f0
netlink_sendmsg+0x1e3/0x420
__sock_sendmsg+0x38/0x60
____sys_sendmsg+0x1ef/0x230
? copy_msghdr_from_user+0x6c/0xa0
___sys_sendmsg+0x7f/0xc0
? ___sys_recvmsg+0x8a/0xc0
? __sys_sendto+0x119/0x180
__sys_sendmsg+0x61/0xb0
do_syscall_64+0x55/0x640
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f35238bb764
Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55
RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764
RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003
RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20
R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790
R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780 |
| In the Linux kernel, the following vulnerability has been resolved:
ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues
Add NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes
during resume from suspend when rings[q_idx]->q_vector is NULL.
Tested adaptor:
60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02)
Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]
SR-IOV state: both disabled and enabled can reproduce this issue.
kernel version: v6.18
Reproduce steps:
Boot up and execute suspend like systemctl suspend or rtcwake.
Log:
<1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040
<1>[ 231.444052] #PF: supervisor read access in kernel mode
<1>[ 231.444484] #PF: error_code(0x0000) - not-present page
<6>[ 231.444913] PGD 0 P4D 0
<4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI
<4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170
<4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89
<4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202
<4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010
<4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000
<4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000
<4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
<4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000
<4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000
<4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0
<4>[ 231.451629] PKRU: 55555554
<4>[ 231.452076] Call Trace:
<4>[ 231.452549] <TASK>
<4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]
<4>[ 231.453482] ice_resume+0xfd/0x220 [ice]
<4>[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10
<4>[ 231.454425] pci_pm_resume+0x8c/0x140
<4>[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10
<4>[ 231.455347] dpm_run_callback+0x5f/0x160
<4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170
<4>[ 231.456244] device_resume+0x177/0x270
<4>[ 231.456708] dpm_resume+0x209/0x2f0
<4>[ 231.457151] dpm_resume_end+0x15/0x30
<4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0
<4>[ 231.458054] enter_state+0x10e/0x570
Add defensive checks for both the ring pointer and its q_vector
before dereferencing, allowing the system to resume successfully even when
q_vectors are unmapped. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/imx/tve: fix probe device leak
Make sure to drop the reference taken to the DDC device during probe on
probe failure (e.g. probe deferral) and on driver unbind. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early read unlock of page with EOF in middle
The read result collection for buffered reads seems to run ahead of the
completion of subrequests under some circumstances, as can be seen in the
following log snippet:
9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0
...
netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0
...
netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
netfs_folio: i=157f3 ix=00004-00004 read-done
netfs_folio: i=157f3 ix=00004-00004 read-unlock
netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
netfs_folio: i=157f3 ix=00005-00005 read-done
netfs_folio: i=157f3 ix=00005-00005 read-unlock
...
netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
...
netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0
The 'cto=5fb2' indicates the collected file pos we've collected results to
so far - but we still have 0x4e more bytes to go - so we shouldn't have
collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail
happens after we unlock the folio, allowing the application to see the
uncleared tail through mmap.
The problem is that netfs_read_unlock_folios() will unlock a folio in which
the amount of read results collected hits EOF position - but the ZERO
subreq lies beyond that and so happens after.
Fix this by changing the end check to always be the end of the folio and
never the end of the file.
In the future, I should look at clearing to the end of the folio here rather
than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can
run in parallel with an async READ subreq. Further, the ZERO subreq may still
be necessary to, say, handle extents in a ceph file that don't have any
backing store and are thus implicitly all zeros.
This can be reproduced by creating a file, the size of which doesn't align
to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something
like:
xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \
-c "mread -v 0 0x6000" /xfstest.test/x
The last 0x4e bytes should all be 00, but if the tail hasn't been cleared
yet, you may see rubbish there. This can be reproduced with kafs by
modifying the kernel to disable the call to netfs_read_subreq_progress()
and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.
Reproduction can be made easier by inserting an mdelay(100) in
netfs_issue_read() for the ZERO-subreq case.
AFS and CIFS are normally unlikely to show this as they dispatch READ ops
asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is
completely synchronous, so the ZERO-subreq will always happen after. It isn't
seen all the time, though, because the collection may be done in a worker
thread. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT
A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key
initialization fails:
==================================================================
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2
RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]
RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401
Call Trace:
sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189
sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111
sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217
sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787
sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169
sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052
sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88
sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243
sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127
The issue is triggered when sctp_auth_asoc_init_active_key() fails in
sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the
command sequence is currently:
- SCTP_CMD_PEER_INIT
- SCTP_CMD_TIMER_STOP (T1_INIT)
- SCTP_CMD_TIMER_START (T1_COOKIE)
- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)
- SCTP_CMD_ASSOC_SHKEY
- SCTP_CMD_GEN_COOKIE_ECHO
If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while
asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by
SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL
to be queued by sctp_datamsg_from_user().
Since command interpretation stops on failure, no COOKIE_ECHO should been
sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already
been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As
a result, the DATA chunk can be transmitted together with the COOKIE_ECHO
in sctp_outq_flush_data(), leading to the observed issue.
Similar to the other places where it calls sctp_auth_asoc_init_active_key()
right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY
immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting
T1_COOKIE. This ensures that if shared key generation fails, authenticated
DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,
giving the client another chance to process INIT_ACK and retry key setup. |
