Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2023 5 次提交
    • L
      block/badblocks: fix the bug of reverse order · b36ddbdb
      由 Li Nan 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6ZG5B
CVE: NA

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

Order of badblocks will be reversed if we set a large area at once. 'hi'
remains unchanged while adding continuous badblocks is wrong, the next
setting is greater than 'hi', it should be added to the next position.
Let 'hi' +1 each cycle.

  # echo 0 2048 > bad_blocks
  # cat bad_blocks
    1536 512
    1024 512
    512 512
    0 512

Fixes: 9e0e252a ("badblocks: Add core badblock management code")
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      b36ddbdb
    • L
      block: Only set bb->changed when badblocks changes · efa964ee
      由 Li Nan 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6ZG5B
CVE: NA

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

bb->changed and unacked_exist is set and badblocks_update_acked() is
involked even if no badblocks changes in badblocks_set(). Only update
them when badblocks changes.

Fixes: 9e0e252a ("badblocks: Add core badblock management code")
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      efa964ee
    • L
      md: fix sysfs duplicate file while adding rdev · 4f5666c8
      由 Li Nan 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188553, https://gitee.com/openeuler/kernel/issues/I6TNFX
CVE: NA

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

rdev->del_work has not been queued to md_rdev_misc_wq and flush_workqueue
will not flush it if tow threads add and remove same device. sysfs might
WARN duplicate filename as below.

    //T1	             //T2
    mdadm write super
			     add success
			     remove
			      unbind_rdev_from_array

    md_ioctl
     flush_workqueue
			      INIT_WORK
                               queue_work
     md_add_new_disk
      duplicate filename dev-xxx

Check if there is any kobj with the same name, and return busy if true.

Fixes: 5792a285 ("md: avoid a deadlock when removing a device from an md array via sysfs")
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      4f5666c8
    • L
      md: replace invalid function flush_rdev_wq() with flush_workqueue() · 52e332f2
      由 Li Nan 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188553, https://gitee.com/openeuler/kernel/issues/I6TNFX
CVE: NA

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

If we want to remove a device, first we delete it from mddev->disks list,
then init rdev->del_work to put it (see unbind_rdev_from_array()).

flush_rdev_wq() traverses mddev->disks to check if there is any pending
rdev->del_work, if so, flush it. Howerver, rdev will not be in the list of
mddev->disks if rdev->del_work exists, and flush_workqueue() will never be
executed.

Replace it with flush_workqueue() to ensure del_work has been completed
when adding devices.

Fixes: cc1ffe61 ("md: add new workqueue for delete rdev")
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      52e332f2
    • I
      bonding: Fix memory leak when changing bond type to Ethernet · d8503f10
      由 Ido Schimmel 提交于 
      mainline inclusion
from mainline-v6.3-rc6
commit c484fcc0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I718K0
CVE: NA

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

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

When a net device is put administratively up, its 'IFF_UP' flag is set
(if not set already) and a 'NETDEV_UP' notification is emitted, which
causes the 8021q driver to add VLAN ID 0 on the device. The reverse
happens when a net device is put administratively down.

When changing the type of a bond to Ethernet, its 'IFF_UP' flag is
incorrectly cleared, resulting in the kernel skipping the above process
and VLAN ID 0 being leaked [1].

Fix by restoring the flag when changing the type to Ethernet, in a
similar fashion to the restoration of the 'IFF_SLAVE' flag.

The issue can be reproduced using the script in [2], with example out
before and after the fix in [3].

