| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: mte: Do not warn if the page is already tagged in copy_highpage()
The arm64 copy_highpage() assumes that the destination page is newly
allocated and not MTE-tagged (PG_mte_tagged unset) and warns
accordingly. However, following commit 060913999d7a ("mm: migrate:
support poisoned recover from migrate folio"), folio_mc_copy() is called
before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the
copy will be done again to the same destination page. Since
copy_highpage() already set the PG_mte_tagged flag, this second copy
will warn.
Replace the WARN_ON_ONCE(page already tagged) in the arm64
copy_highpage() with a comment. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix obj leak in VM_BIND error path
If we fail a handle-lookup part way thru, we need to drop the already
obtained obj references.
Patchwork: https://patchwork.freedesktop.org/patch/669784/ |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] =====================================================
[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220
[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220
[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0
[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310
[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810
[ 70.685447][ T9333] do_rmdir+0x964/0xea0
[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0
[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0
[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.687646][ T9333]
[ 70.687856][ T9333] Uninit was stored to memory at:
[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0
[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800
[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600
[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70
[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0
[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30
[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0
[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0
[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.692773][ T9333]
[ 70.692990][ T9333] Uninit was stored to memory at:
[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0
[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800
[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700
[ 70.694911][ T9333] mount_bdev+0x37b/0x530
[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60
[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0
[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0
[ 70.696588][ T9333] do_new_mount+0x73e/0x1630
[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0
[ 70.697425][ T9333] __se_sys_mount+0x733/0x830
[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150
[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0
[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.699730][ T9333]
[ 70.699946][ T9333] Uninit was created at:
[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60
[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0
[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0
[ 70.701774][ T9333] allocate_slab+0x30e/0x1390
[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0
[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20
[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0
[ 70.703598][ T9333] alloc_inode+0x82/0x490
[ 70.703984][ T9333] iget_locked+0x22e/0x1320
[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0
[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0
[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700
[ 70.705776][ T9333] mount_bdev+0x37b/0x530
[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60
[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0
[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0
[ 70.707444][ T9333] do_new_mount+0x73e/0x1630
[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0
[ 70.708270][ T9333] __se_sys_mount+0x733/0x830
[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150
[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0
[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.710611][ T9333]
[ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17
[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.712490][ T9333] =====================================================
[ 70.713085][ T9333] Disabling lock debugging due to kernel taint
[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...
[ 70.714159][ T9333]
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
slab: Avoid race on slab->obj_exts in alloc_slab_obj_exts
If two competing threads enter alloc_slab_obj_exts() and one of them
fails to allocate the object extension vector, it might override the
valid slab->obj_exts allocated by the other thread with
OBJEXTS_ALLOC_FAIL. This will cause the thread that lost this race and
expects a valid pointer to dereference a NULL pointer later on.
Update slab->obj_exts atomically using cmpxchg() to avoid
slab->obj_exts overrides by racing threads.
Thanks for Vlastimil and Suren's help with debugging. |
| In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: Don't block input queue by waiting MSC
Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.
Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: use dst_dev_net_rcu()
Replace three dst_dev() with a lockdep enabled helper. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix crypto buffers in non-linear memory
The crypto API, through the scatterlist API, expects input buffers to be
in linear memory. We handle this with the cifs_sg_set_buf() helper
that converts vmalloc'd memory to their corresponding pages.
However, when we allocate our aead_request buffer (@creq in
smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly
puts aead_request->__ctx in vmalloc area.
AEAD algorithm then uses ->__ctx for its private/internal data and
operations, and uses sg_set_buf() for such data on a few places.
This works fine as long as @creq falls into kmalloc zone (small
requests) or vmalloc'd memory is still within linear range.
Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too
many tasks will increment the base stacks' addresses to a point where
virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that
happens.
In practice: too many parallel reads and writes on an encrypted mount
will trigger this bug.
To fix this, always alloc @creq with kmalloc() instead.
Also drop the @sensitive_size variable/arguments since
kfree_sensitive() doesn't need it.
Backtrace:
[ 945.272081] ------------[ cut here ]------------
[ 945.272774] kernel BUG at include/linux/scatterlist.h:209!
[ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)
[ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)
[ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220
[ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b
[ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246
[ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030
[ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070
[ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000
[ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070
[ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010
[ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000
[ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0
[ 945.286683] Call Trace:
[ 945.286952] <TASK>
[ 945.287184] ? crypt_message+0x33f/0xad0 [cifs]
[ 945.287719] crypto_gcm_encrypt+0x36/0xe0
[ 945.288152] crypt_message+0x54a/0xad0 [cifs]
[ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs]
[ 945.289300] smb_send_rqst+0xa3/0x160 [cifs]
[ 945.289944] cifs_call_async+0x178/0x340 [cifs]
[ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs]
[ 945.291759] ? find_held_lock+0x32/0x90
[ 945.292212] ? netfs_advance_write+0xf2/0x310
[ 945.292723] netfs_advance_write+0xf2/0x310
[ 945.293210] netfs_write_folio+0x346/0xcc0
[ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10
[ 945.294250] netfs_writepages+0x117/0x460
[ 945.294724] do_writepages+0xbe/0x170
[ 945.295152] ? find_held_lock+0x32/0x90
[ 945.295600] ? kvm_sched_clock_read+0x11/0x20
[ 945.296103] __writeback_single_inode+0x56/0x4b0
[ 945.296643] writeback_sb_inodes+0x229/0x550
[ 945.297140] __writeback_inodes_wb+0x4c/0xe0
[ 945.297642] wb_writeback+0x2f1/0x3f0
[ 945.298069] wb_workfn+0x300/0x490
[ 945.298472] process_one_work+0x1fe/0x590
[ 945.298949] worker_thread+0x1ce/0x3c0
[ 945.299397] ? __pfx_worker_thread+0x10/0x10
[ 945.299900] kthr
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Explicitly check accesses to bpf_sock_addr
Syzkaller found a kernel warning on the following sock_addr program:
0: r0 = 0
1: r2 = *(u32 *)(r1 +60)
2: exit
which triggers:
verifier bug: error during ctx access conversion (0)
This is happening because offset 60 in bpf_sock_addr corresponds to an
implicit padding of 4 bytes, right after msg_src_ip4. Access to this
padding isn't rejected in sock_addr_is_valid_access and it thus later
fails to convert the access.
This patch fixes it by explicitly checking the various fields of
bpf_sock_addr in sock_addr_is_valid_access.
I checked the other ctx structures and is_valid_access functions and
didn't find any other similar cases. Other cases of (properly handled)
padding are covered in new tests in a subsequent patch. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv, bpf: Sign extend struct ops return values properly
The ns_bpf_qdisc selftest triggers a kernel panic:
Unable to handle kernel paging request at virtual address ffffffffa38dbf58
Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000
[ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000
Oops [#1]
Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)]
CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE
Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024
epc : __qdisc_run+0x82/0x6f0
ra : __qdisc_run+0x6e/0x6f0
epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550
gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180
t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0
s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001
a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000
a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049
s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000
s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0
s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000
s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000
t5 : 0000000000000000 t6 : ff60000093a6a8b6
status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d
[<ffffffff80bd5c7a>] __qdisc_run+0x82/0x6f0
[<ffffffff80b6fe58>] __dev_queue_xmit+0x4c0/0x1128
[<ffffffff80b80ae0>] neigh_resolve_output+0xd0/0x170
[<ffffffff80d2daf6>] ip6_finish_output2+0x226/0x6c8
[<ffffffff80d31254>] ip6_finish_output+0x10c/0x2a0
[<ffffffff80d31446>] ip6_output+0x5e/0x178
[<ffffffff80d2e232>] ip6_xmit+0x29a/0x608
[<ffffffff80d6f4c6>] inet6_csk_xmit+0xe6/0x140
[<ffffffff80c985e4>] __tcp_transmit_skb+0x45c/0xaa8
[<ffffffff80c995fe>] tcp_connect+0x9ce/0xd10
[<ffffffff80d66524>] tcp_v6_connect+0x4ac/0x5e8
[<ffffffff80cc19b8>] __inet_stream_connect+0xd8/0x318
[<ffffffff80cc1c36>] inet_stream_connect+0x3e/0x68
[<ffffffff80b42b20>] __sys_connect_file+0x50/0x88
[<ffffffff80b42bee>] __sys_connect+0x96/0xc8
[<ffffffff80b42c40>] __riscv_sys_connect+0x20/0x30
[<ffffffff80e5bcae>] do_trap_ecall_u+0x256/0x378
[<ffffffff80e69af2>] handle_exception+0x14a/0x156
Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709
---[ end trace 0000000000000000 ]---
The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer
is treated as a 32bit value and sign extend to 64bit in epilogue. This
behavior is right for most bpf prog types but wrong for struct ops which
requires RISC-V ABI.
So let's sign extend struct ops return values according to the function
model and RISC-V ABI([0]).
[0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf |
| In the Linux kernel, the following vulnerability has been resolved:
perf: arm_spe: Prevent overflow in PERF_IDX2OFF()
Cast nr_pages to unsigned long to avoid overflow when handling large
AUX buffer sizes (>= 2 GiB). |
| In the Linux kernel, the following vulnerability has been resolved:
NFSD: free copynotify stateid in nfs4_free_ol_stateid()
Typically copynotify stateid is freed either when parent's stateid
is being close/freed or in nfsd4_laundromat if the stateid hasn't
been used in a lease period.
However, in case when the server got an OPEN (which created
a parent stateid), followed by a COPY_NOTIFY using that stateid,
followed by a client reboot. New client instance while doing
CREATE_SESSION would force expire previous state of this client.
It leads to the open state being freed thru release_openowner->
nfs4_free_ol_stateid() and it finds that it still has copynotify
stateid associated with it. We currently print a warning and is
triggerred
WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]
This patch, instead, frees the associated copynotify stateid here.
If the parent stateid is freed (without freeing the copynotify
stateids associated with it), it leads to the list corruption
when laundromat ends up freeing the copynotify state later.
[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink
[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)
[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN
[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024
[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]
[ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200
[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200
[ 1626.861182] sp : ffff8000881d7a40
[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200
[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20
[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8
[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000
[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065
[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3
[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000
[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001
[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000
[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d
[ 1626.868167] Call trace:
[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)
[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd]
[ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd]
[ 1626.869813] laundromat_main+0x24/0x60 [nfsd]
[ 1626.870231] process_one_work+0x584/0x1050
[ 1626.870595] worker_thread+0x4c4/0xc60
[ 1626.870893] kthread+0x2f8/0x398
[ 1626.871146] ret_from_fork+0x10/0x20
[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)
[ 1626.871892] SMP: stopping secondary CPUs |
| In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()
which causes the code to proceed with NULL clock pointers. The current
logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both
valid pointers and NULL, leading to potential NULL pointer dereference
in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:
"The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL
pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)
when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be
called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid
pointers, preventing potential NULL pointer dereference in clk_get_rate(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work
The origin code calls cancel_delayed_work() in ocelot_stats_deinit()
to cancel the cyclic delayed work item ocelot->stats_work. However,
cancel_delayed_work() may fail to cancel the work item if it is already
executing. While destroy_workqueue() does wait for all pending work items
in the work queue to complete before destroying the work queue, it cannot
prevent the delayed work item from being rescheduled within the
ocelot_check_stats_work() function. This limitation exists because the
delayed work item is only enqueued into the work queue after its timer
expires. Before the timer expiration, destroy_workqueue() has no visibility
of this pending work item. Once the work queue appears empty,
destroy_workqueue() proceeds with destruction. When the timer eventually
expires, the delayed work item gets queued again, leading to the following
warning:
workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats
WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0
...
RIP: 0010:__queue_work+0x875/0xaf0
...
RSP: 0018:ffff88806d108b10 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027
RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88
RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2
R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000
R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0
FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0
Call Trace:
<IRQ>
? kasan_report+0xc6/0xf0
? __pfx_delayed_work_timer_fn+0x10/0x10
? __pfx_delayed_work_timer_fn+0x10/0x10
call_timer_fn+0x25/0x1c0
__run_timer_base.part.0+0x3be/0x8c0
? __pfx_delayed_work_timer_fn+0x10/0x10
? rcu_sched_clock_irq+0xb06/0x27d0
? __pfx___run_timer_base.part.0+0x10/0x10
? try_to_wake_up+0xb15/0x1960
? _raw_spin_lock_irq+0x80/0xe0
? __pfx__raw_spin_lock_irq+0x10/0x10
tmigr_handle_remote_up+0x603/0x7e0
? __pfx_tmigr_handle_remote_up+0x10/0x10
? sched_balance_trigger+0x1c0/0x9f0
? sched_tick+0x221/0x5a0
? _raw_spin_lock_irq+0x80/0xe0
? __pfx__raw_spin_lock_irq+0x10/0x10
? tick_nohz_handler+0x339/0x440
? __pfx_tmigr_handle_remote_up+0x10/0x10
__walk_groups.isra.0+0x42/0x150
tmigr_handle_remote+0x1f4/0x2e0
? __pfx_tmigr_handle_remote+0x10/0x10
? ktime_get+0x60/0x140
? lapic_next_event+0x11/0x20
? clockevents_program_event+0x1d4/0x2a0
? hrtimer_interrupt+0x322/0x780
handle_softirqs+0x16a/0x550
irq_exit_rcu+0xaf/0xe0
sysvec_apic_timer_interrupt+0x70/0x80
</IRQ>
...
The following diagram reveals the cause of the above warning:
CPU 0 (remove) | CPU 1 (delayed work callback)
mscc_ocelot_remove() |
ocelot_deinit() | ocelot_check_stats_work()
ocelot_stats_deinit() |
cancel_delayed_work()| ...
| queue_delayed_work()
destroy_workqueue() | (wait a time)
| __queue_work() //UAF
The above scenario actually constitutes a UAF vulnerability.
The ocelot_stats_deinit() is only invoked when initialization
failure or resource destruction, so we must ensure that any
delayed work items cannot be rescheduled.
Replace cancel_delayed_work() with disable_delayed_work_sync()
to guarantee proper cancellation of the delayed work item and
ensure completion of any currently executing work before the
workqueue is deallocated.
A deadlock concern was considered: ocelot_stats_deinit() is called
in a process context and is not holding any locks that the delayed
work item might also need. Therefore, the use of the _sync() variant
is safe here.
This bug was identified through static analysis. To reproduce the
issue and validate the fix, I simulated ocelot-swit
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Fix kernel panic on partial unmap of a GPU VA region
This commit address a kernel panic issue that can happen if Userspace
tries to partially unmap a GPU virtual region (aka drm_gpuva).
The VM_BIND interface allows partial unmapping of a BO.
Panthor driver pre-allocates memory for the new drm_gpuva structures
that would be needed for the map/unmap operation, done using drm_gpuvm
layer. It expected that only one new drm_gpuva would be needed on umap
but a partial unmap can require 2 new drm_gpuva and that's why it
ended up doing a NULL pointer dereference causing a kernel panic.
Following dump was seen when partial unmap was exercised.
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078
Mem abort info:
ESR = 0x0000000096000046
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x06: level 2 translation fault
Data abort info:
ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
CM = 0, WnR = 1, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000
[000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000
Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP
<snip>
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]
lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor]
sp : ffff800085d43970
x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000
x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000
x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180
x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010
x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c
x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58
x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c
x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7
x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001
x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078
Call trace:
panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]
op_remap_cb.isra.22+0x50/0x80
__drm_gpuvm_sm_unmap+0x10c/0x1c8
drm_gpuvm_sm_unmap+0x40/0x60
panthor_vm_exec_op+0xb4/0x3d0 [panthor]
panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor]
panthor_ioctl_vm_bind+0x160/0x4a0 [panthor]
drm_ioctl_kernel+0xbc/0x138
drm_ioctl+0x240/0x500
__arm64_sys_ioctl+0xb0/0xf8
invoke_syscall+0x4c/0x110
el0_svc_common.constprop.1+0x98/0xf8
do_el0_svc+0x24/0x38
el0_svc+0x40/0xf8
el0t_64_sync_handler+0xa0/0xc8
el0t_64_sync+0x174/0x178 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix device resources accessed after device removal
Correct possible race conditions during device removal.
Previously, a scheduled work item to reset a LUN could still execute
after the device was removed, leading to use-after-free and other
resource access issues.
This race condition occurs because the abort handler may schedule a LUN
reset concurrently with device removal via sdev_destroy(), leading to
use-after-free and improper access to freed resources.
- Check in the device reset handler if the device is still present in
the controller's SCSI device list before running; if not, the reset
is skipped.
- Cancel any pending TMF work that has not started in sdev_destroy().
- Ensure device freeing in sdev_destroy() is done while holding the
LUN reset mutex to avoid races with ongoing resets. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection
The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL
event_spec field, indicating support for IIO events. However, event
detection is not supported for all sensors, and if userspace tries to
configure accelerometer wakeup events on a sensor device that does not
support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL
pointer when trying to write to the wakeup register.
Define an additional struct iio_chan_spec array whose members have a NULL
event_spec field, and use this array instead of st_lsm6dsx_acc_channels for
sensors without event detection capability. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: ac97: fix a double free in snd_ac97_controller_register()
If ac97_add_adapter() fails, put_device() is the correct way to drop
the device reference. kfree() is not required.
Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do
the cleanup.
Found by code review. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/fpu: Fix false-positive kmsan report in fpu_vstl()
A false-positive kmsan report is detected when running ping command.
An inline assembly instruction 'vstl' can write varied amount of bytes
depending on value of 'index' argument. If 'index' > 0, 'vstl' writes
at least 2 bytes.
clang generates kmsan write helper call depending on inline assembly
constraints. Constraints are evaluated compile-time, but value of
'index' argument is known only at runtime.
clang currently generates call to __msan_instrument_asm_store with 1 byte
as size. Manually call kmsan function to indicate correct amount of bytes
written and fix false-positive report.
This change fixes following kmsan reports:
[ 36.563119] =====================================================
[ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70
[ 36.563852] virtqueue_add+0x35c6/0x7c70
[ 36.564016] virtqueue_add_outbuf+0xa0/0xb0
[ 36.564266] start_xmit+0x288c/0x4a20
[ 36.564460] dev_hard_start_xmit+0x302/0x900
[ 36.564649] sch_direct_xmit+0x340/0xea0
[ 36.564894] __dev_queue_xmit+0x2e94/0x59b0
[ 36.565058] neigh_resolve_output+0x936/0xb40
[ 36.565278] __neigh_update+0x2f66/0x3a60
[ 36.565499] neigh_update+0x52/0x60
[ 36.565683] arp_process+0x1588/0x2de0
[ 36.565916] NF_HOOK+0x1da/0x240
[ 36.566087] arp_rcv+0x3e4/0x6e0
[ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0
[ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0
[ 36.566710] napi_complete_done+0x376/0x740
[ 36.566918] virtnet_poll+0x1bae/0x2910
[ 36.567130] __napi_poll+0xf4/0x830
[ 36.567294] net_rx_action+0x97c/0x1ed0
[ 36.567556] handle_softirqs+0x306/0xe10
[ 36.567731] irq_exit_rcu+0x14c/0x2e0
[ 36.567910] do_io_irq+0xd4/0x120
[ 36.568139] io_int_handler+0xc2/0xe8
[ 36.568299] arch_cpu_idle+0xb0/0xc0
[ 36.568540] arch_cpu_idle+0x76/0xc0
[ 36.568726] default_idle_call+0x40/0x70
[ 36.568953] do_idle+0x1d6/0x390
[ 36.569486] cpu_startup_entry+0x9a/0xb0
[ 36.569745] rest_init+0x1ea/0x290
[ 36.570029] start_kernel+0x95e/0xb90
[ 36.570348] startup_continue+0x2e/0x40
[ 36.570703]
[ 36.570798] Uninit was created at:
[ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0
[ 36.571261] kmalloc_reserve+0x12a/0x470
[ 36.571553] __alloc_skb+0x310/0x860
[ 36.571844] __ip_append_data+0x483e/0x6a30
[ 36.572170] ip_append_data+0x11c/0x1e0
[ 36.572477] raw_sendmsg+0x1c8c/0x2180
[ 36.572818] inet_sendmsg+0xe6/0x190
[ 36.573142] __sys_sendto+0x55e/0x8e0
[ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0
[ 36.573571] __do_syscall+0x12e/0x240
[ 36.573823] system_call+0x6e/0x90
[ 36.573976]
[ 36.574017] Byte 35 of 98 is uninitialized
[ 36.574082] Memory access of size 98 starts at 0000000007aa0012
[ 36.574218]
[ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE
[ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST
[ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux)
[ 36.574755] =====================================================
[ 63.532541] =====================================================
[ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70
[ 63.533989] virtqueue_add+0x35c6/0x7c70
[ 63.534940] virtqueue_add_outbuf+0xa0/0xb0
[ 63.535861] start_xmit+0x288c/0x4a20
[ 63.536708] dev_hard_start_xmit+0x302/0x900
[ 63.537020] sch_direct_xmit+0x340/0xea0
[ 63.537997] __dev_queue_xmit+0x2e94/0x59b0
[ 63.538819] neigh_resolve_output+0x936/0xb40
[ 63.539793] ip_finish_output2+0x1ee2/0x2200
[ 63.540784] __ip_finish_output+0x272/0x7a0
[ 63.541765] ip_finish_output+0x4e/0x5e0
[ 63.542791] ip_output+0x166/0x410
[ 63.543771] ip_push_pending_frames+0x1a2/0x470
[ 63.544753] raw_sendmsg+0x1f06/0x2180
[ 63.545033] inet_sendmsg+0xe6/0x190
[ 63.546006] __sys_sendto+0x55e/0x8e0
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register()
When a file descriptor of pppol2tp socket is passed as file descriptor
of UDP socket, a recursive deadlock occurs in l2tp_tunnel_register().
This situation is reproduced by the following program:
int main(void)
{
int sock;
struct sockaddr_pppol2tp addr;
sock = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);
if (sock < 0) {
perror("socket");
return 1;
}
addr.sa_family = AF_PPPOX;
addr.sa_protocol = PX_PROTO_OL2TP;
addr.pppol2tp.pid = 0;
addr.pppol2tp.fd = sock;
addr.pppol2tp.addr.sin_family = PF_INET;
addr.pppol2tp.addr.sin_port = htons(0);
addr.pppol2tp.addr.sin_addr.s_addr = inet_addr("192.168.0.1");
addr.pppol2tp.s_tunnel = 1;
addr.pppol2tp.s_session = 0;
addr.pppol2tp.d_tunnel = 0;
addr.pppol2tp.d_session = 0;
if (connect(sock, (const struct sockaddr *)&addr, sizeof(addr)) < 0) {
perror("connect");
return 1;
}
return 0;
}
This program causes the following lockdep warning:
============================================
WARNING: possible recursive locking detected
6.2.0-rc5-00205-gc96618275234 #56 Not tainted
--------------------------------------------
repro/8607 is trying to acquire lock:
ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: l2tp_tunnel_register+0x2b7/0x11c0
but task is already holding lock:
ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_PPPOX);
lock(sk_lock-AF_PPPOX);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by repro/8607:
#0: ffff8880213c8130 (sk_lock-AF_PPPOX){+.+.}-{0:0}, at: pppol2tp_connect+0xa82/0x1a30
stack backtrace:
CPU: 0 PID: 8607 Comm: repro Not tainted 6.2.0-rc5-00205-gc96618275234 #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x100/0x178
__lock_acquire.cold+0x119/0x3b9
? lockdep_hardirqs_on_prepare+0x410/0x410
lock_acquire+0x1e0/0x610
? l2tp_tunnel_register+0x2b7/0x11c0
? lock_downgrade+0x710/0x710
? __fget_files+0x283/0x3e0
lock_sock_nested+0x3a/0xf0
? l2tp_tunnel_register+0x2b7/0x11c0
l2tp_tunnel_register+0x2b7/0x11c0
? sprintf+0xc4/0x100
? l2tp_tunnel_del_work+0x6b0/0x6b0
? debug_object_deactivate+0x320/0x320
? lockdep_init_map_type+0x16d/0x7a0
? lockdep_init_map_type+0x16d/0x7a0
? l2tp_tunnel_create+0x2bf/0x4b0
? l2tp_tunnel_create+0x3c6/0x4b0
pppol2tp_connect+0x14e1/0x1a30
? pppol2tp_put_sk+0xd0/0xd0
? aa_sk_perm+0x2b7/0xa80
? aa_af_perm+0x260/0x260
? bpf_lsm_socket_connect+0x9/0x10
? pppol2tp_put_sk+0xd0/0xd0
__sys_connect_file+0x14f/0x190
__sys_connect+0x133/0x160
? __sys_connect_file+0x190/0x190
? lockdep_hardirqs_on+0x7d/0x100
? ktime_get_coarse_real_ts64+0x1b7/0x200
? ktime_get_coarse_real_ts64+0x147/0x200
? __audit_syscall_entry+0x396/0x500
__x64_sys_connect+0x72/0xb0
do_syscall_64+0x38/0xb0
entry_SYSCALL_64_after_hwframe+0x63/0xcd
This patch fixes the issue by getting/creating the tunnel before
locking the pppol2tp socket. |
| In the Linux kernel, the following vulnerability has been resolved:
NFSD: NFSv4 file creation neglects setting ACL
An NFSv4 client that sets an ACL with a named principal during file
creation retrieves the ACL afterwards, and finds that it is only a
default ACL (based on the mode bits) and not the ACL that was
requested during file creation. This violates RFC 8881 section
6.4.1.3: "the ACL attribute is set as given".
The issue occurs in nfsd_create_setattr(), which calls
nfsd_attrs_valid() to determine whether to call nfsd_setattr().
However, nfsd_attrs_valid() checks only for iattr changes and
security labels, but not POSIX ACLs. When only an ACL is present,
the function returns false, nfsd_setattr() is skipped, and the
POSIX ACL is never applied to the inode.
Subsequently, when the client retrieves the ACL, the server finds
no POSIX ACL on the inode and returns one generated from the file's
mode bits rather than returning the originally-specified ACL. |
