January 2025 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] tracing: Prevent bad count for tracing_cpumask_write
by Luo Gengkun 07 Jan '25

07 Jan '25

From: Lizhi Xu <lizhi.xu(a)windriver.com> stable inclusion from stable-v6.6.69 commit 03041e474a6a8f1bfd4b96b164bb3165c48fa1a3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBG2PO CVE: CVE-2024-56763 Reference: https://git.kernel.org/stable/c/03041e474a6a8f1bfd4b96b164bb3165c48fa1a3 -------------------------------- commit 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 upstream. If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it. Cc: stable(a)vger.kernel.org Fixes: 9e01c1b74c953 ("cpumask: convert kernel trace functions") Link: https://lore.kernel.org/20241216073238.2573704-1-lizhi.xu@windriver.com Reported-by: syzbot+0aecfd34fb878546f3fd(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0aecfd34fb878546f3fd Tested-by: syzbot+0aecfd34fb878546f3fd(a)syzkaller.appspotmail.com Signed-off-by: Lizhi Xu <lizhi.xu(a)windriver.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/trace/trace.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 02bc8e03ffa1..24c995d1dab2 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -5331,6 +5331,9 @@ tracing_cpumask_write(struct file *filp, const char __user *ubuf, cpumask_var_t tracing_cpumask_new; int err; + if (count == 0 || count > KMALLOC_MAX_SIZE) + return -EINVAL; + if (!zalloc_cpumask_var(&tracing_cpumask_new, GFP_KERNEL)) return -ENOMEM; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-56567
by Liao Chen 07 Jan '25

07 Jan '25

fix CVE-2024-56567 Zicheng Qu (1): ad7780: fix division by zero in ad7780_write_raw() drivers/iio/adc/ad7780.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[openeuler:OLK-5.10 2656/2656] kernel/rcu/update.o: warning: objtool: synchronize_rcu_tasks_trace()+0xde: unreachable instruction
by kernel test robot 07 Jan '25

07 Jan '25

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 9be6ae394c896999214be0f875765d2c58d15b13 commit: 2509f2079e7247ed0d695bdb69c3d019a700a4b8 [2656/2656] rcu-tasks: Make rude RCU-Tasks work well with CPU hotplug config: x86_64-buildonly-randconfig-006-20250107 (https://download.01.org/0day-ci/archive/20250107/202501071757.EREnWTHH-lkp@…) compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250107/202501071757.EREnWTHH-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202501071757.EREnWTHH-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/rcu/update.o: warning: objtool: synchronize_rcu_tasks_trace()+0xde: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS 0/3] CVE-2024-56642
by Liu Jian 07 Jan '25

07 Jan '25

CVE-2024-56642 Eric Dumazet (1): tipc: fix NULL deref in cleanup_bearer() Kuniyuki Iwashima (1): tipc: Fix use-after-free of kernel socket in cleanup_bearer(). Xin Long (1): tipc: remove ub->ubsock checks net/tipc/udp_media.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6] bpf, sockmap: Several fixes to bpf_msg_pop_data
by Liu Jian 07 Jan '25

07 Jan '25