[1]
unreferenced object 0xffff888103479900 (size 256):
  comm "ip", pid 329, jiffies 4294775225 (age 28.561s)
  hex dump (first 32 bytes):
    00 a0 0c 15 81 88 ff ff 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff81a6051a>] kmalloc_trace+0x2a/0xe0
    [<ffffffff8406426c>] vlan_vid_add+0x30c/0x790
    [<ffffffff84068e21>] vlan_device_event+0x1491/0x21a0
    [<ffffffff81440c8e>] notifier_call_chain+0xbe/0x1f0
    [<ffffffff8372383a>] call_netdevice_notifiers_info+0xba/0x150
    [<ffffffff837590f2>] __dev_notify_flags+0x132/0x2e0
    [<ffffffff8375ad9f>] dev_change_flags+0x11f/0x180
    [<ffffffff8379af36>] do_setlink+0xb96/0x4060
    [<ffffffff837adf6a>] __rtnl_newlink+0xc0a/0x18a0
    [<ffffffff837aec6c>] rtnl_newlink+0x6c/0xa0
    [<ffffffff837ac64e>] rtnetlink_rcv_msg+0x43e/0xe00
    [<ffffffff839a99e0>] netlink_rcv_skb+0x170/0x440
    [<ffffffff839a738f>] netlink_unicast+0x53f/0x810
    [<ffffffff839a7fcb>] netlink_sendmsg+0x96b/0xe90
    [<ffffffff8369d12f>] ____sys_sendmsg+0x30f/0xa70
    [<ffffffff836a6d7a>] ___sys_sendmsg+0x13a/0x1e0
unreferenced object 0xffff88810f6a83e0 (size 32):
  comm "ip", pid 329, jiffies 4294775225 (age 28.561s)
  hex dump (first 32 bytes):
    a0 99 47 03 81 88 ff ff a0 99 47 03 81 88 ff ff  ..G.......G.....
    81 00 00 00 01 00 00 00 cc cc cc cc cc cc cc cc  ................
  backtrace:
    [<ffffffff81a6051a>] kmalloc_trace+0x2a/0xe0
    [<ffffffff84064369>] vlan_vid_add+0x409/0x790
    [<ffffffff84068e21>] vlan_device_event+0x1491/0x21a0
    [<ffffffff81440c8e>] notifier_call_chain+0xbe/0x1f0
    [<ffffffff8372383a>] call_netdevice_notifiers_info+0xba/0x150
    [<ffffffff837590f2>] __dev_notify_flags+0x132/0x2e0
    [<ffffffff8375ad9f>] dev_change_flags+0x11f/0x180
    [<ffffffff8379af36>] do_setlink+0xb96/0x4060
    [<ffffffff837adf6a>] __rtnl_newlink+0xc0a/0x18a0
    [<ffffffff837aec6c>] rtnl_newlink+0x6c/0xa0
    [<ffffffff837ac64e>] rtnetlink_rcv_msg+0x43e/0xe00
    [<ffffffff839a99e0>] netlink_rcv_skb+0x170/0x440
    [<ffffffff839a738f>] netlink_unicast+0x53f/0x810
    [<ffffffff839a7fcb>] netlink_sendmsg+0x96b/0xe90
    [<ffffffff8369d12f>] ____sys_sendmsg+0x30f/0xa70
    [<ffffffff836a6d7a>] ___sys_sendmsg+0x13a/0x1e0

[2]
ip link add name t-nlmon type nlmon
ip link add name t-dummy type dummy
ip link add name t-bond type bond mode active-backup

ip link set dev t-bond up
ip link set dev t-nlmon master t-bond
ip link set dev t-nlmon nomaster
ip link show dev t-bond
ip link set dev t-dummy master t-bond
ip link show dev t-bond

ip link del dev t-bond
ip link del dev t-dummy
ip link del dev t-nlmon

[3]
Before:

12: t-bond: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/netlink
12: t-bond: <BROADCAST,MULTICAST,MASTER,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 46:57:39:a4:46:a2 brd ff:ff:ff:ff:ff:ff

After:

12: t-bond: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/netlink
12: t-bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 66:48:7b:74:b6:8a brd ff:ff:ff:ff:ff:ff

