mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 25 participants
  • 20261 discussions
[PATCH openEuler-1.0-LTS] tty: fix deadlock caused by calling printk() under tty_port->lock
by Gu Bowen 29 Mar '25

29 Mar '25
From: Qi Zheng <zhengqi.arch(a)bytedance.com> stable inclusion from stable-v4.19.247 commit 04ee31678c128a6cc7bb057ea189a8624ba5a314 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP2T9 CVE: CVE-2022-49441 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ] pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner); vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023 vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 fail_dump lib/fault-inject.c:45 [inline] should_fail+0x67b/0x7c0 lib/fault-inject.c:144 __should_failslab+0x152/0x1c0 mm/failslab.c:33 should_failslab+0x5/0x10 mm/slab_common.c:1224 slab_pre_alloc_hook mm/slab.h:468 [inline] slab_alloc_node mm/slub.c:2723 [inline] slab_alloc mm/slub.c:2807 [inline] __kmalloc+0x72/0x300 mm/slub.c:3871 kmalloc include/linux/slab.h:582 [inline] tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175 __tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273 tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318 tty_insert_flip_string include/linux/tty_flip.h:37 [inline] pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock); n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356 do_tty_write drivers/tty/tty_io.c:961 [inline] tty_write+0x512/0x930 drivers/tty/tty_io.c:1045 __vfs_write+0x76/0x100 fs/read_write.c:494 [...] other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &port->lock Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com Fixes: b6da31b2c07c ("tty: Fix data race in tty_insert_flip_string_fixed_flag") Signed-off-by: Qi Zheng <zhengqi.arch(a)bytedance.com> Acked-by: Jiri Slaby <jirislaby(a)kernel.org> Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Akinobu Mita <akinobu.mita(a)gmail.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/tty/tty_buffer.c [Context conflicts.] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/tty/tty_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c index 93f9f9dc09fc..823630c69ef5 100644 --- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c @@ -168,7 +168,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size) if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit) return NULL; printk_safe_enter(); - p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC); + p = kmalloc(sizeof(struct tty_buffer) + 2 * size, + GFP_ATOMIC | __GFP_NOWARN); printk_safe_exit(); if (p == NULL) return NULL; -- 2.25.1
2 1
0 0
[PATCH openEuler-1.0-LTS] media: uvcvideo: Fix double free in error path
by Gu Bowen 29 Mar '25

29 Mar '25
From: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> stable inclusion from stable-v6.6.76 commit 6c36dcd662ec5276782838660f8533a7cb26be49 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPBDI CVE: CVE-2024-57980 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c6ef3a7fa97ec823a1e1af9085cf13db9f7b3bac upstream. If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Fixes: a31a4055473b ("V4L/DVB:usbvideo:don't use part of buffer for USB transfer #4") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20241107235130.31372-1-laurent.pinchart@ideasonbo… Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Reviewed by: Ricardo Ribalda <ribalda(a)chromium.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/media/usb/uvc/uvc_status.c [Context conflicts due to commit adfd3910c27fb ("media: uvcvideo: Remove void casting for the status endpoint") not merge.] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/media/usb/uvc/uvc_status.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/usb/uvc/uvc_status.c b/drivers/media/usb/uvc/uvc_status.c index 883e4cab45e7..a353b3c5c03a 100644 --- a/drivers/media/usb/uvc/uvc_status.c +++ b/drivers/media/usb/uvc/uvc_status.c @@ -272,6 +272,7 @@ int uvc_status_init(struct uvc_device *dev) dev->int_urb = usb_alloc_urb(0, GFP_KERNEL); if (dev->int_urb == NULL) { kfree(dev->status); + dev->status = NULL; return -ENOMEM; } -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] net: rose: fix timer races against user threads
by Gu Bowen 29 Mar '25

