Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 5月, 2023 2 次提交
  3. 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
  5. 28 4月, 2023 8 次提交
  7. 26 4月, 2023 1 次提交
  9. 25 4月, 2023 1 次提交
  11. 24 4月, 2023 1 次提交
  13. 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
  15. 19 4月, 2023 2 次提交
  17. 18 4月, 2023 9 次提交
  19. 17 4月, 2023 2 次提交
  21. 11 4月, 2023 1 次提交
  23. 10 4月, 2023 2 次提交
  25. 08 4月, 2023 6 次提交