Fixes: e36b9d16 ("bonding: clean muticast addresses when device changes type")
Fixes: 75c78500 ("bonding: remap muticast addresses without using dev_close() and dev_open()")
Fixes: 9ec7eb60 ("bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change")
Reported-by: NMirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Link: https://lore.kernel.org/netdev/78a8a03b-6070-3e6b-5042-f848dab16fb8@alu.unizg.hr/Tested-by: NMirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      d8503f10
  3. 06 5月, 2023 6 次提交
  5. 05 5月, 2023 2 次提交
    • G
      net: sched: sch_qfq: prevent slab-out-of-bounds in qfq_activate_agg · e769145b
      由 Gwangun Jung 提交于 
      stable inclusion
from stable-v4.19.282
commit 6ef8120262dfa63d9ec517d724e6f15591473a78
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6ZISA
CVE: CVE-2023-31436

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

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

[ Upstream commit 30379334 ]

If the TCA_QFQ_LMAX value is not offered through nlattr, lmax is determined by the MTU value of the network device.
The MTU of the loopback device can be set up to 2^31-1.
As a result, it is possible to have an lmax value that exceeds QFQ_MIN_LMAX.

Due to the invalid lmax value, an index is generated that exceeds the QFQ_MAX_INDEX(=24) value, causing out-of-bounds read/write errors.

The following reports a oob access:

[   84.582666] BUG: KASAN: slab-out-of-bounds in qfq_activate_agg.constprop.0 (net/sched/sch_qfq.c:1027 net/sched/sch_qfq.c:1060 net/sched/sch_qfq.c:1313)
[   84.583267] Read of size 4 at addr ffff88810f676948 by task ping/301
[   84.583686]
[   84.583797] CPU: 3 PID: 301 Comm: ping Not tainted 6.3.0-rc5 #1
[   84.584164] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[   84.584644] Call Trace:
[   84.584787]  <TASK>
[   84.584906] dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
[   84.585108] print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)
[   84.585570] kasan_report (mm/kasan/report.c:538)
[   84.585988] qfq_activate_agg.constprop.0 (net/sched/sch_qfq.c:1027 net/sched/sch_qfq.c:1060 net/sched/sch_qfq.c:1313)
[   84.586599] qfq_enqueue (net/sched/sch_qfq.c:1255)
[   84.587607] dev_qdisc_enqueue (net/core/dev.c:3776)
[   84.587749] __dev_queue_xmit (./include/net/sch_generic.h:186 net/core/dev.c:3865 net/core/dev.c:4212)
[   84.588763] ip_finish_output2 (./include/net/neighbour.h:546 net/ipv4/ip_output.c:228)
[   84.589460] ip_output (net/ipv4/ip_output.c:430)
[   84.590132] ip_push_pending_frames (./include/net/dst.h:444 net/ipv4/ip_output.c:126 net/ipv4/ip_output.c:1586 net/ipv4/ip_output.c:1606)
[   84.590285] raw_sendmsg (net/ipv4/raw.c:649)
[   84.591960] sock_sendmsg (net/socket.c:724 net/socket.c:747)
[   84.592084] __sys_sendto (net/socket.c:2142)
[   84.593306] __x64_sys_sendto (net/socket.c:2150)
[   84.593779] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[   84.593902] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
[   84.594070] RIP: 0033:0x7fe568032066
[   84.594192] Code: 0e 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c09[ 84.594796] RSP: 002b:00007ffce388b4e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c