From: Zijian Zhang <zijianzhang(a)bytedance.com> stable inclusion from stable-v6.6.64 commit 98c7ea7d11f2588e8197db042e0291e4ac8f8346 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFC CVE: CVE-2024-56720 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit 5d609ba262475db450ba69b8e8a557bd768ac07a ] Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG. Fixes: 7246d8ed4dcc ("bpf: helper to pop data from messages") Signed-off-by: Zijian Zhang <zijianzhang(a)bytedance.com> Reviewed-by: John Fastabend <john.fastabend(a)gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-8-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/core/filter.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 48dd2896ee1d9..131a21b5463cc 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -2889,8 +2889,10 @@ static const struct bpf_func_proto bpf_msg_push_data_proto = { static void sk_msg_shift_left(struct sk_msg *msg, int i) { + struct scatterlist *sge = sk_msg_elem(msg, i); int prev; + put_page(sg_page(sge)); do { prev = i; sk_msg_iter_var_next(i); @@ -2927,6 +2929,9 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, if (unlikely(flags)) return -EINVAL; + if (unlikely(len == 0)) + return 0; + /* First find the starting scatterlist element */ i = msg->sg.start; do { @@ -2939,7 +2944,7 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, } while (i != msg->sg.end); /* Bounds checks: start and pop must be inside message */ - if (start >= offset + l || last >= msg->sg.size) + if (start >= offset + l || last > msg->sg.size) return -EINVAL; space = MAX_MSG_FRAGS - sk_msg_elem_used(msg); @@ -2968,12 +2973,12 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, */ if (start != offset) { struct scatterlist *nsge, *sge = sk_msg_elem(msg, i); - int a = start; + int a = start - offset; int b = sge->length - pop - a; sk_msg_iter_var_next(i); - if (pop < sge->length - a) { + if (b > 0) { if (space) { sge->length = a; sk_msg_shift_right(msg, i); @@ -2992,7 +2997,6 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, if (unlikely(!page)) return -ENOMEM; - sge->length = a; orig = sg_page(sge); from = sg_virt(sge); to = page_address(page); @@ -3002,7 +3006,7 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, put_page(orig); } pop = 0; - } else if (pop >= sge->length - a) { + } else { pop -= (sge->length - a); sge->length = a; } @@ -3036,7 +3040,6 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, pop -= sge->length; sk_msg_shift_left(msg, i); } - sk_msg_iter_var_next(i); } sk_mem_uncharge(msg->sk, len - pop); -- 2.34.1

2 5

[PATCH OLK-5.10] tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
by Liu Jian 07 Jan '25

07 Jan '25

From: Zijian Zhang <zijianzhang(a)bytedance.com> stable inclusion from stable-v5.10.231 commit dbedc7e142df5ea238a46fdd7462c1c42cd36a10 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEANQ CVE: CVE-2024-56633 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit ca70b8baf2bd125b2a4d96e76db79375c07d7ff2 ] The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value apply_bytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes. [...] 415 tosend = msg->sg.size; 416 if (psock->apply_bytes && psock->apply_bytes < tosend) 417 tosend = psock->apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg->sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret < 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...] When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke sk_msg_free. Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg->sg.size - apply_bytes) bytes. The same warning will be reported in selftest. [...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] So instead of sk_msg_free_partial we can do sk_msg_free here. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Fixes: 8ec95b94716a ("bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues") Signed-off-by: Zijian Zhang <zijianzhang(a)bytedance.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Link: https://lore.kernel.org/bpf/20241016234838.3167769-3-zijianzhang@bytedance.… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv4/tcp_bpf.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c index 8645017da9df9..384121426ea28 100644 --- a/net/ipv4/tcp_bpf.c +++ b/net/ipv4/tcp_bpf.c @@ -447,7 +447,6 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock, cork = true; psock->cork = NULL; } - sk_msg_return(sk, msg, tosend); release_sock(sk); origsize = msg->sg.size; @@ -459,8 +458,9 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock, sock_put(sk_redir); lock_sock(sk); + sk_mem_uncharge(sk, sent); if (unlikely(ret < 0)) { - int free = sk_msg_free_nocharge(sk, msg); + int free = sk_msg_free(sk, msg); if (!cork) *copied -= free; @@ -474,7 +474,7 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock, break; case __SK_DROP: default: - sk_msg_free_partial(sk, msg, tosend); + sk_msg_free(sk, msg); sk_msg_apply_bytes(psock, tosend); *copied -= (tosend + delta); return -EACCES; @@ -490,11 +490,8 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock, } if (msg && msg->sg.data[msg->sg.start].page_link && - msg->sg.data[msg->sg.start].length) { - if (eval == __SK_REDIRECT) - sk_mem_charge(sk, tosend - sent); + msg->sg.data[msg->sg.start].length) goto more_data; - } } return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6] drm/i915/hdcp: Add encoder check in hdcp2_get_capability
by He Yujie 07 Jan '25

07 Jan '25