29 Mar '25
From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.14-rc1 commit 5de7665e0a0746b5ad7943554b34db8f8614a196 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBPBF2 CVE: CVE-2025-21718 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20250122180244.1861468-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- net/rose/rose_timer.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/net/rose/rose_timer.c b/net/rose/rose_timer.c index f06ddbed3fed..1525773e94aa 100644 --- a/net/rose/rose_timer.c +++ b/net/rose/rose_timer.c @@ -122,6 +122,10 @@ static void rose_heartbeat_expiry(struct timer_list *t) struct rose_sock *rose = rose_sk(sk); bh_lock_sock(sk); + if (sock_owned_by_user(sk)) { + sk_reset_timer(sk, &sk->sk_timer, jiffies + HZ/20); + goto out; + } switch (rose->state) { case ROSE_STATE_0: /* Magic here: If we listen() and a new link dies before it @@ -152,6 +156,7 @@ static void rose_heartbeat_expiry(struct timer_list *t) } rose_start_heartbeat(sk); +out: bh_unlock_sock(sk); sock_put(sk); } @@ -162,6 +167,10 @@ static void rose_timer_expiry(struct timer_list *t) struct sock *sk = &rose->sock; bh_lock_sock(sk); + if (sock_owned_by_user(sk)) { + sk_reset_timer(sk, &rose->timer, jiffies + HZ/20); + goto out; + } switch (rose->state) { case ROSE_STATE_1: /* T1 */ case ROSE_STATE_4: /* T2 */ @@ -182,6 +191,7 @@ static void rose_timer_expiry(struct timer_list *t) } break; } +out: bh_unlock_sock(sk); sock_put(sk); } @@ -192,6 +202,10 @@ static void rose_idletimer_expiry(struct timer_list *t) struct sock *sk = &rose->sock; bh_lock_sock(sk); + if (sock_owned_by_user(sk)) { + sk_reset_timer(sk, &rose->idletimer, jiffies + HZ/20); + goto out; + } rose_clear_queues(sk); rose_write_internal(sk, ROSE_CLEAR_REQUEST); @@ -207,6 +221,7 @@ static void rose_idletimer_expiry(struct timer_list *t) sk->sk_state_change(sk); sock_set_flag(sk, SOCK_DEAD); } +out: bh_unlock_sock(sk); sock_put(sk); } -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] media: uvcvideo: Fix double free in error path
by Gu Bowen 29 Mar '25

29 Mar '25
From: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> stable inclusion from stable-v6.6.76 commit 6c36dcd662ec5276782838660f8533a7cb26be49 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBM4S5 CVE: CVE-2024-57980 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c6ef3a7fa97ec823a1e1af9085cf13db9f7b3bac upstream. If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Fixes: a31a4055473b ("V4L/DVB:usbvideo:don't use part of buffer for USB transfer #4") Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20241107235130.31372-1-laurent.pinchart@ideasonbo… Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Reviewed by: Ricardo Ribalda <ribalda(a)chromium.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/media/usb/uvc/uvc_status.c [Context conflicts due to commit adfd3910c27fb ("media: uvcvideo: Remove void casting for the status endpoint") not merge.] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- drivers/media/usb/uvc/uvc_status.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/usb/uvc/uvc_status.c b/drivers/media/usb/uvc/uvc_status.c index 73725051cc16..6edf491dd873 100644 --- a/drivers/media/usb/uvc/uvc_status.c +++ b/drivers/media/usb/uvc/uvc_status.c @@ -269,6 +269,7 @@ int uvc_status_init(struct uvc_device *dev) dev->int_urb = usb_alloc_urb(0, GFP_KERNEL); if (dev->int_urb == NULL) { kfree(dev->status); + dev->status = NULL; return -ENOMEM; } -- 2.25.1
2 1
0 0
[openeuler:OLK-6.6 2064/2064] kismet: WARNING: unmet direct dependencies detected for CRYPTO_DRBG_CTR when selected by CRYPTO_DEV_HISI_TRNG
by kernel test robot 29 Mar '25

29 Mar '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 94d50befec22eea69046e558027594d630edb926 commit: e623afb45e58ded6b45cc4f0ac6c19b3736c96f9 [2064/2064] crypto: hisilicon/trng - support to obtain random numbers from soft algorithm config: arm64-kismet-CONFIG_CRYPTO_DRBG_CTR-CONFIG_CRYPTO_DEV_HISI_TRNG-0-0 (https://download.01.org/0day-ci/archive/20250329/202503290855.eVbc4pVd-lkp@…) reproduce: (https://download.01.org/0day-ci/archive/20250329/202503290855.eVbc4pVd-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/202503290855.eVbc4pVd-lkp@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for CRYPTO_DRBG_CTR when selected by CRYPTO_DEV_HISI_TRNG WARNING: unmet direct dependencies detected for CRYPTO_DRBG_CTR Depends on [n]: CRYPTO [=y] && CRYPTO_DRBG_MENU [=n] Selected by [y]: - CRYPTO_DEV_HISI_TRNG [=y] && CRYPTO [=y] && CRYPTO_HW [=y] && ARM64 [=y] && ACPI [=y] WARNING: unmet direct dependencies detected for PGP_PRELOAD Depends on [n]: CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=n] Selected by [y]: - PGP_PRELOAD_PUBLIC_KEYS [=y] && CRYPTO [=y] WARNING: unmet direct dependencies detected for RESCTRL_FS Depends on [n]: MISC_FILESYSTEMS [=n] && ARCH_HAS_CPU_RESCTRL [=y] Selected by [y]: - ARM64_MPAM [=y] -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 1528/1528] drivers/fpga/dfl.o: warning: objtool: build_info_commit_dev()+0x5b: unreachable instruction
by kernel test robot 29 Mar '25