Code starting with the faulting instruction
===========================================
[   84.595047] RAX: ffffffffffffffda RBX: 00007ffce388cc70 RCX: 00007fe568032066
[   84.595281] RDX: 0000000000000040 RSI: 00005605fdad6d10 RDI: 0000000000000003
[   84.595515] RBP: 00005605fdad6d10 R08: 00007ffce388eeec R09: 0000000000000010
[   84.595749] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
[   84.595984] R13: 00007ffce388cc30 R14: 00007ffce388b4f0 R15: 0000001d00000001
[   84.596218]  </TASK>
[   84.596295]
[   84.596351] Allocated by task 291:
[   84.596467] kasan_save_stack (mm/kasan/common.c:46)
[   84.596597] kasan_set_track (mm/kasan/common.c:52)
[   84.596725] __kasan_kmalloc (mm/kasan/common.c:384)
[   84.596852] __kmalloc_node (./include/linux/kasan.h:196 mm/slab_common.c:967 mm/slab_common.c:974)
[   84.596979] qdisc_alloc (./include/linux/slab.h:610 ./include/linux/slab.h:731 net/sched/sch_generic.c:938)
[   84.597100] qdisc_create (net/sched/sch_api.c:1244)
[   84.597222] tc_modify_qdisc (net/sched/sch_api.c:1680)
[   84.597357] rtnetlink_rcv_msg (net/core/rtnetlink.c:6174)
[   84.597495] netlink_rcv_skb (net/netlink/af_netlink.c:2574)
[   84.597627] netlink_unicast (net/netlink/af_netlink.c:1340 net/netlink/af_netlink.c:1365)
[   84.597759] netlink_sendmsg (net/netlink/af_netlink.c:1942)
[   84.597891] sock_sendmsg (net/socket.c:724 net/socket.c:747)
[   84.598016] ____sys_sendmsg (net/socket.c:2501)
[   84.598147] ___sys_sendmsg (net/socket.c:2557)
[   84.598275] __sys_sendmsg (./include/linux/file.h:31 net/socket.c:2586)
[   84.598399] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[   84.598520] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
[   84.598688]
[   84.598744] The buggy address belongs to the object at ffff88810f674000
[   84.598744]  which belongs to the cache kmalloc-8k of size 8192
[   84.599135] The buggy address is located 2664 bytes to the right of
[   84.599135]  allocated 7904-byte region [ffff88810f674000, ffff88810f675ee0)
[   84.599544]
[   84.599598] The buggy address belongs to the physical page:
[   84.599777] page:00000000e638567f refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10f670
[   84.600074] head:00000000e638567f order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[   84.600330] flags: 0x200000000010200(slab|head|node=0|zone=2)
[   84.600517] raw: 0200000000010200 ffff888100043180 dead000000000122 0000000000000000
[   84.600764] raw: 0000000000000000 0000000080020002 00000001ffffffff 0000000000000000
[   84.601009] page dumped because: kasan: bad access detected
[   84.601187]
[   84.601241] Memory state around the buggy address:
[   84.601396]  ffff88810f676800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   84.601620]  ffff88810f676880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   84.601845] >ffff88810f676900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   84.602069]                                               ^
[   84.602243]  ffff88810f676980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   84.602468]  ffff88810f676a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   84.602693] ==================================================================
[   84.602924] Disabling lock debugging due to kernel taint

Fixes: 3015f3d2 ("pkt_sched: enable QFQ to support TSO/GSO")
Reported-by: NGwangun Jung <exsociety@gmail.com>
Signed-off-by: NGwangun Jung <exsociety@gmail.com>
Acked-by: Jamal Hadi Salim<jhs@mojatatu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      e769145b
    • B
      ext4: only update i_reserved_data_blocks on successful block allocation · 8c1d63f6
      由 Baokun Li 提交于 
      maillist inclusion
category: bugfix
bugzilla: 188499, https://gitee.com/openeuler/kernel/issues/I6TNVT
CVE: NA

Reference: https://patchwork.ozlabs.org/project/linux-ext4/patch/20230412124126.2286716-2-libaokun1@huawei.com/

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

In our fault injection test, we create an ext4 file, migrate it to
non-extent based file, then punch a hole and finally trigger a WARN_ON
in the ext4_da_update_reserve_space():

EXT4-fs warning (device sda): ext4_da_update_reserve_space:369:
ino 14, used 11 with only 10 reserved data blocks

When writing back a non-extent based file, if we enable delalloc, the
number of reserved blocks will be subtracted from the number of blocks
mapped by ext4_ind_map_blocks(), and the extent status tree will be
updated. We update the extent status tree by first removing the old
extent_status and then inserting the new extent_status. If the block range
we remove happens to be in an extent, then we need to allocate another
extent_status with ext4_es_alloc_extent().

       use old    to remove   to add new
    |----------|------------|------------|
              old extent_status

