December 2024 - Linux-stable-mirror

[PATCH v2 5.15] tty: n_gsm: Fix use-after-free in gsm_cleanup_mux

by mingli.yu＠eng.windriver.com

From: Longlong Xia <xialonglong(a)kylinos.cn> commit 9462f4ca56e7d2430fdb6dcc8498244acbfc4489 upstream. BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock. Signed-off-by: Longlong Xia <xialonglong(a)kylinos.cn> Cc: stable <stable(a)kernel.org> Suggested-by: Jiri Slaby <jirislaby(a)kernel.org> Link: https://lore.kernel.org/r/20240926130213.531959-1-xialonglong@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Mingli: Backport to fix CVE-2024-50073, no guard macro defined resolution] Signed-off-by: Mingli Yu <mingli.yu(a)windriver.com> --- drivers/tty/n_gsm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index aae9f73585bd..1becbdf7c470 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2443,6 +2443,7 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc) int i; struct gsm_dlci *dlci; struct gsm_msg *txq, *ntxq; + unsigned long flags; gsm->dead = true; mutex_lock(&gsm->mutex); @@ -2471,9 +2472,12 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm, bool disc) mutex_unlock(&gsm->mutex); /* Now wipe the queues */ tty_ldisc_flush(gsm->tty); + + spin_lock_irqsave(&gsm->tx_lock, flags); list_for_each_entry_safe(txq, ntxq, &gsm->tx_list, list) kfree(txq); INIT_LIST_HEAD(&gsm->tx_list); + spin_unlock_irqrestore(&gsm->tx_lock, flags); } /** -- 2.34.1

9 months, 1 week

4
4
0 0

[PATCH net] net :mana :Request a V2 response version for MANA_QUERY_GF_STAT

by Shradha Gupta

The current requested response version(V1) for MANA_QUERY_GF_STAT query results in STATISTICS_FLAGS_TX_ERRORS_GDMA_ERROR value being set to 0 always. In order to get the correct value for this counter we request the response version to be V2. Cc: stable(a)vger.kernel.org Fixes: e1df5202e879 ("net :mana :Add remaining GDMA stats for MANA to ethtool") Signed-off-by: Shradha Gupta <shradhagupta(a)linux.microsoft.com> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 57ac732e7707..f73848a4feb3 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -2536,6 +2536,7 @@ void mana_query_gf_stats(struct mana_port_context *apc) mana_gd_init_req_hdr(&req.hdr, MANA_QUERY_GF_STAT, sizeof(req), sizeof(resp)); + req.hdr.resp.msg_version = GDMA_MESSAGE_V2; req.req_stats = STATISTICS_FLAGS_RX_DISCARDS_NO_WQE | STATISTICS_FLAGS_RX_ERRORS_VPORT_DISABLED | STATISTICS_FLAGS_HC_RX_BYTES | -- 2.43.0

9 months, 1 week

1
0
0 0

Re: [PATCH] riscv: Fix vector state restore in rt_sigreturn()

by Yangyu Chen

