Skip to content

K
Kernel

openeuler / Kernel
9 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 15 8月, 2023 1 次提交
  3. 14 8月, 2023 9 次提交
  5. 10 8月, 2023 1 次提交
  7. 09 8月, 2023 1 次提交
    • L
      xfrm: add NULL check in xfrm_update_ae_params · 6f03ab1c
      由 Lin Ma 提交于 
      mainline inclusion
from mainline-v6.5-rc3
commit 00374d9b6d9f932802b55181be9831aa948e5b7c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NYWN
CVE: CVE-2023-3772

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00374d9b6d9f932802b55181be9831aa948e5b7c

--------------------------------

Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_ae_params(...) is okay to update them. However, the current
implementation of xfrm_new_ae(...) allows a malicious user to directly
dereference a NULL pointer and crash the kernel like below.

BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774d #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
RIP: 0010:memcpy_orig+0xad/0x140
Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c
RSP: 0018:ffff888008f57658 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571
RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818
R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000
FS:  00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 ? __die+0x1f/0x70
 ? page_fault_oops+0x1e8/0x500
 ? __pfx_is_prefetch.constprop.0+0x10/0x10
 ? __pfx_page_fault_oops+0x10/0x10
 ? _raw_spin_unlock_irqrestore+0x11/0x40
 ? fixup_exception+0x36/0x460
 ? _raw_spin_unlock_irqrestore+0x11/0x40
 ? exc_page_fault+0x5e/0xc0
 ? asm_exc_page_fault+0x26/0x30
 ? xfrm_update_ae_params+0xd1/0x260
 ? memcpy_orig+0xad/0x140
 ? __pfx__raw_spin_lock_bh+0x10/0x10
 xfrm_update_ae_params+0xe7/0x260
 xfrm_new_ae+0x298/0x4e0
 ? __pfx_xfrm_new_ae+0x10/0x10
 ? __pfx_xfrm_new_ae+0x10/0x10
 xfrm_user_rcv_msg+0x25a/0x410
 ? __pfx_xfrm_user_rcv_msg+0x10/0x10
 ? __alloc_skb+0xcf/0x210
 ? stack_trace_save+0x90/0xd0
 ? filter_irq_stacks+0x1c/0x70
 ? __stack_depot_save+0x39/0x4e0
 ? __kasan_slab_free+0x10a/0x190
 ? kmem_cache_free+0x9c/0x340
 ? netlink_recvmsg+0x23c/0x660
 ? sock_recvmsg+0xeb/0xf0
 ? __sys_recvfrom+0x13c/0x1f0
 ? __x64_sys_recvfrom+0x71/0x90
 ? do_syscall_64+0x3f/0x90
 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
 ? copyout+0x3e/0x50
 netlink_rcv_skb+0xd6/0x210
 ? __pfx_xfrm_user_rcv_msg+0x10/0x10
 ? __pfx_netlink_rcv_skb+0x10/0x10
 ? __pfx_sock_has_perm+0x10/0x10
 ? mutex_lock+0x8d/0xe0
 ? __pfx_mutex_lock+0x10/0x10
 xfrm_netlink_rcv+0x44/0x50
 netlink_unicast+0x36f/0x4c0
 ? __pfx_netlink_unicast+0x10/0x10
 ? netlink_recvmsg+0x500/0x660
 netlink_sendmsg+0x3b7/0x700

This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit
adds additional NULL check in xfrm_update_ae_params to fix the NPD.

Fixes: d8647b79 ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: NLin Ma <linma@zju.edu.cn>
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

Conflicts:
	net/xfrm/xfrm_user.c
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
      6f03ab1c
  9. 08 8月, 2023 18 次提交
  11. 07 8月, 2023 8 次提交
    • O
      !1663 tty: fix pid memleak in disassociate_ctty() · 5b5909d1
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ci-robot 
 
PR sync from: Yi Yang <yiyang13@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/FA2B7TOM3KI377VPITPMUXX6FWMNJ2NK/ 
 
https://gitee.com/openeuler/kernel/issues/I7PBYJ 
 