29 Mar '25
Hi Scott, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4d1e247486ffeef035a5a55a97f2659f68177357 commit: 99e28159a079ea6af5a5b789e83b68240d67f9ff [1528/1528] fpga: dfl: Add lockdep classes for pdata->lock config: x86_64-buildonly-randconfig-006-20250328 (https://download.01.org/0day-ci/archive/20250329/202503290119.FlNWiz0A-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250329/202503290119.FlNWiz0A-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/202503290119.FlNWiz0A-lkp@intel.com/ All warnings (new ones prefixed by >>): drivers/fpga/dfl.c:57: warning: cannot understand function prototype: 'struct dfl_dev_info ' drivers/fpga/dfl.c:77: warning: cannot understand function prototype: 'struct dfl_chardev_info ' >> drivers/fpga/dfl.o: warning: objtool: build_info_commit_dev()+0x5b: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:openEuler-1.0-LTS 1528/1528] drivers/crypto/.tmp_qcom-rng.o: warning: objtool: missing symbol for section .init.text
by kernel test robot 29 Mar '25

29 Mar '25
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4d1e247486ffeef035a5a55a97f2659f68177357 commit: c5f5aeef9b55b362ad5a0e04e4b41cd63b208842 [1528/1528] Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux config: x86_64-buildonly-randconfig-002-20250328 (https://download.01.org/0day-ci/archive/20250328/202503282324.X867QbB6-lkp@…) compiler: clang version 20.1.1 (https://github.com/llvm/llvm-project 424c2d9b7e4de40d0804dd374721e6411c27d1d1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503282324.X867QbB6-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/202503282324.X867QbB6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/crypto/.tmp_qcom-rng.o: warning: objtool: missing symbol for section .init.text -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH openEuler-1.0-LTS] usb: usbip: fix a refcount leak in stub_probe()
by Xia Fukun 28 Mar '25

28 Mar '25
From: Hangyu Hua <hbh25y(a)gmail.com> stable inclusion from stable-v4.19.325 commit 247d3809e45a34d9e1a3a2bb7012e31ed8b46031 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP3SN CVE: CVE-2022-49389 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit… -------------------------------- [ Upstream commit 9ec4cbf1cc55d126759051acfe328d489c5d6e60 ] usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review. Fixes: 3ff67445750a ("usbip: fix error handling in stub_probe()") Reviewed-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Hangyu Hua <hbh25y(a)gmail.com> Link: https://lore.kernel.org/r/20220412020257.9767-1-hbh25y@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/usb/usbip/stub_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c index 93891d445c30..2650ef62757a 100644 --- a/drivers/usb/usbip/stub_dev.c +++ b/drivers/usb/usbip/stub_dev.c @@ -410,7 +410,6 @@ static int stub_probe(struct usb_device *udev) (struct usb_dev_state *) udev); err_port: dev_set_drvdata(&udev->dev, NULL); - usb_put_dev(udev); /* we already have busid_priv, just lock busid_lock */ spin_lock(&busid_priv->busid_lock); @@ -425,6 +424,7 @@ static int stub_probe(struct usb_device *udev) put_busid_priv(busid_priv); sdev_free: + usb_put_dev(udev); stub_device_free(sdev); return rc; -- 2.34.1
2 1
0 0
[openeuler:openEuler-1.0-LTS 1528/1528] include/asm-generic/io.h:742:19: warning: 'reg' may be used uninitialized in this function
by kernel test robot 28 Mar '25

28 Mar '25
tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4d1e247486ffeef035a5a55a97f2659f68177357 commit: e44716ed4262a467260fccb7814e4c89588f438d [1528/1528] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY config: arm64-randconfig-003-20250328 (https://download.01.org/0day-ci/archive/20250328/202503281620.pNXaYE13-lkp@…) compiler: aarch64-linux-gcc (GCC) 10.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250328/202503281620.pNXaYE13-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/202503281620.pNXaYE13-lkp@intel.com/ Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c: In function 'nv40_fifo_dma_engine_init': drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:111:37: warning: 'ctx' may be used uninitialized in this function [-Wmaybe-uninitialized] 111 | nvkm_wo32(imem->ramfc, chan->ramfc + ctx, inst); | ^ In file included from arch/arm64/include/asm/io.h:213, from include/linux/io.h:25, from include/linux/pci.h:34, from drivers/gpu/drm/nouveau/include/nvif/os.h:8, from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3, from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/engine.h:5, from drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h:4, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv04.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:24: >> include/asm-generic/io.h:742:19: warning: 'reg' may be used uninitialized in this function [-Wmaybe-uninitialized] 742 | #define iowrite32 iowrite32 | ^~~~~~~~~ drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:97:12: note: 'reg' was declared here 97 | u32 inst, reg, ctx; | ^~~ drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c: In function 'nv40_fifo_dma_engine_fini': drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:80:37: warning: 'ctx' may be used uninitialized in this function [-Wmaybe-uninitialized] 80 | nvkm_wo32(imem->ramfc, chan->ramfc + ctx, 0x00000000); | ^ In file included from arch/arm64/include/asm/io.h:213, from include/linux/io.h:25, from include/linux/pci.h:34, from drivers/gpu/drm/nouveau/include/nvif/os.h:8, from drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3, from drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4, from drivers/gpu/drm/nouveau/include/nvkm/core/engine.h:5, from drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h:4, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv04.h:5, from drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:24: >> include/asm-generic/io.h:742:19: warning: 'reg' may be used uninitialized in this function [-Wmaybe-uninitialized] 742 | #define iowrite32 iowrite32 | ^~~~~~~~~ drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.c:67:6: note: 'reg' was declared here 67 | u32 reg, ctx; | ^~~ vim +/reg +742 include/asm-generic/io.h 9216efafc52ff9 Thierry Reding 2014-10-01 740 9216efafc52ff9 Thierry Reding 2014-10-01 741 #ifndef iowrite32 9216efafc52ff9 Thierry Reding 2014-10-01 @742 #define iowrite32 iowrite32 9216efafc52ff9 Thierry Reding 2014-10-01 743 static inline void iowrite32(u32 value, volatile void __iomem *addr) 9216efafc52ff9 Thierry Reding 2014-10-01 744 { 9216efafc52ff9 Thierry Reding 2014-10-01 745 writel(value, addr); 9216efafc52ff9 Thierry Reding 2014-10-01 746 } 9216efafc52ff9 Thierry Reding 2014-10-01 747 #endif 9216efafc52ff9 Thierry Reding 2014-10-01 748 :::::: The code at line 742 was first introduced by commit :::::: 9216efafc52ff99e9351ef60de5fcafc2bc8adb6 asm-generic/io.h: Reconcile I/O accessor overrides :::::: TO: Thierry Reding <treding(a)nvidia.com> :::::: CC: Thierry Reding <treding(a)nvidia.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH openEuler-1.0-LTS] drivers: usb: host: Fix deadlock in oxu_bus_suspend()
by Xia Fukun 28 Mar '25

28 Mar '25
From: Duoming Zhou <duoming(a)zju.edu.cn> stable inclusion from stable-v4.19.247 commit f8242044c91cafbba9e320b0fb31abf2429a3221 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP3Z3 CVE: CVE-2022-49313 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4d378f2ae58138d4c55684e1d274e7dd94aa6524 ] There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/usb/host/oxu210hp-hcd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c index c5e6e8d0b5ef..0402fa3b1ea2 100644 --- a/drivers/usb/host/oxu210hp-hcd.c +++ b/drivers/usb/host/oxu210hp-hcd.c @@ -3476,8 +3476,10 @@ static int oxu_bus_suspend(struct usb_hcd *hcd) } } + spin_unlock_irq(&oxu->lock); /* turn off now-idle HC */ del_timer_sync(&oxu->watchdog); + spin_lock_irq(&oxu->lock); ehci_halt(oxu); hcd->state = HC_STATE_SUSPENDED; -- 2.34.1
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • ...
  • 2027
  • Older →

HyperKitty Powered by HyperKitty