I think this patch should also be backported to the v6.6 LTS tree. Since it should recolonize as Fixes: 8ee0b41898 ("riscv: signal: Add sigcontext save/restore for vector") and that commit first appears since v6.5-rc1 and this patch land to master branch since v6.9-rc3 Thanks, Yangyu Chen On 4/3/24 15:26, Björn Töpel wrote: > From: Björn Töpel <bjorn(a)rivosinc.com> > The RISC-V Vector specification states in "Appendix D: Calling > Convention for Vector State" [1] that "Executing a system call causes > all caller-saved vector registers (v0-v31, vl, vtype) and vstart to > become unspecified.". In the RISC-V kernel this is called "discarding > the vstate". > Returning from a signal handler via the rt_sigreturn() syscall, vector > discard is also performed. However, this is not an issue since the > vector state should be restored from the sigcontext, and therefore not > care about the vector discard. > The "live state" is the actual vector register in the running context, > and the "vstate" is the vector state of the task. A dirty live state, > means that the vstate and live state are not in synch. > When vectorized user_from_copy() was introduced, an bug sneaked in at > the restoration code, related to the discard of the live state. > An example when this go wrong: > 1. A userland application is executing vector code > 2. The application receives a signal, and the signal handler is > entered. > 3. The application returns from the signal handler, using the > rt_sigreturn() syscall. > 4. The live vector state is discarded upon entering the > rt_sigreturn(), and the live state is marked as "dirty", indicating > that the live state need to be synchronized with the current > vstate. > 5. rt_sigreturn() restores the vstate, except the Vector registers, > from the sigcontext > 6. rt_sigreturn() restores the Vector registers, from the sigcontext, > and now the vectorized user_from_copy() is used. The dirty live > state from the discard is saved to the vstate, making the vstate > corrupt. > 7. rt_sigreturn() returns to the application, which crashes due to > corrupted vstate. > Note that the vectorized user_from_copy() is invoked depending on the > value of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which > means that vlen has to be larger than 128b for this bug to trigger. > The fix is simply to mark the live state as non-dirty/clean prior > performing the vstate restore. > Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-relea… # [1] > Reported-by: Charlie Jenkins <charlie(a)rivosinc.com> > Reported-by: Vineet Gupta <vgupta(a)kernel.org> > Fixes: c2a658d41924 ("riscv: lib: vectorize copy_to_user/copy_from_user") > Signed-off-by: Björn Töpel <bjorn(a)rivosinc.com> > --- > arch/riscv/kernel/signal.c | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c > index 501e66debf69..5a2edd7f027e 100644 > --- a/arch/riscv/kernel/signal.c > +++ b/arch/riscv/kernel/signal.c > @@ -119,6 +119,13 @@ static long __restore_v_state(struct pt_regs *regs, void __user *sc_vec) > struct __sc_riscv_v_state __user *state = sc_vec; > void __user *datap; > + /* > + * Mark the vstate as clean prior performing the actual copy, > + * to avoid getting the vstate incorrectly clobbered by the > + * discarded vector state. > + */ > + riscv_v_vstate_set_restore(current, regs); > + > /* Copy everything of __sc_riscv_v_state except datap. */ > err = __copy_from_user(&current->thread.vstate, &state->v_state, > offsetof(struct __riscv_v_ext_state, datap)); > @@ -133,13 +140,7 @@ static long __restore_v_state(struct pt_regs *regs, void __user *sc_vec) > * Copy the whole vector content from user space datap. Use > * copy_from_user to prevent information leak. > */ > - err = copy_from_user(current->thread.vstate.datap, datap, riscv_v_vsize); > - if (unlikely(err)) > - return err; > - > - riscv_v_vstate_set_restore(current, regs); > - > - return err; > + return copy_from_user(current->thread.vstate.datap, datap, riscv_v_vsize); > } > #else > #define save_v_state(task, regs) (0) > base-commit: 7115ff4a8bfed3b9294bad2e111744e6abeadf1a

9 months, 1 week

1
0
0 0

[PATCH net-next v2 0/5] virtio_net: correct netdev_tx_reset_queue() invocation points

by Koichiro Den