From: Suraj Kandpal <suraj.kandpal(a)intel.com> mainline inclusion from mainline-v6.12-rc1 commit d34f4f058edf1235c103ca9c921dc54820d14d40 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB5KQZ CVE: CVE-2024-53050 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Add encoder check in intel_hdcp2_get_capability to avoid null pointer error. Signed-off-by: Suraj Kandpal <suraj.kandpal(a)intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722064451.3610512-3-sura… Conflicts: drivers/gpu/drm/i915/display/intel_hdcp.c drivers/gpu/drm/i915/display/intel_dp_hdcp.c [ Context conflict: 130849f8ec14("drm/i915/hdcp: Use intel_connector as argument for hdcp_2_2_capable") a35239a89259("drm/i915/hdcp: Use correct aux for capability check scenario") 287c0de8b294("drm/i915/hdcp: Move to direct reads for HDCP") 55d9b2b8e440("drm/i915/hdcp: Refactor intel_dp_hdcp2_capable") 8e754d9e9e8a("drm/i915/hdcp: Rename hdcp capable functions") the above patches are not merge. ] Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/gpu/drm/i915/display/intel_hdcp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index cb99839afcd0..762170e6cbbb 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -163,7 +163,7 @@ bool intel_hdcp_capable(struct intel_connector *connector) /* Is HDCP2.2 capable on Platform and Sink */ bool intel_hdcp2_capable(struct intel_connector *connector) { - struct intel_digital_port *dig_port = intel_attached_dig_port(connector); + struct intel_digital_port *dig_port; struct drm_i915_private *i915 = to_i915(connector->base.dev); struct intel_hdcp *hdcp = &connector->hdcp; bool capable = false; @@ -192,6 +192,11 @@ bool intel_hdcp2_capable(struct intel_connector *connector) } mutex_unlock(&i915->display.hdcp.hdcp_mutex); + if (!intel_attached_encoder(connector)) + return false; + + dig_port = intel_attached_dig_port(connector); + /* Sink's capability for HDCP2.2 */ hdcp->shim->hdcp_2_2_capable(dig_port, &capable); -- 2.34.1

2 1

[PATCH OLK-6.6] nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
by He Yujie 07 Jan '25

07 Jan '25

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v6.6.63 commit 59b49ca67cca7b007a5afd3de0283c8008157665 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBA6RL CVE: CVE-2024-53131 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit cd45e963e44b0f10d90b9e6c0e8b4f47f3c92471 upstream. Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. Link: https://lkml.kernel.org/r/20241106160811.3316-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20241106160811.3316-2-konishi.ryusuke@gmail.com Fixes: 5305cb830834 ("block: add block_{touch|dirty}_buffer tracepoint") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: Ubisectech Sirius <bugreport(a)valiantsec.com> Closes: https://lkml.kernel.org/r/86bd3013-887e-4e38-960f-ca45c657f032.bugreport@va… Reported-by: syzbot+9982fb8d18eba905abe2(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9982fb8d18eba905abe2 Tested-by: syzbot+9982fb8d18eba905abe2(a)syzkaller.appspotmail.com Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- fs/nilfs2/page.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/nilfs2/page.c b/fs/nilfs2/page.c index 9bced0a5c253..144e200c4909 100644 --- a/fs/nilfs2/page.c +++ b/fs/nilfs2/page.c @@ -39,7 +39,6 @@ __nilfs_get_page_block(struct page *page, unsigned long block, pgoff_t index, first_block = (unsigned long)index << (PAGE_SHIFT - blkbits); bh = nilfs_page_get_nth_block(page, block - first_block); - touch_buffer(bh); wait_on_buffer(bh); return bh; } -- 2.34.1

2 1

[PATCH OLK-6.6] octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
by He Yujie 07 Jan '25

07 Jan '25