The problem is that the allocation of a new extent_status failed due to a
fault injection, and __es_shrink() did not get free memory, resulting in
a return of -ENOMEM. Then do_writepages() retries after receiving -ENOMEM,
we map to the same extent again, and the number of reserved blocks is again
subtracted from the number of blocks in that extent. Since the blocks in
the same extent are subtracted twice, we end up triggering WARN_ON at
ext4_da_update_reserve_space() because used > ei->i_reserved_data_blocks.

For non-extent based file, we update the number of reserved blocks after
ext4_ind_map_blocks() is executed, which causes a problem that when we call
ext4_ind_map_blocks() to create a block, it doesn't always create a block,
but we always reduce the number of reserved blocks. So we move the logic
for updating reserved blocks to ext4_ind_map_blocks() to ensure that the
number of reserved blocks is updated only after we do succeed in allocating
some new blocks.

Fixes: 5f634d06 ("ext4: Fix quota accounting error with fallocate")
Reviewed-by: NJan Kara <jack@suse.cz>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      8c1d63f6
  7. 28 4月, 2023 8 次提交
  9. 26 4月, 2023 1 次提交
  11. 25 4月, 2023 1 次提交
  13. 24 4月, 2023 1 次提交
  15. 23 4月, 2023 3 次提交
    • W
      i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer() · b735f669
      由 Wei Chen 提交于 
      mainline inclusion
from mainline-v6.3-rc4
commit 92fbb6d1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6XHPL
CVE: CVE-2023-2194

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

The data->block[0] variable comes from user and is a number between
0-255. Without proper check, the variable may be very large to cause
an out-of-bounds when performing memcpy in slimpro_i2c_blkwr.

Fix this bug by checking the value of writelen.

Fixes: f6505fba ("i2c: add SLIMpro I2C device driver on APM X-Gene platform")
Signed-off-by: NWei Chen <harperchen1110@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: NAndi Shyti <andi.shyti@kernel.org>
Signed-off-by: NWolfram Sang <wsa@kernel.org>
Signed-off-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      b735f669
    • L
      audit: fix a memleak caused by auditing load module · 08551f22
      由 Li RongQing 提交于 
      mainline inclusion
from mainline-v5.2-rc1
commit 95e0b46f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6X2LV
CVE: NA

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

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

module.name will be allocated unconditionally when auditing load
module, and audit_log_start() can fail with other reasons, or
audit_log_exit maybe not called, caused module.name is not freed

so free module.name in audit_free_context and __audit_syscall_exit