When virtnet_close is followed by virtnet_open, some TX completions can possibly remain unconsumed, until they are finally processed during the first NAPI poll after the netdev_tx_reset_queue(), resulting in a crash [1]. Commit b96ed2c97c79 ("virtio_net: move netdev_tx_reset_queue() call before RX napi enable") was not sufficient to eliminate all BQL crash cases for virtio-net. This issue can be reproduced with the latest net-next master by running: `while :; do ip l set DEV down; ip l set DEV up; done` under heavy network TX load from inside the machine. This patch series resolves the issue and also addresses similar existing problems: (a). Drop netdev_tx_reset_queue() from open/close path. This eliminates the BQL crashes due to the problematic open/close path. (b). As a result of (a), netdev_tx_reset_queue() is now explicitly required in freeze/restore path. Add netdev_tx_reset_queue() to free_unused_bufs(). (c). Fix missing resetting in virtnet_tx_resize(). virtnet_tx_resize() has lacked proper resetting since commit c8bd1f7f3e61 ("virtio_net: add support for Byte Queue Limits"). (d). Fix missing resetting in the XDP_SETUP_XSK_POOL path. Similar to (c), this path lacked proper resetting. Call netdev_tx_reset_queue() when virtqueue_reset() has actually recycled unused buffers. This patch series consists of five commits: [1/5]: Resolves (a) and (b). [2/5]: Prerequisite for (c). [3/5]: Resolves (c). [4/5]: Preresuisite for (d). [5/5]: Resolves (d). Changes for v2: - add tx queue resetting for (b) to (d) above v1: https://lore.kernel.org/all/20241130181744.3772632-1-koichiro.den@canonical… [1]: ------------[ cut here ]------------ kernel BUG at lib/dynamic_queue_limits.c:99! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G N 6.12.0net-next_main+ #2 Tainted: [N]=TEST Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), \ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 Code: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff <0f> 0b 01 d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009 RDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000 RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001 R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40 FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <IRQ> ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? dql_completed+0x26b/0x290 ? exc_invalid_op+0x4c/0x60 ? dql_completed+0x26b/0x290 ? asm_exc_invalid_op+0x16/0x20 ? dql_completed+0x26b/0x290 __free_old_xmit+0xff/0x170 [virtio_net] free_old_xmit+0x54/0xc0 [virtio_net] virtnet_poll+0xf4/0xe30 [virtio_net] ? __update_load_avg_cfs_rq+0x264/0x2d0 ? update_curr+0x35/0x260 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? sched_clock_cpu+0xd/0x1a0 handle_softirqs+0x138/0x3e0 do_softirq.part.0+0x89/0xc0 </IRQ> <TASK> __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicast+0x23e/0x390 ? netlink_sendmsg+0x21e/0x490 ? ____sys_sendmsg+0x31b/0x350 ? avc_has_perm_noaudit+0x67/0xf0 ? cred_has_capability.isra.0+0x75/0x110 ? __nla_validate_parse+0x5f/0xee0 ? __pfx___probestub_irq_enable+0x3/0x10 ? __create_object+0x5e/0x90 ? security_capable+0x3b/0x7[I0 rtnl_newlink+0x784/0xaf0 ? avc_has_perm_noaudit+0x67/0xf0 ? cred_has_capability.isra.0+0x75/0x110 ? stack_depot_save_flags+0x24/0x6d0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x34f/0x3f0 ? do_syscall_64+0x6c/0x180 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 netlink_unicast+0x23e/0x390 netlink_sendmsg+0x21e/0x490 ____sys_sendmsg+0x31b/0x350 ? copy_msghdr_from_user+0x6d/0xa0 ___sys_sendmsg+0x86/0xd0 ? __pte_offset_map+0x17/0x160 ? preempt_count_add+0x69/0xa0 ? __call_rcu_common.constprop.0+0x147/0x610 ? preempt_count_add+0x69/0xa0 ? preempt_count_add+0x69/0xa0 ? _raw_spin_trylock+0x13/0x60 ? trace_hardirqs_on+0x1d/0x80 __sys_sendmsg+0x66/0xc0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f41defe5b34 Code: 15 e1 12 0f 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d 35 95 0f 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:00007ffe5336ecc8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f41defe5b34 RDX: 0000000000000000 RSI: 00007ffe5336ed30 RDI: 0000000000000003 RBP: 00007ffe5336eda0 R08: 0000000000000010 R09: 0000000000000001 R10: 00007ffe5336f6f9 R11: 0000000000000202 R12: 0000000000000003 R13: 0000000067452259 R14: 0000556ccc28b040 R15: 0000000000000000 </TASK> [...] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Koichiro Den (5): virtio_net: correct netdev_tx_reset_queue() invocation point virtio_ring: add 'flushed' as an argument to virtqueue_resize() virtio_net: add missing netdev_tx_reset_queue() to virtnet_tx_resize() virtio_ring: add 'flushed' as an argument to virtqueue_reset() virtio_net: add missing netdev_tx_reset_queue to virtnet_sq_bind_xsk_pool() drivers/net/virtio_net.c | 18 +++++++++++++----- drivers/virtio/virtio_ring.c | 13 +++++++++++-- include/linux/virtio.h | 6 ++++-- 3 files changed, 28 insertions(+), 9 deletions(-) -- 2.43.0

9 months, 1 week

3
11
0 0

[PATCH] net: wireless: sme: Initialize n_channels before accessing channels in cfg80211_conn_scan

by Haoyu Li