Link:https://gitee.com/openeuler/kernel/pulls/1663 

Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
      5b5909d1
    • J
      sched: disable sched_autogroup by default · cdf0d0cd
      由 Jialin Zhang 提交于 
      hulk inclusion
category: performance
bugzilla: 32059, https://gitee.com/openeuler/kernel/issues/I65DOZ
CVE: NA

--------------------------------

This option optimizes the scheduler for common desktop workloads by
automatically creating and populating task groups.  This separation
of workloads isolates aggressive CPU burners (like build jobs) from
desktop applications.  Task group autogeneration is currently based
upon task session.

We do not need this for mostly server workloads, so just disable by
default. If you need this feature really, just enable it by sysctl:

sysctl -w kernel.sched_autogroup_enabled=1
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      cdf0d0cd
    • Y
      tty: fix pid memleak in disassociate_ctty() · a2aa6b07
      由 Yi Yang 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7PBYJ

--------------------------------

There is memleak in alloc_pid:
------------------------------
unreferenced object 0xffff88810c181940 (size 224):
  comm "sshd", pid 8191, jiffies 4294946950 (age 524.570s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de  .............N..
    ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff  ....kkkk........
  backtrace:
    [<ffffffff814774e6>] kmem_cache_alloc+0x5c6/0x9b0
    [<ffffffff81177342>] alloc_pid+0x72/0x570
    [<ffffffff81140ac4>] copy_process+0x1374/0x2470
    [<ffffffff81141d77>] kernel_clone+0xb7/0x900
    [<ffffffff81142645>] __se_sys_clone+0x85/0xb0
    [<ffffffff8114269b>] __x64_sys_clone+0x2b/0x30
    [<ffffffff83965a72>] do_syscall_64+0x32/0x80
    [<ffffffff83a00085>] entry_SYSCALL_64_after_hwframe+0x61/0xc6

The pid memleak is triggered by the following race:
task[sshd]                      task[bash]
-----------------------		-----------------------
				do_exit();
				disassociate_ctty();
				spin_lock_irq(¤t->sighand->siglock);
				put_pid(current->signal->tty_old_pgrp);
				current->signal->tty_old_pgrp = NULL;
				tty = tty_kref_get(current->signal->tty);
				//tty is not NULL
				spin_unlock_irq(¤t->sighand->siglock);
tty_vhangup();
tty_lock(tty);
...
tty_signal_session_leader();
spin_lock_irq(&p->sighand->siglock);
...
p->signal->tty_old_pgrp = get_pid(tty->pgrp); // tty_old_pgrp reassign
spin_unlock_irq(&p->sighand->siglock);
...
tty_unlock(tty);
				if (tty) {
				    tty_lock(tty);
				    ...
				    put_pid(tty->pgrp);
				    tty->pgrp = NULL;// It's too late
				    ...
				    tty_unlock(tty);
				}

in task[bash], tty_old_pgrp is released by disassociate_ctty(), then it's
reassigned by tty_signal_session_leader() in task[sshd], cause memleak.

fix the memleak by add put_pid() in disassociate_ctty() after tty_old_pgrp
is reassigned.

Fixes: c8bcd9c5 ("tty: Fix ->session locking")
Signed-off-by: NYi Yang <yiyang13@huawei.com>
      a2aa6b07
    • D
      media: usb: siano: Fix warning due to null work_func_t function pointer · a1f80798
      由 Duoming Zhou 提交于 
      mainline inclusion
from mainline-v6.5-rc1
commit 6f489a966fbeb0da63d45c2c66a8957eab604bf6
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7QE3A
CVE: CVE-2023-4132

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f489a966fbeb0da63d45c2c66a8957eab604bf6

--------------------------------

The previous commit ebad8e73 ("media: usb: siano: Fix use after
free bugs caused by do_submit_urb") adds cancel_work_sync() in
smsusb_stop_streaming(). But smsusb_stop_streaming() may be called,
even if the work_struct surb->wq has not been initialized. As a result,
the warning will occur. One of the processes that could lead to warning
is shown below:

smsusb_probe()
  smsusb_init_device()
    if (!dev->in_ep || !dev->out_ep || align < 0) {
         smsusb_term_device(intf);
           smsusb_stop_streaming()
             cancel_work_sync(&dev->surbs[i].wq);
               __cancel_work_timer()
                 __flush_work()
                   if (WARN_ON(!work->func)) // work->func is null

The log reported by syzbot is shown below:

WARNING: CPU: 0 PID: 897 at kernel/workqueue.c:3066 __flush_work+0x798/0xa80 kernel/workqueue.c:3063
Modules linked in:
CPU: 0 PID: 897 Comm: kworker/0:2 Not tainted 6.2.0-rc1-syzkaller #0
RIP: 0010:__flush_work+0x798/0xa80 kernel/workqueue.c:3066
...
RSP: 0018:ffffc9000464ebf8 EFLAGS: 00010246
RAX: 1ffff11002dbb420 RBX: 0000000000000021 RCX: 1ffffffff204fa4e
RDX: dffffc0000000000 RSI: 0000000000000001 RDI: ffff888016dda0e8
RBP: ffffc9000464ed98 R08: 0000000000000001 R09: ffffffff90253b2f
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888016dda0e8
R13: ffff888016dda0e8 R14: ffff888016dda100 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd4331efe8 CR3: 000000000b48e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 __cancel_work_timer+0x315/0x460 kernel/workqueue.c:3160
 smsusb_stop_streaming drivers/media/usb/siano/smsusb.c:182 [inline]
 smsusb_term_device+0xda/0x2d0 drivers/media/usb/siano/smsusb.c:344
 smsusb_init_device+0x400/0x9ce drivers/media/usb/siano/smsusb.c:419
 smsusb_probe+0xbbd/0xc55 drivers/media/usb/siano/smsusb.c:567
...

This patch adds check before cancel_work_sync(). If surb->wq has not
been initialized, the cancel_work_sync() will not be executed.

Reported-by: syzbot+27b0b464864741b18b99@syzkaller.appspotmail.com
Fixes: ebad8e73 ("media: usb: siano: Fix use after free bugs caused by do_submit_urb")
Signed-off-by: NDuoming Zhou <duoming@zju.edu.cn>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NRuan Jinjie <ruanjinjie@huawei.com>
      a1f80798
    • D
      media: usb: siano: Fix use after free bugs caused by do_submit_urb · b7579ce4
      由 Duoming Zhou 提交于 
      mainline inclusion
from mainline-v6.3-rc1
commit ebad8e73
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7QE3A
CVE: CVE-2023-4132

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebad8e731c1c06adf04621d6fd327b860c0861b5

--------------------------------

There are UAF bugs caused by do_submit_urb(). One of the KASan reports
is shown below:

[   36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890
[   36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49
[   36.408316]
[   36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237a-dir8
[   36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584
[   36.416157] Workqueue:  0x0 (events)
[   36.417654] Call Trace:
[   36.418546]  <TASK>
[   36.419320]  dump_stack_lvl+0x96/0xd0
[   36.420522]  print_address_description+0x75/0x350
[   36.421992]  print_report+0x11b/0x250
[   36.423174]  ? _raw_spin_lock_irqsave+0x87/0xd0
[   36.424806]  ? __virt_addr_valid+0xcf/0x170
[   36.426069]  ? worker_thread+0x4a2/0x890
[   36.427355]  kasan_report+0x131/0x160
[   36.428556]  ? worker_thread+0x4a2/0x890
[   36.430053]  worker_thread+0x4a2/0x890
[   36.431297]  ? worker_clr_flags+0x90/0x90
[   36.432479]  kthread+0x166/0x190
[   36.433493]  ? kthread_blkcg+0x50/0x50
[   36.434669]  ret_from_fork+0x22/0x30
[   36.435923]  </TASK>
[   36.436684]
[   36.437215] Allocated by task 24:
[   36.438289]  kasan_set_track+0x50/0x80
[   36.439436]  __kasan_kmalloc+0x89/0xa0
[   36.440566]  smsusb_probe+0x374/0xc90
[   36.441920]  usb_probe_interface+0x2d1/0x4c0
[   36.443253]  really_probe+0x1d5/0x580
[   36.444539]  __driver_probe_device+0xe3/0x130
[   36.446085]  driver_probe_device+0x49/0x220
[   36.447423]  __device_attach_driver+0x19e/0x1b0
[   36.448931]  bus_for_each_drv+0xcb/0x110
[   36.450217]  __device_attach+0x132/0x1f0
[   36.451470]  bus_probe_device+0x59/0xf0
[   36.452563]  device_add+0x4ec/0x7b0
[   36.453830]  usb_set_configuration+0xc63/0xe10
[   36.455230]  usb_generic_driver_probe+0x3b/0x80
[   36.456166] printk: console [ttyGS0] disabled
[   36.456569]  usb_probe_device+0x90/0x110
[   36.459523]  really_probe+0x1d5/0x580
[   36.461027]  __driver_probe_device+0xe3/0x130
[   36.462465]  driver_probe_device+0x49/0x220
[   36.463847]  __device_attach_driver+0x19e/0x1b0
[   36.465229]  bus_for_each_drv+0xcb/0x110
[   36.466466]  __device_attach+0x132/0x1f0
[   36.467799]  bus_probe_device+0x59/0xf0
[   36.469010]  device_add+0x4ec/0x7b0
[   36.470125]  usb_new_device+0x863/0xa00
[   36.471374]  hub_event+0x18c7/0x2220
[   36.472746]  process_one_work+0x34c/0x5b0
[   36.474041]  worker_thread+0x4b7/0x890
[   36.475216]  kthread+0x166/0x190
[   36.476267]  ret_from_fork+0x22/0x30
[   36.477447]
[   36.478160] Freed by task 24:
[   36.479239]  kasan_set_track+0x50/0x80
[   36.480512]  kasan_save_free_info+0x2b/0x40
[   36.481808]  ____kasan_slab_free+0x122/0x1a0
[   36.483173]  __kmem_cache_free+0xc4/0x200
[   36.484563]  smsusb_term_device+0xcd/0xf0
[   36.485896]  smsusb_probe+0xc85/0xc90
[   36.486976]  usb_probe_interface+0x2d1/0x4c0
[   36.488303]  really_probe+0x1d5/0x580
[   36.489498]  __driver_probe_device+0xe3/0x130
[   36.491140]  driver_probe_device+0x49/0x220
[   36.492475]  __device_attach_driver+0x19e/0x1b0
[   36.493988]  bus_for_each_drv+0xcb/0x110
[   36.495171]  __device_attach+0x132/0x1f0
[   36.496617]  bus_probe_device+0x59/0xf0
[   36.497875]  device_add+0x4ec/0x7b0
[   36.498972]  usb_set_configuration+0xc63/0xe10
[   36.500264]  usb_generic_driver_probe+0x3b/0x80
[   36.501740]  usb_probe_device+0x90/0x110
[   36.503084]  really_probe+0x1d5/0x580
[   36.504241]  __driver_probe_device+0xe3/0x130
[   36.505548]  driver_probe_device+0x49/0x220
[   36.506766]  __device_attach_driver+0x19e/0x1b0
[   36.508368]  bus_for_each_drv+0xcb/0x110
[   36.509646]  __device_attach+0x132/0x1f0
[   36.510911]  bus_probe_device+0x59/0xf0
[   36.512103]  device_add+0x4ec/0x7b0
[   36.513215]  usb_new_device+0x863/0xa00
[   36.514736]  hub_event+0x18c7/0x2220
[   36.516130]  process_one_work+0x34c/0x5b0
[   36.517396]  worker_thread+0x4b7/0x890
[   36.518591]  kthread+0x166/0x190
[   36.519599]  ret_from_fork+0x22/0x30
[   36.520851]
[   36.521405] Last potentially related work creation:
[   36.523143]  kasan_save_stack+0x3f/0x60
[   36.524275]  kasan_record_aux_stack_noalloc+0x9d/0xb0
[   36.525831]  insert_work+0x25/0x130
[   36.527039]  __queue_work+0x4d4/0x620
[   36.528236]  queue_work_on+0x72/0xb0
[   36.529344]  __usb_hcd_giveback_urb+0x13f/0x1b0
[   36.530819]  dummy_timer+0x350/0x1a40
[   36.532149]  call_timer_fn+0x2c/0x190
[   36.533567]  expire_timers+0x69/0x1f0
[   36.534736]  __run_timers+0x289/0x2d0
[   36.535841]  run_timer_softirq+0x2d/0x60
[   36.537110]  __do_softirq+0x116/0x380
[   36.538377]
[   36.538950] Second to last potentially related work creation:
[   36.540855]  kasan_save_stack+0x3f/0x60
[   36.542084]  kasan_record_aux_stack_noalloc+0x9d/0xb0
[   36.543592]  insert_work+0x25/0x130
[   36.544891]  __queue_work+0x4d4/0x620
[   36.546168]  queue_work_on+0x72/0xb0
[   36.547328]  __usb_hcd_giveback_urb+0x13f/0x1b0
[   36.548805]  dummy_timer+0x350/0x1a40
[   36.550116]  call_timer_fn+0x2c/0x190
[   36.551570]  expire_timers+0x69/0x1f0
[   36.552762]  __run_timers+0x289/0x2d0
[   36.553916]  run_timer_softirq+0x2d/0x60
[   36.555118]  __do_softirq+0x116/0x380
[   36.556239]
[   36.556807] The buggy address belongs to the object at ffff888005960000
[   36.556807]  which belongs to the cache kmalloc-4k of size 4096
[   36.560652] The buggy address is located 232 bytes inside of
[   36.560652]  4096-byte region [ffff888005960000, ffff888005961000)
[   36.564791]
[   36.565355] The buggy address belongs to the physical page:
[   36.567212] page:000000004f0a0731 refcount:1 mapcount:0 mapping:0000000000000000 index:0x00
[   36.570534] head:000000004f0a0731 order:3 compound_mapcount:0 subpages_mapcount:0 compound0
[   36.573717] flags: 0x100000000010200(slab|head|node=0|zone=1)
[   36.575481] raw: 0100000000010200 ffff888001042140 dead000000000122 0000000000000000
[   36.577842] raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
[   36.580175] page dumped because: kasan: bad access detected
[   36.581994]
[   36.582548] Memory state around the buggy address:
[   36.583983]  ffff88800595ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   36.586240]  ffff888005960000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   36.588884] >ffff888005960080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   36.591071]                                                           ^
[   36.593295]  ffff888005960100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   36.595705]  ffff888005960180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   36.598026] ==================================================================
[   36.600224] Disabling lock debugging due to kernel taint
[   36.602681] general protection fault, probably for non-canonical address 0x43600a000000060I
[   36.607129] CPU: 0 PID: 49 Comm: kworker/0:2 Tainted: G    B              6.2.0-rc3-15798-8
[   36.611115] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584
[   36.615026] Workqueue: events do_submit_urb
[   36.616290] RIP: 0010:_raw_spin_lock_irqsave+0x8a/0xd0
[   36.618107] Code: 24 00 00 00 00 48 89 df be 04 00 00 00 e8 9e b5 c6 fe 48 89 ef be 04 00 5
[   36.623522] RSP: 0018:ffff888004b6fcf0 EFLAGS: 00010046
[   36.625072] RAX: 0000000000000000 RBX: 043600a000000060 RCX: ffffffff9fc0e0d7
[   36.627206] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff888004b6fcf0
[   36.629813] RBP: ffff888004b6fcf0 R08: dffffc0000000000 R09: ffffed100096df9f
[   36.631974] R10: dfffe9100096dfa0 R11: 1ffff1100096df9e R12: ffff888005960020
[   36.634285] R13: ffff8880059600f0 R14: 0000000000000246 R15: 0000000000000001
[   36.636438] FS:  0000000000000000(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
[   36.639092] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   36.640951] CR2: 00007f07476819a3 CR3: 0000000004a34000 CR4: 00000000000006f0
[   36.643411] Call Trace:
[   36.644215]  <TASK>
[   36.644902]  smscore_getbuffer+0x3e/0x1e0
[   36.646147]  do_submit_urb+0x4f/0x190
[   36.647449]  process_one_work+0x34c/0x5b0
[   36.648777]  worker_thread+0x4b7/0x890
[   36.649984]  ? worker_clr_flags+0x90/0x90
[   36.651166]  kthread+0x166/0x190
[   36.652151]  ? kthread_blkcg+0x50/0x50
[   36.653547]  ret_from_fork+0x22/0x30
[   36.655051]  </TASK>
[   36.655733] Modules linked in:
[   36.656787] ---[ end trace 0000000000000000 ]---
[   36.658328] RIP: 0010:_raw_spin_lock_irqsave+0x8a/0xd0
[   36.660045] Code: 24 00 00 00 00 48 89 df be 04 00 00 00 e8 9e b5 c6 fe 48 89 ef be 04 00 5
[   36.665730] RSP: 0018:ffff888004b6fcf0 EFLAGS: 00010046
[   36.667448] RAX: 0000000000000000 RBX: 043600a000000060 RCX: ffffffff9fc0e0d7
[   36.669675] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff888004b6fcf0
[   36.672645] RBP: ffff888004b6fcf0 R08: dffffc0000000000 R09: ffffed100096df9f
[   36.674921] R10: dfffe9100096dfa0 R11: 1ffff1100096df9e R12: ffff888005960020
[   36.677034] R13: ffff8880059600f0 R14: 0000000000000246 R15: 0000000000000001
[   36.679184] FS:  0000000000000000(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
[   36.681655] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   36.683383] CR2: 00007f07476819a3 CR3: 0000000004a34000 CR4: 00000000000006f0
[   36.685733] Kernel panic - not syncing: Fatal exception
[   36.688585] Kernel Offset: 0x1d400000 from 0xffffffff81000000 (relocation range: 0xfffffff)
[   36.692199] ---[ end Kernel panic - not syncing: Fatal exception ]---

When the siano device is plugged in, it may call the following functions
to initialize the device.

smsusb_probe()-->smsusb_init_device()-->smscore_start_device().

When smscore_start_device() gets failed, the function smsusb_term_device()
will be called and smsusb_device_t will be deallocated. Although we use
usb_kill_urb() in smsusb_stop_streaming() to cancel transfer requests
and wait for them to finish, the worker threads that are scheduled by
smsusb_onresponse() may be still running. As a result, the UAF bugs
could happen.

We add cancel_work_sync() in smsusb_stop_streaming() in order that the
worker threads could finish before the smsusb_device_t is deallocated.

Fixes: dd47fbd4 ("[media] smsusb: don't sleep while atomic")
Signed-off-by: NDuoming Zhou <duoming@zju.edu.cn>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NRuan Jinjie <ruanjinjie@huawei.com>
      b7579ce4
    • O
      !1629 can: raw: fix receiver memory leak · d636f566
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ci-robot 
 
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PN6CJX7CQ6YCEZFFWSQPDTGBGIIF7PGE/ 
Backport can/raw receiver memory leak fix commits.

Eric Dumazet (1):
  can: raw: fix lockdep issue in raw_release()

Ziyang Xuan (1):
  can: raw: fix receiver memory leak


-- 
2.25.1
 
https://gitee.com/openeuler/kernel/issues/I7PM10 
 
Link:https://gitee.com/openeuler/kernel/pulls/1629 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
      d636f566
    • O
      !1655 can: bcm: Fix UAF in bcm_proc_show() · c28ee72a
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ci-robot 
 
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7EQSQN64OKQD5VUXFEKT6K4XAFZ52LBI/ 
 
https://gitee.com/openeuler/kernel/issues/I7R1N4 
 
Link:https://gitee.com/openeuler/kernel/pulls/1655 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com>
      c28ee72a
    • Y
      can: bcm: Fix UAF in bcm_proc_show() · c1aa7aa1
      由 YueHaibing 提交于 
      mainline inclusion
from mainline-v6.5-rc1
commit 55c3b96074f3f9b0aee19bf93cd71af7516582bb
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7R1N4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=55c3b96074f3f9b0aee19bf93cd71af7516582bb

---------------------------

BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80
Read of size 8 at addr ffff888155846230 by task cat/7862

CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xd5/0x150
 print_report+0xc1/0x5e0
 kasan_report+0xba/0xf0
 bcm_proc_show+0x969/0xa80
 seq_read_iter+0x4f6/0x1260
 seq_read+0x165/0x210
 proc_reg_read+0x227/0x300
 vfs_read+0x1d5/0x8d0
 ksys_read+0x11e/0x240
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Allocated by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 __kasan_kmalloc+0x9e/0xa0
 bcm_sendmsg+0x264b/0x44e0
 sock_sendmsg+0xda/0x180
 ____sys_sendmsg+0x735/0x920
 ___sys_sendmsg+0x11d/0x1b0
 __sys_sendmsg+0xfa/0x1d0
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 7846:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x27/0x40
 ____kasan_slab_free+0x161/0x1c0
 slab_free_freelist_hook+0x119/0x220
 __kmem_cache_free+0xb4/0x2e0
 rcu_core+0x809/0x1bd0

bcm_op is freed before procfs entry be removed in bcm_release(),
this lead to bcm_proc_show() may read the freed bcm_op.

Fixes: ffd980f9 ("[CAN]: Add broadcast manager (bcm) protocol")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net>
Acked-by: NOliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/all/20230715092543.15548-1-yuehaibing@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
      c1aa7aa1
  13. 03 8月, 2023 2 次提交
    • E
      can: raw: fix lockdep issue in raw_release() · ad3aec46
      由 Eric Dumazet 提交于 
      mainline inclusion
from mainline-v6.5-rc4
commit 11c9027c983e9e4b408ee5613b6504d24ebd85be
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7PM10
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11c9027c983e9e4b408ee5613b6504d24ebd85be

---------------------------

syzbot complained about a lockdep issue [1]

Since raw_bind() and raw_setsockopt() first get RTNL
before locking the socket, we must adopt the same order in raw_release()

[1]
WARNING: possible circular locking dependency detected
6.5.0-rc1-syzkaller-00192-g78adb4bcf99e #0 Not tainted
------------------------------------------------------
syz-executor.0/14110 is trying to acquire lock:
ffff88804e4b6130 (sk_lock-AF_CAN){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1708 [inline]
ffff88804e4b6130 (sk_lock-AF_CAN){+.+.}-{0:0}, at: raw_bind+0xb1/0xab0 net/can/raw.c:435

but task is already holding lock:
ffffffff8e3df368 (rtnl_mutex){+.+.}-{3:3}, at: raw_bind+0xa7/0xab0 net/can/raw.c:434

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (rtnl_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x181/0x1340 kernel/locking/mutex.c:747
raw_release+0x1c6/0x9b0 net/can/raw.c:391
__sock_release+0xcd/0x290 net/socket.c:654
sock_close+0x1c/0x20 net/socket.c:1386
__fput+0x3fd/0xac0 fs/file_table.c:384
task_work_run+0x14d/0x240 kernel/task_work.c:179
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204
__syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:297
do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd

-> #0 (sk_lock-AF_CAN){+.+.}-{0:0}:
check_prev_add kernel/locking/lockdep.c:3142 [inline]
check_prevs_add kernel/locking/lockdep.c:3261 [inline]
validate_chain kernel/locking/lockdep.c:3876 [inline]
__lock_acquire+0x2e3d/0x5de0 kernel/locking/lockdep.c:5144
lock_acquire kernel/locking/lockdep.c:5761 [inline]
lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726
lock_sock_nested+0x3a/0xf0 net/core/sock.c:3492
lock_sock include/net/sock.h:1708 [inline]
raw_bind+0xb1/0xab0 net/can/raw.c:435
__sys_bind+0x1ec/0x220 net/socket.c:1792
__do_sys_bind net/socket.c:1803 [inline]
__se_sys_bind net/socket.c:1801 [inline]
__x64_sys_bind+0x72/0xb0 net/socket.c:1801
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(rtnl_mutex);
        lock(sk_lock-AF_CAN);
        lock(rtnl_mutex);
lock(sk_lock-AF_CAN);

*** DEADLOCK ***

1 lock held by syz-executor.0/14110:

stack backtrace:
CPU: 0 PID: 14110 Comm: syz-executor.0 Not tainted 6.5.0-rc1-syzkaller-00192-g78adb4bcf99e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
check_noncircular+0x311/0x3f0 kernel/locking/lockdep.c:2195
check_prev_add kernel/locking/lockdep.c:3142 [inline]
check_prevs_add kernel/locking/lockdep.c:3261 [inline]
validate_chain kernel/locking/lockdep.c:3876 [inline]
__lock_acquire+0x2e3d/0x5de0 kernel/locking/lockdep.c:5144
lock_acquire kernel/locking/lockdep.c:5761 [inline]
lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726
lock_sock_nested+0x3a/0xf0 net/core/sock.c:3492
lock_sock include/net/sock.h:1708 [inline]
raw_bind+0xb1/0xab0 net/can/raw.c:435
__sys_bind+0x1ec/0x220 net/socket.c:1792
__do_sys_bind net/socket.c:1803 [inline]
__se_sys_bind net/socket.c:1801 [inline]
__x64_sys_bind+0x72/0xb0 net/socket.c:1801
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd89007cb29
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd890d2a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000031
RAX: ffffffffffffffda RBX: 00007fd89019bf80 RCX: 00007fd89007cb29
RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007fd8900c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd89019bf80 R15: 00007ffebf8124f8
</TASK>

Fixes: ee8b94c8510c ("can: raw: fix receiver memory leak")
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Cc: Ziyang Xuan <william.xuanziyang@huawei.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: stable@vger.kernel.org
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/all/20230720114438.172434-1-edumazet@google.comSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      ad3aec46
    • Z
      can: raw: fix receiver memory leak · 0a239ea3
      由 Ziyang Xuan 提交于 
      mainline inclusion
from mainline-v6.5-rc3
commit ee8b94c8510ce64afe0b87ef548d23e00915fb10
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7PM10
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee8b94c8510ce64afe0b87ef548d23e00915fb10

---------------------------

Got kmemleak errors with the following ltp can_filter testcase:

for ((i=1; i<=100; i++))
do
        ./can_filter &
        sleep 0.1
done

==============================================================
[<00000000db4a4943>] can_rx_register+0x147/0x360 [can]
[<00000000a289549d>] raw_setsockopt+0x5ef/0x853 [can_raw]
[<000000006d3d9ebd>] __sys_setsockopt+0x173/0x2c0
[<00000000407dbfec>] __x64_sys_setsockopt+0x61/0x70
[<00000000fd468496>] do_syscall_64+0x33/0x40
[<00000000b7e47d51>] entry_SYSCALL_64_after_hwframe+0x61/0xc6

It's a bug in the concurrent scenario of unregister_netdevice_many()
and raw_release() as following:

             cpu0                                        cpu1
unregister_netdevice_many(can_dev)
  unlist_netdevice(can_dev) // dev_get_by_index() return NULL after this
  net_set_todo(can_dev)
						raw_release(can_socket)
						  dev = dev_get_by_index(, ro->ifindex); // dev == NULL
						  if (dev) { // receivers in dev_rcv_lists not free because dev is NULL
						    raw_disable_allfilters(, dev, );
						    dev_put(dev);
						  }
						  ...
						  ro->bound = 0;
						  ...

call_netdevice_notifiers(NETDEV_UNREGISTER, )
  raw_notify(, NETDEV_UNREGISTER, )
    if (ro->bound) // invalid because ro->bound has been set 0
      raw_disable_allfilters(, dev, ); // receivers in dev_rcv_lists will never be freed

Add a net_device pointer member in struct raw_sock to record bound
can_dev, and use rtnl_lock to serialize raw_socket members between
raw_bind(), raw_release(), raw_setsockopt() and raw_notify(). Use
ro->dev to decide whether to free receivers in dev_rcv_lists.

Fixes: 8d0caedb ("can: bcm/raw/isotp: use per module netdevice notifier")
Reviewed-by: NOliver Hartkopp <socketcan@hartkopp.net>
Acked-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Link: https://lore.kernel.org/all/20230711011737.1969582-1-william.xuanziyang@huawei.com
Cc: stable@vger.kernel.org
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Conflicts:
	net/can/raw.c
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
      0a239ea3