| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
comedi: fix race between polling and detaching
syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed. We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.
Tasks will read-lock `dev->attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev->attach_lock` before checking that all of
the subdevices are safe to be deleted. This includes testing for any
sleepers on the subdevices' wait queues. It remains locked until the
device has been detached. This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.
Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev->attach_lock`
is write-locked, which wasn't the case previously, but that does not
matter.
Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch. |
| In the Linux kernel, the following vulnerability has been resolved:
media: venus: Fix OOB read due to missing payload bound check
Currently, The event_seq_changed() handler processes a variable number
of properties sent by the firmware. The number of properties is indicated
by the firmware and used to iterate over the payload. However, the
payload size is not being validated against the actual message length.
This can lead to out-of-bounds memory access if the firmware provides a
property count that exceeds the data available in the payload. Such a
condition can result in kernel crashes or potential information leaks if
memory beyond the buffer is accessed.
Fix this by properly validating the remaining size of the payload before
each property access and updating bounds accordingly as properties are
parsed.
This ensures that property parsing is safely bounded within the received
message buffer and protects against malformed or malicious firmware
behavior. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: reject duplicate device on updates
A chain/flowtable update with duplicated devices in the same batch is
possible. Unfortunately, netdev event path only removes the first
device that is found, leaving unregistered the hook of the duplicated
device.
Check if a duplicated device exists in the transaction batch, bail out
with EEXIST in such case.
WARNING is hit when unregistering the hook:
[49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150
[49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full)
[...]
[49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150 |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-boundary access in dnode page
As Jiaming Zhang reported:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x17e/0x800 mm/kasan/report.c:480
kasan_report+0x147/0x180 mm/kasan/report.c:593
data_blkaddr fs/f2fs/f2fs.h:3053 [inline]
f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline]
f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855
f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195
prepare_write_begin fs/f2fs/data.c:3395 [inline]
f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594
generic_perform_write+0x2c7/0x910 mm/filemap.c:4112
f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline]
f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x546/0xa90 fs/read_write.c:686
ksys_write+0x149/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The root cause is in the corrupted image, there is a dnode has the same
node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to
access block address in dnode at offset 934, however it parses the dnode
as inode node, so that get_dnode_addr() returns 360, then it tries to
access page address from 360 + 934 * 4 = 4096 w/ 4 bytes.
To fix this issue, let's add sanity check for node id of all direct nodes
during f2fs_get_dnode_of_data(). |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: initialize state_ptrs earlier in xfrm_state_find
In case of preemption, xfrm_state_look_at will find a different
pcpu_id and look up states for that other CPU. If we matched a state
for CPU2 in the state_cache while the lookup started on CPU1, we will
jump to "found", but the "best" state that we got will be ignored and
we will enter the "acquire" block. This block uses state_ptrs, which
isn't initialized at this point.
Let's initialize state_ptrs just after taking rcu_read_lock. This will
also prevent a possible misuse in the future, if someone adjusts this
function. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()
`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change
to different stacks along with the Shadow Call Stack if it is enabled.
Those two stack changes cannot be done atomically and both functions
can be interrupted by SErrors or Debug Exceptions which, though unlikely,
is very much broken : if interrupted, we can end up with mismatched stacks
and Shadow Call Stack leading to clobbered stacks.
In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,
but x18 stills points to the old task's SCS. When the interrupt handler
tries to save the task's SCS pointer, it will save the old task
SCS pointer (x18) into the new task struct (pointed to by SP_EL0),
clobbering it.
In `call_on_irq_stack()`, it can happen when switching from the task stack
to the IRQ stack and when switching back. In both cases, we can be
interrupted when the SCS pointer points to the IRQ SCS, but SP points to
the task stack. The nested interrupt handler pushes its return addresses
on the IRQ SCS. It then detects that SP points to the task stack,
calls `call_on_irq_stack()` and clobbers the task SCS pointer with
the IRQ SCS pointer, which it will also use !
This leads to tasks returning to addresses on the wrong SCS,
or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK
or FPAC if enabled.
This is possible on a default config, but unlikely.
However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and
instead the GIC is responsible for filtering what interrupts the CPU
should receive based on priority.
Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU
even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*
frequently depending on the system configuration and workload, leading
to unpredictable kernel panics.
Completely mask DAIF in `cpu_switch_to()` and restore it when returning.
Do the same in `call_on_irq_stack()`, but restore and mask around
the branch.
Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency
of behaviour between all configurations.
Introduce and use an assembly macro for saving and masking DAIF,
as the existing one saves but only masks IF. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv
Given mt8365_dai_set_priv allocate priv_size space to copy priv_data which
means we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv"
instead of afe_priv which has the size of "struct mt8365_afe_private".
Otherwise the KASAN complains about.
[ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]
...
[ 59.394789] Call trace:
[ 59.395167] dump_backtrace+0xa0/0x128
[ 59.395733] show_stack+0x20/0x38
[ 59.396238] dump_stack_lvl+0xe8/0x148
[ 59.396806] print_report+0x37c/0x5e0
[ 59.397358] kasan_report+0xac/0xf8
[ 59.397885] kasan_check_range+0xe8/0x190
[ 59.398485] asan_memcpy+0x3c/0x98
[ 59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]
[ 59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm]
[ 59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm]
[ 59.401873] platform_probe+0xcc/0x228
[ 59.402442] really_probe+0x340/0x9e8
[ 59.402992] driver_probe_device+0x16c/0x3f8
[ 59.403638] driver_probe_device+0x64/0x1d8
[ 59.404256] driver_attach+0x1dc/0x4c8
[ 59.404840] bus_for_each_dev+0x100/0x190
[ 59.405442] driver_attach+0x44/0x68
[ 59.405980] bus_add_driver+0x23c/0x500
[ 59.406550] driver_register+0xf8/0x3d0
[ 59.407122] platform_driver_register+0x68/0x98
[ 59.407810] mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm] |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: alienware-wmi-wmax: Fix `dmi_system_id` array
Add missing empty member to `awcc_dmi_table`. |
| In the Linux kernel, the following vulnerability has been resolved:
[ceph] parse_longname(): strrchr() expects NUL-terminated string
... and parse_longname() is not guaranteed that. That's the reason
why it uses kmemdup_nul() to build the argument for kstrtou64();
the problem is, kstrtou64() is not the only thing that need it.
Just get a NUL-terminated copy of the entire thing and be done
with that... |
| In the Linux kernel, the following vulnerability has been resolved:
gfs2: No more self recovery
When a node withdraws and it turns out that it is the only node that has
the filesystem mounted, gfs2 currently tries to replay the local journal
to bring the filesystem back into a consistent state. Not only is that
a very bad idea, it has also never worked because gfs2_recover_func()
will refuse to do anything during a withdraw.
However, before even getting to this point, gfs2_recover_func()
dereferences sdp->sd_jdesc->jd_inode. This was a use-after-free before
commit 04133b607a78 ("gfs2: Prevent double iput for journal on error")
and is a NULL pointer dereference since then.
Simply get rid of self recovery to fix that. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails
Have nvmet_req_init() and req->execute() complete failed commands.
Description of the problem:
nvmet_req_init() calls __nvmet_req_complete() internally upon failure,
e.g., unsupported opcode, which calls the "queue_response" callback,
this results in nvmet_pci_epf_queue_response() being called, which will
call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is
different from DMA_TO_DEVICE. This results in a double completion as
nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()
when nvmet_req_init() fails.
Steps to reproduce:
On the host send a command with an unsupported opcode with nvme-cli,
For example the admin command "security receive"
$ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096
This triggers a double completion as nvmet_req_init() fails and
nvmet_pci_epf_queue_response() is called, here iod->dma_dir is still
in the default state of "DMA_NONE" as set by default in
nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.
Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also
called in nvmet_pci_epf_exec_iod_work() leading to a double completion.
This not only sends two completions to the host but also corrupts the
state of the PCI NVMe target leading to kernel oops.
This patch lets nvmet_req_init() and req->execute() complete all failed
commands, and removes the double completion case in
nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where
double completions occurred. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: mcc: prevent shift wrapping in rtw89_core_mlsr_switch()
The "link_id" value comes from the user via debugfs. If it's larger
than BITS_PER_LONG then that would result in shift wrapping and
potentially an out of bounds access later. In fact, we can limit it
to IEEE80211_MLD_MAX_NUM_LINKS (15).
Fortunately, only root can write to debugfs files so the security
impact is minimal. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-boundary access in devs.path
- touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123
- truncate -s $((1024*1024*1024)) \
/mnt/f2fs/012345678901234567890123456789012345678901234567890123
- touch /mnt/f2fs/file
- truncate -s $((1024*1024*1024)) /mnt/f2fs/file
- mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \
-c /mnt/f2fs/file
- mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \
/mnt/f2fs/loop
[16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff
[16937.192268] F2FS-fs (loop0): Failed to find devices
If device path length equals to MAX_PATH_LEN, sbi->devs.path[] may
not end up w/ null character due to path array is fully filled, So
accidently, fields locate after path[] may be treated as part of
device path, result in parsing wrong device path.
struct f2fs_dev_info {
...
char path[MAX_PATH_LEN];
...
};
Let's add one byte space for sbi->devs.path[] to store null
character of device path string. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()
Callers of wdev_chandef() must hold the wiphy mutex.
But the worker cfg80211_propagate_cac_done_wk() never takes the lock.
Which triggers the warning below with the mesh_peer_connected_dfs
test from hostapd and not (yet) released mac80211 code changes:
WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165
Modules linked in:
CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf
Workqueue: cfg80211 cfg80211_propagate_cac_done_wk
Stack:
00000000 00000001 ffffff00 6093267c
00000000 6002ec30 6d577c50 60037608
00000000 67e8d108 6063717b 00000000
Call Trace:
[<6002ec30>] ? _printk+0x0/0x98
[<6003c2b3>] show_stack+0x10e/0x11a
[<6002ec30>] ? _printk+0x0/0x98
[<60037608>] dump_stack_lvl+0x71/0xb8
[<6063717b>] ? wdev_chandef+0x60/0x165
[<6003766d>] dump_stack+0x1e/0x20
[<6005d1b7>] __warn+0x101/0x20f
[<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d
[<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec
[<60751191>] ? __this_cpu_preempt_check+0x0/0x16
[<600b11a2>] ? mark_held_locks+0x5a/0x6e
[<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d
[<60052e53>] ? unblock_signals+0x3a/0xe7
[<60052f2d>] ? um_set_signals+0x2d/0x43
[<60751191>] ? __this_cpu_preempt_check+0x0/0x16
[<607508b2>] ? lock_is_held_type+0x207/0x21f
[<6063717b>] wdev_chandef+0x60/0x165
[<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f
[<60052f00>] ? um_set_signals+0x0/0x43
[<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a
[<6007e460>] process_scheduled_works+0x3bc/0x60e
[<6007d0ec>] ? move_linked_works+0x4d/0x81
[<6007d120>] ? assign_work+0x0/0xaa
[<6007f81f>] worker_thread+0x220/0x2dc
[<600786ef>] ? set_pf_worker+0x0/0x57
[<60087c96>] ? to_kthread+0x0/0x43
[<6008ab3c>] kthread+0x2d3/0x2e2
[<6007f5ff>] ? worker_thread+0x0/0x2dc
[<6006c05b>] ? calculate_sigpending+0x0/0x56
[<6003b37d>] new_thread_handler+0x4a/0x64
irq event stamp: 614611
hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf
hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf
softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985
softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable migration in nf_hook_run_bpf().
syzbot reported that the netfilter bpf prog can be called without
migration disabled in xmit path.
Then the assertion in __bpf_prog_run() fails, triggering the splat
below. [0]
Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().
[0]:
BUG: assuming non migratable context at ./include/linux/filter.h:703
in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session
3 locks held by sshd-session/5829:
#0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]
#0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395
#1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470
#2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]
#2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]
#2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241
CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
__cant_migrate kernel/sched/core.c:8860 [inline]
__cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834
__bpf_prog_run include/linux/filter.h:703 [inline]
bpf_prog_run include/linux/filter.h:725 [inline]
nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20
nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]
nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623
nf_hook+0x370/0x680 include/linux/netfilter.h:272
NF_HOOK_COND include/linux/netfilter.h:305 [inline]
ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433
dst_output include/net/dst.h:459 [inline]
ip_local_out net/ipv4/ip_output.c:129 [inline]
__ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527
__tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479
tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]
tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838
__tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021
tcp_push+0x225/0x700 net/ipv4/tcp.c:759
tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359
tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396
inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg net/socket.c:727 [inline]
sock_write_iter+0x4aa/0x5b0 net/socket.c:1131
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x6c7/0x1150 fs/read_write.c:686
ksys_write+0x1f8/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe7d365d407
Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
RSP: |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_nfacct: don't assume acct name is null-terminated
BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721
Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851
[..]
string+0x231/0x2b0 lib/vsprintf.c:721
vsnprintf+0x739/0xf00 lib/vsprintf.c:2874
[..]
nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41
xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523
nfnl_acct_find_get() handles non-null input, but the error
printk relied on its presence. |
| In the Linux kernel, the following vulnerability has been resolved:
media: ti: j721e-csi2rx: fix list_del corruption
If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is
marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.
This causes the same buffer to be retried in the next iteration, resulting
in a double list_del() and eventual list corruption.
Fix this by removing the buffer from the queue before calling
vb2_buffer_done() on error.
This resolves a crash due to list_del corruption:
[ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA
[ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048
[ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)
[ 37.850799] ------------[ cut here ]------------
[ 37.855424] kernel BUG at lib/list_debug.c:65!
[ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul
[ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY
[ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)
[ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114
[ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114
[ 37.914059] sp : ffff800080003db0
[ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000
[ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122
[ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0
[ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a
[ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720
[ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea
[ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568
[ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff
[ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000
[ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d
[ 37.988832] Call trace:
[ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)
[ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4
[ 38.001419] udma_vchan_complete+0x1e0/0x344
[ 38.005705] tasklet_action_common+0x118/0x310
[ 38.010163] tasklet_action+0x30/0x3c
[ 38.013832] handle_softirqs+0x10c/0x2e0
[ 38.017761] __do_softirq+0x14/0x20
[ 38.021256] ____do_softirq+0x10/0x20
[ 38.024931] call_on_irq_stack+0x24/0x60
[ 38.028873] do_softirq_own_stack+0x1c/0x40
[ 38.033064] __irq_exit_rcu+0x130/0x15c
[ 38.036909] irq_exit_rcu+0x10/0x20
[ 38.040403] el1_interrupt+0x38/0x60
[ 38.043987] el1h_64_irq_handler+0x18/0x24
[ 38.048091] el1h_64_irq+0x6c/0x70
[ 38.051501] default_idle_call+0x34/0xe0 (P)
[ 38.055783] do_idle+0x1f8/0x250
[ 38.059021] cpu_startup_entry+0x34/0x3c
[ 38.062951] rest_init+0xb4/0xc0
[ 38.066186] console_on_rootfs+0x0/0x6c
[ 38.070031] __primary_switched+0x88/0x90
[ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)
[ 38.080168] ---[ end trace 0000000000000000 ]---
[ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt
[ 38.092197] SMP: stopping secondary CPUs
[ 38.096139] Kernel Offset: disabled
[ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b
[ 38.105202] Memory Limit: none
[ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can
run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7
("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a
po->bind_lock critical section had to be temporarily released. And
the fix was similarly to temporarily set po->num to zero to keep
the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the
introduction of git history. |
| In the Linux kernel, the following vulnerability has been resolved:
tls: handle data disappearing from under the TLS ULP
TLS expects that it owns the receive queue of the TCP socket.
This cannot be guaranteed in case the reader of the TCP socket
entered before the TLS ULP was installed, or uses some non-standard
read API (eg. zerocopy ones). Replace the WARN_ON() and a buggy
early exit (which leaves anchor pointing to a freed skb) with real
error handling. Wipe the parsing state and tell the reader to retry.
We already reload the anchor every time we (re)acquire the socket lock,
so the only condition we need to avoid is an out of bounds read
(not having enough bytes in the socket for previously parsed record len).
If some data was read from under TLS but there's enough in the queue
we'll reload and decrypt what is most likely not a valid TLS record.
Leading to some undefined behavior from TLS perspective (corrupting
a stream? missing an alert? missing an attack?) but no kernel crash
should take place. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: cancle set bad inode after removing name fails
The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.
When renaming, the file0's inode is marked as a bad inode because the file
name cannot be deleted.
The underlying bug is that make_bad_inode() is called on a live inode.
In some cases it's "icache lookup finds a normal inode, d_splice_alias()
is called to attach it to dentry, while another thread decides to call
make_bad_inode() on it - that would evict it from icache, but we'd already
found it there earlier".
In some it's outright "we have an inode attached to dentry - that's how we
got it in the first place; let's call make_bad_inode() on it just for shits
and giggles". |