With the new __counted_by annocation in cfg80211_scan_request struct, the "n_channels" struct member must be set before accessing the "channels" array. Failing to do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Signed-off-by: Haoyu Li <lihaoyu499(a)gmail.com> --- net/wireless/sme.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/wireless/sme.c b/net/wireless/sme.c index 431da30817a6..268171600087 100644 --- a/net/wireless/sme.c +++ b/net/wireless/sme.c @@ -83,6 +83,7 @@ static int cfg80211_conn_scan(struct wireless_dev *wdev) if (!request) return -ENOMEM; + request->n_channels = n_channels; if (wdev->conn->params.channel) { enum nl80211_band band = wdev->conn->params.channel->band; struct ieee80211_supported_band *sband = -- 2.34.1

9 months, 1 week

4
4
0 0

[net] net: Make napi_hash_lock irq safe

by Joe Damato

Make napi_hash_lock IRQ safe. It is used during the control path, and is taken and released in napi_hash_add and napi_hash_del, which will typically be called by calls to napi_enable and napi_disable. This change avoids a deadlock in pcnet32 (and other any other drivers which follow the same pattern): CPU 0: pcnet32_open spin_lock_irqsave(&lp->lock, ...) napi_enable napi_hash_add <- before this executes, CPU 1 proceeds spin_lock(napi_hash_lock) [...] spin_unlock_irqrestore(&lp->lock, flags); CPU 1: pcnet32_close napi_disable napi_hash_del spin_lock(napi_hash_lock) < INTERRUPT > pcnet32_interrupt spin_lock(lp->lock) <- DEADLOCK Changing the napi_hash_lock to be IRQ safe prevents the IRQ from firing on CPU 1 until napi_hash_lock is released, preventing the deadlock. Cc: stable(a)vger.kernel.org Fixes: 86e25f40aa1e ("net: napi: Add napi_config") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Closes: https://lore.kernel.org/netdev/85dd4590-ea6b-427d-876a-1d8559c7ad82@roeck-u… Suggested-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Joe Damato <jdamato(a)fastly.com> --- net/core/dev.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 13d00fc10f55..45a8c3dd4a64 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -6557,18 +6557,22 @@ static void __napi_hash_add_with_id(struct napi_struct *napi, static void napi_hash_add_with_id(struct napi_struct *napi, unsigned int napi_id) { - spin_lock(&napi_hash_lock); + unsigned long flags; + + spin_lock_irqsave(&napi_hash_lock, flags); WARN_ON_ONCE(napi_by_id(napi_id)); __napi_hash_add_with_id(napi, napi_id); - spin_unlock(&napi_hash_lock); + spin_unlock_irqrestore(&napi_hash_lock, flags); } static void napi_hash_add(struct napi_struct *napi) { + unsigned long flags; + if (test_bit(NAPI_STATE_NO_BUSY_POLL, &napi->state)) return; - spin_lock(&napi_hash_lock); + spin_lock_irqsave(&napi_hash_lock, flags); /* 0..NR_CPUS range is reserved for sender_cpu use */ do { @@ -6578,7 +6582,7 @@ static void napi_hash_add(struct napi_struct *napi) __napi_hash_add_with_id(napi, napi_gen_id); - spin_unlock(&napi_hash_lock); + spin_unlock_irqrestore(&napi_hash_lock, flags); } /* Warning : caller is responsible to make sure rcu grace period @@ -6586,11 +6590,13 @@ static void napi_hash_add(struct napi_struct *napi) */ static void napi_hash_del(struct napi_struct *napi) { - spin_lock(&napi_hash_lock); + unsigned long flags; + + spin_lock_irqsave(&napi_hash_lock, flags); hlist_del_init_rcu(&napi->napi_hash_node); - spin_unlock(&napi_hash_lock); + spin_unlock_irqrestore(&napi_hash_lock, flags); } static enum hrtimer_restart napi_watchdog(struct hrtimer *timer) -- 2.25.1

9 months, 1 week

4
3
0 0

[PATCH] dt-bindings: soc: fsl: cpm_qe: Limit matching to nodes with "fsl,qe"

by Chen-Yu Tsai

Otherwise the binding matches against random nodes with "simple-bus" giving out all kinds of invalid warnings: $ make CHECK_DTBS=y mediatek/mt8188-evb.dtb SYNC include/config/auto.conf.cmd UPD include/config/kernel.release SCHEMA Documentation/devicetree/bindings/processed-schema.json DTC [C] arch/arm64/boot/dts/mediatek/mt8188-evb.dtb arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: compatible:0: 'fsl,qe' was expected from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: compatible: ['simple-bus'] is too short from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000:compatible:0: 'fsl,qe-ic' was expected from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000:reg: [[0, 201326592, 0, 262144], [0, 201588736, 0, 2097152]] is too long from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000:#interrupt-cells:0:0: 1 was expected from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: interrupt-controller@c000000: '#redistributor-regions', 'ppi-partitions' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: 'reg' is a required property from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# arch/arm64/boot/dts/mediatek/mt8188-evb.dtb: soc: 'bus-frequency' is a required property from schema $id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,qe.yaml# Fixes: ecbfc6ff94a2 ("dt-bindings: soc: fsl: cpm_qe: convert to yaml format") Cc: Frank Li <Frank.Li(a)nxp.com> Cc: <stable(a)vger.kernel.org> # v6.11+ Signed-off-by: Chen-Yu Tsai <wenst(a)chromium.org> --- .../devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml index 89cdf5e1d0a8..9e07a2c4d05b 100644 --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,qe.yaml @@ -21,6 +21,14 @@ description: | The description below applies to the qe of MPC8360 and more nodes and properties would be extended in the future. +select: + properties: + compatible: + contains: + const: fsl,qe + required: + - compatible + properties: compatible: items: -- 2.47.0.338.g60cca15819-goog

9 months, 1 week

3
3
0 0

[PATCH] drivers: clk: clk-en7523.c: Initialize num before accessing hws in en7523_register_clocks

by Haoyu Li

With the new __counted_by annocation in clk_hw_onecell_data, the "num" struct member must be set before accessing the "hws" array. Failing to do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Signed-off-by: Haoyu Li <lihaoyu499(a)gmail.com> --- drivers/clk/clk-en7523.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c index e52c5460e927..61d95ead5ec4 100644 --- a/drivers/clk/clk-en7523.c +++ b/drivers/clk/clk-en7523.c @@ -503,6 +503,8 @@ static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_dat u32 rate; int i; + clk_data->num = EN7523_NUM_CLOCKS; + for (i = 0; i < ARRAY_SIZE(en7523_base_clks); i++) { const struct en_clk_desc *desc = &en7523_base_clks[i]; u32 reg = desc->div_reg ? desc->div_reg : desc->base_reg; @@ -524,8 +526,6 @@ static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_dat hw = en7523_register_pcie_clk(dev, np_base); clk_data->hws[EN7523_CLK_PCIE] = hw; - - clk_data->num = EN7523_NUM_CLOCKS; } static int en7523_clk_hw_init(struct platform_device *pdev, -- 2.34.1

9 months, 1 week

3
2
0 0

Possible wrong fix patch for some stable branches

by Zhang Zekun

Hi, All The mainline patch to fix CVE-2024-50282 add a check to fix a potential buffer overflow issue in amdgpu_debugfs_gprwave_read() which is introduced in commit 553f973a0d7b ("drm/amd/amdgpu: Update debugfs for XCC support (v3)"), but some linux-stable fix patches add the check in some other funcitons, is something wrong here? Stable version which contain the suspicious patches: Fixed in 4.19.324 with commit 673bdb4200c0: Fixed in amdgpu_debugfs_regs_smc_read() Fixed in 5.4.286 with commit 7ccd781794d2: Fixed in amdgpu_debugfs_regs_smc_read() Fixed in 5.10.230 with commit 17f5f18085ac: Fixed in amdgpu_debugfs_regs_pcie_write() Fixed in 5.15.172 with commit aaf6160a4b7f: Fixed in amdgpu_debugfs_regs_didt_write() Fixed in 6.1.117 with commit 25d7e84343e1: Fixed in amdgpu_debugfs_regs_pcie_write() Link to mainline fix patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…

9 months, 1 week

4
3
0 0

[PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden

by Marc Zyngier

Catalin reports that a hypervisor lying to a guest about the size of the ASID field may result in unexpected issues: - if the underlying HW does only supports 8 bit ASIDs, the ASID field in a TLBI VAE1* operation is only 8 bits, and the HW will ignore the other 8 bits - if on the contrary the HW is 16 bit capable, the ASID field in the same TLBI operation is always 16 bits, irrespective of the value of TCR_ELx.AS. This could lead to missed invalidations if the guest was lead to assume that the HW had 8 bit ASIDs while they really are 16 bit wide. In order to avoid any potential disaster that would be hard to debug, prenent the migration between a host with 8 bit ASIDs to one with wider ASIDs (the converse was obviously always forbidden). This is also consistent with what we already do for VMIDs. If it becomes absolutely mandatory to support such a migration path in the future, we will have to trap and emulate all TLBIs, something that nobody should look forward to. Fixes: d5a32b60dc18 ("KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1") Reported-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Cc: Will Deacon <will(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Marc Zyngier <maz(a)kernel.org> Cc: James Morse <james.morse(a)arm.com> Cc: Oliver Upton <oliver.upton(a)linux.dev> --- arch/arm64/kvm/sys_regs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index a26f02ec8748..b1918adbd0aa 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -2674,7 +2674,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_WRITABLE(ID_AA64MMFR0_EL1, ~(ID_AA64MMFR0_EL1_RES0 | ID_AA64MMFR0_EL1_TGRAN4_2 | ID_AA64MMFR0_EL1_TGRAN64_2 | - ID_AA64MMFR0_EL1_TGRAN16_2)), + ID_AA64MMFR0_EL1_TGRAN16_2 | + ID_AA64MMFR0_EL1_ASIDBITS)), ID_WRITABLE(ID_AA64MMFR1_EL1, ~(ID_AA64MMFR1_EL1_RES0 | ID_AA64MMFR1_EL1_HCX | ID_AA64MMFR1_EL1_TWED | -- 2.43.0

9 months, 1 week

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024