unreferenced object 0xffff88af90837d20 (size 8):
  comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s)
  hex dump (first 8 bytes):
    69 78 67 62 65 00 ff ff                          ixgbe...
  backtrace:
    [<0000000008da28fe>] __audit_log_kern_module+0x33/0x80
    [<00000000c1491e61>] load_module+0x64f/0x3850
    [<000000007fc9ae3f>] __do_sys_init_module+0x218/0x250
    [<0000000000d4a478>] do_syscall_64+0x117/0x400
    [<000000004924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [<000000007dc331dd>] 0xffffffffffffffff

Fixes: ca86cad7 ("audit: log module name on init_module")
Signed-off-by: NZhang Yu <zhangyu31@baidu.com>
Signed-off-by: NLi RongQing <lirongqing@baidu.com>
[PM: manual merge fixup in __audit_syscall_exit()]
Signed-off-by: NPaul Moore <paul@paul-moore.com>

conflict:
	kernel/auditsc.c
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Reviewed-by: Ncuigaosheng <cuigaosheng1@huawei.com>
Reviewed-by: Nguozihua <guozihua@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      08551f22
    • O
      !595 [openEuler-1.0-LTS] iommu/arm-smmu-v3: Fix UAF when handle evt during iommu group removing · 632f732c
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ch-cityhunter 
 
#### 设备remove流程和smmu中断处理线程是异步的，并发情况下有UAF问题

1. arm_smmu_remove_device流程先释放了dev->iommu_param
   中断线程查找的红黑树还能找到对应master，会导致UAF
2. 中断线程通过红黑树获取master之后使用的过程没有保护
   remove流程也可以在其查找成功之后释放dev->iommu_param

openeuler在2019年最初上库第一版arm-smmu-v3是就有此问题

#### 修改方法

参考内核社区，arm-smmu-v3在2021年合入社区，此问题经过review后已修正，首次合入是没问题的
https://github.com/torvalds/linux/commit/395ad89d11fd93f79a6b942e91fc409807a63c4b

1. 调整移除master和释放内存的顺序，先移除master，避免被其他流程查找到
2. arm_smmu_find_master()外部加锁，保护中断线程获取master后整个使用阶段

```
driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKM7
CVE: NA

--------

A use-after-free issue like following:

[ 2257.819189] arm-smmu-v3 arm-smmu-v3.4.auto: EVTQ overflow detected -- events lost
[ 2257.819197] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received:
[ 2257.819199] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000820000000010
[ 2257.819201] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000020000000000
[ 2257.819202] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7218
[ 2257.819206] iommu: Removing device 0000:82:00.0 from group 49
[ 2257.819207] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7000
[ 2257.819211] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received:
[ 2257.819212] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000820000000010
[ 2257.819214] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000020000000000
[ 2257.819215] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea722c
[ 2257.819216] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7000
[ 2257.819218] ==================================================================
[ 2257.819228] BUG: KASAN: use-after-free in iommu_report_device_fault+0x520/0x5c0
[ 2257.819230] Read of size 8 at addr ffffa02c516c1320 by task irq/63-arm-smmu/483
[ 2257.819231]
[ 2257.819235] CPU: 25 PID: 483 Comm: irq/63-arm-smmu Kdump: loaded Tainted: G           OE     4.19.90-2205.3.0.0149.oe1.aarch64+debug #1
[ 2257.819236] Hardware name: Huawei S920S00/BC82AMDGK, BIOS 1.68 11/10/2020
[ 2257.819237] Call trace:
[ 2257.819240]  dump_backtrace+0x0/0x320
[ 2257.819242]  show_stack+0x24/0x30
[ 2257.819246]  dump_stack+0xdc/0x128
[ 2257.819251]  print_address_description+0x68/0x278
[ 2257.819253]  kasan_report+0x1e4/0x308
[ 2257.819254]  __asan_report_load8_noabort+0x30/0x40
[ 2257.819257]  iommu_report_device_fault+0x520/0x5c0
[ 2257.819260]  arm_smmu_handle_evt+0x300/0x428
[ 2257.819261]  arm_smmu_evtq_thread+0x27c/0x460
[ 2257.819264]  irq_thread_fn+0x88/0x140
[ 2257.819266]  irq_thread+0x190/0x318
[ 2257.819268]  kthread+0x2a4/0x320
[ 2257.819270]  ret_from_fork+0x10/0x18
[ 2257.819271]
[ 2257.819273] Allocated by task 95166:
[ 2257.819275]  kasan_kmalloc+0xd0/0x178
[ 2257.819277]  kmem_cache_alloc_trace+0x100/0x210
[ 2257.819279]  iommu_group_add_device+0x254/0xe18
[ 2257.819280]  iommu_group_get_for_dev+0x198/0x480
[ 2257.819282]  arm_smmu_add_device+0x424/0x988
[ 2257.819284]  iort_iommu_configure+0x33c/0x5b8
[ 2257.819287]  acpi_dma_configure+0x9c/0xf8
[ 2257.819289]  pci_dma_configure+0x124/0x158
[ 2257.819291]  dma_configure+0x5c/0x80
[ 2257.819294]  really_probe+0xcc/0x920
[ 2257.819296]  driver_probe_device+0x224/0x308
[ 2257.819298]  __device_attach_driver+0x154/0x260
[ 2257.819299]  bus_for_each_drv+0xe4/0x178
[ 2257.819301]  __device_attach+0x1bc/0x2a8
[ 2257.819302]  device_attach+0x24/0x30
[ 2257.819304]  pci_bus_add_device+0x7c/0xe8
[ 2257.819305]  pci_bus_add_devices+0x70/0x168
[ 2257.819307]  pci_bus_add_devices+0x114/0x168
[ 2257.819308]  pci_rescan_bus+0x38/0x48
[ 2257.819310]  bus_rescan_store+0xc4/0xe8
[ 2257.819312]  bus_attr_store+0x70/0x98
[ 2257.819314]  sysfs_kf_write+0x104/0x170
[ 2257.819316]  kernfs_fop_write+0x23c/0x430
[ 2257.819319]  __vfs_write+0x7c/0xe8
[ 2257.819320]  vfs_write+0x12c/0x3d0
[ 2257.819321]  ksys_write+0xd4/0x1d8
[ 2257.819322]  __arm64_sys_write+0x70/0xa0
[ 2257.819325]  el0_svc_common+0xfc/0x278
[ 2257.819327]  el0_svc_handler+0x50/0xc0
[ 2257.819329]  el0_svc+0x8/0x1b0
[ 2257.819329]
[ 2257.819330] Freed by task 95166:
[ 2257.819332]  __kasan_slab_free+0x114/0x200
[ 2257.819334]  kasan_slab_free+0x10/0x18
[ 2257.819335]  kfree+0x80/0x1f0
[ 2257.819337]  iommu_group_remove_device+0x27c/0x560
[ 2257.819338]  arm_smmu_remove_device+0xe8/0x190
[ 2257.819339]  iommu_bus_notifier+0x134/0x248
[ 2257.819342]  notifier_call_chain+0xb0/0x140
[ 2257.819343]  blocking_notifier_call_chain+0x6c/0xd8
[ 2257.819344]  device_del+0x578/0x940
[ 2257.819346]  pci_remove_bus_device+0x114/0x290
[ 2257.819347]  pci_stop_and_remove_bus_device_locked+0x2c/0x40
[ 2257.819349]  remove_store+0xdc/0xe8
[ 2257.819352]  dev_attr_store+0x60/0x80
[ 2257.819353]  sysfs_kf_write+0x104/0x170
[ 2257.819354]  kernfs_fop_write+0x23c/0x430
[ 2257.819355]  __vfs_write+0x7c/0xe8
[ 2257.819357]  vfs_write+0x12c/0x3d0
[ 2257.819358]  ksys_write+0xd4/0x1d8
[ 2257.819359]  __arm64_sys_write+0x70/0xa0
[ 2257.819361]  el0_svc_common+0xfc/0x278
[ 2257.819362]  el0_svc_handler+0x50/0xc0
[ 2257.819364]  el0_svc+0x8/0x1b0
[ 2257.819364]

           T0                                 T1
---------------------------------    ---------------------------------
|- arm_smmu_evtq_thread              |- arm_smmu_remove_device
  |- arm_smmu_handle_evt               |- iommu_group_remove_device
                                         |- kfree(dev->iommu_param)
    |- arm_smmu_find_master
    |- iommu_report_device_fault       |- arm_smmu_remove_master
      |- mutex_lock( \
         &dev->iommu_param->lock)
         // UAF

Reference upstream mainline commit 395ad89d,
move arm_smmu_remove_master() before iommu_group_remove_device(),
and hold mutex to protect finding master and subsequent handling.
``` 
 
Link:https://gitee.com/openeuler/kernel/pulls/595 

Reviewed-by: Weilong Chen <chenweilong@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      632f732c
  17. 19 4月, 2023 2 次提交
  19. 18 4月, 2023 9 次提交
  21. 17 4月, 2023 2 次提交