From: Dipendra Khadka <kdipendra88(a)gmail.com> stable inclusion from stable-v6.6.64 commit c0f64fd73b60aee85f88c270c9d714ead27a7b7a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBA6RL CVE: CVE-2024-56728 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e26f8eac6bb20b20fdb8f7dc695711ebce4c7c5c ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: 75f36270990c ("octeontx2-pf: Support to enable/disable pause frames via ethtool") Fixes: d0cf9503e908 ("octeontx2-pf: ethtool fec mode support") Signed-off-by: Dipendra Khadka <kdipendra88(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- .../net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c index 8b7fc0af91ce..532e84bc38c7 100644 --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c @@ -343,6 +343,11 @@ static void otx2_get_pauseparam(struct net_device *netdev, if (!otx2_sync_mbox_msg(&pfvf->mbox)) { rsp = (struct cgx_pause_frm_cfg *) otx2_mbox_get_rsp(&pfvf->mbox.mbox, 0, &req->hdr); + if (IS_ERR(rsp)) { + mutex_unlock(&pfvf->mbox.lock); + return; + } + pause->rx_pause = rsp->rx_pause; pause->tx_pause = rsp->tx_pause; } @@ -1082,6 +1087,11 @@ static int otx2_set_fecparam(struct net_device *netdev, rsp = (struct fec_mode *)otx2_mbox_get_rsp(&pfvf->mbox.mbox, 0, &req->hdr); + if (IS_ERR(rsp)) { + err = PTR_ERR(rsp); + goto end; + } + if (rsp->fec >= 0) pfvf->linfo.fec = rsp->fec; else -- 2.34.1

2 1

[PATCH OLK-6.6] usb: musb: Fix hardware lockup on first Rx endpoint request
by He Yujie 07 Jan '25

07 Jan '25

From: Hubert Wiśniewski <hubert.wisniewski.25632(a)gmail.com> stable inclusion from stable-v6.6.64 commit 5906ee3693674d734177df13a519a21bb03f730d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBA6RL CVE: CVE-2024-56687 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3fc137386c4620305bbc2a216868c53f9245670a upstream. There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls): req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300) According to the docstring of usb_ep_queue(), this should not happen: "Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardware lockup might occur in the following sequence: 1. The gadget is initialized using musb_gadget_enable(). 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt. 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set. 4. The first request is enqueued using usb_ep_queue(), leading to the call of req->complete(), as shown in the call trace above. 5. If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usb_g_giveback() removes the request before invoking the callback. 6. The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set. For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rx_complete() callback calls netif_rx(). If called in the task context, netif_rx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rx_complete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host. The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways: 1. Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netif_rx() interacts with interrupts was already quite challenging and u_ether is not the only function driver. Similar "bugs" could be hidden in other drivers as well. 2. Disable MUSB interrupts in musb_g_giveback() before calling the callback and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack. 3. Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them. 4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once IRQs are enabled, the interrupt handler will be able to correctly process the next incoming packet (eventually calling rxstate()). This approach may cause one or two packets to be dropped (two if double buffering is enabled), but this seems to be a minor issue, as packet loss can occur when the software is not yet ready to process them. Additionally, this solution makes the gadget driver compliant with the rule mentioned in the docstring of usb_ep_queue(). There may be additional solutions, but from these four, the last one has been chosen as it seems to be the most appropriate, as it addresses the "bad" behavior of the driver. Fixes: baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context.") Cc: stable(a)vger.kernel.org Signed-off-by: Hubert Wiśniewski <hubert.wisniewski.25632(a)gmail.com> Link: https://lore.kernel.org/r/4ee1ead4525f78fb5909a8cbf99513ad0082ad21.camel@gm… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- drivers/usb/musb/musb_gadget.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 051c6da7cf6d..f175cb2c3e7b 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -1170,12 +1170,19 @@ struct free_record { */ void musb_ep_restart(struct musb *musb, struct musb_request *req) { + u16 csr; + void __iomem *epio = req->ep->hw_ep->regs; + trace_musb_req_start(req); musb_ep_select(musb->mregs, req->epnum); - if (req->tx) + if (req->tx) { txstate(musb, req); - else - rxstate(musb, req); + } else { + csr = musb_readw(epio, MUSB_RXCSR); + csr |= MUSB_RXCSR_FLUSHFIFO | MUSB_RXCSR_P_WZC_BITS; + musb_writew(epio, MUSB_RXCSR, csr); + musb_writew(epio, MUSB_RXCSR, csr); + } } static int musb_ep_restart_resume_work(struct musb *musb, void *data) -- 2.34.1

2 1

2025

2024

2023

2022

2021

2020

2019

Kernel January 2025