Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 5月, 2023 1 次提交
    • L
      i2c: Add Zhaoxin I2C driver · 735c81b4
      由 leoliu-oc 提交于 
      zhaoxin inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6J3EV
CVE: NA

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

Zhaoxin I2C Linux driver support all bidirectional bus protocols speed
specified in the I2C Specification 7.0. The speed mode listed in the
followed table.

|   Speed Name    |           Description                |
| Standard-mode   | Bit rate up to 100 kbit/s            |
| Fast-mode       | Bit rate up to 400 kbit/s.(default)  |
| Fast-mode Plus  | Bit rate up to 1 Mbit/s              |
| High-speed mode | Bit rate up to 3.4 Mbit/s.           |
Signed-off-by: Nleoliu-oc <leoliu-oc@zhaoxin.com>
      735c81b4
  3. 28 2月, 2023 10 次提交
    • O
      !423 genirq bugfix for arm64 · fe71e580
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @LiuYongQiang0816 
 
genirq bugfix from Yipeng Zou 
 
Link:https://gitee.com/openeuler/kernel/pulls/423 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      fe71e580
    • Y
      genirq: Remove irqd_irq_disabled in __irq_move_irq · 2e149805
      由 Yipeng Zou 提交于 
      hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BO2R
CVE: NA

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

CONFIG_GENERIC_PENDING_IRQ has been enable in ARM64 for LPI, which can
delay set irq affinity ops in chip->irq_eoi process. While drivers call
disable_irq_nosync in irq handler, __irq_move_irq would judge irq
is disabled and return directly, which cause set affinity failed.

To fix this issue, remove the irq status judgement in __irq_move_irq
for ARM64, cause there is no relationship between irq affinity and irq
disabled, and irq_set_affinity does not judge it either.

Fixes: 6ea55196 ("irqchip/gic-v3-its: introduce CONFIG_GENERIC_PENDING_IRQ")
Signed-off-by: NZhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: NYipeng Zou <zouyipeng@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      2e149805
    • O
      !422 iscsi bugfixes backport · 140dbb75
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @LiuYongQiang0816 
 
two iscsi bugfixes backport from Zhong Jinghua 
 
Link:https://gitee.com/openeuler/kernel/pulls/422 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      140dbb75
    • M
      scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress · cc6fb9a6
      由 Mike Christie 提交于 
      mainline inclusion
from mainline-v6.2-rc6
commit f484a794
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails,
userspace could be accessing the host's ipaddress attr. If we then free the
session via iscsi_session_teardown() while userspace is still accessing the
session we will hit a use after free bug.

Set the tcp_sw_host->session after we have completed session creation and
can no longer fail.

Link: https://lore.kernel.org/r/20230117193937.21244-3-michael.christie@oracle.comSigned-off-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Acked-by: NDing Hui <dinghui@sangfor.com.cn>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      cc6fb9a6
    • M
      scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress · 3835c5e9
      由 Mike Christie 提交于 
      mainline inclusion
from mainline-v6.2-rc6
commit 6f1d64b1
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

Bug report and analysis from Ding Hui.

During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:

[  276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[  276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[  276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G            E      6.1.0-rc8+ #3
[  276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[  276.944470] Call Trace:
[  276.944943]  <TASK>
[  276.945397]  dump_stack_lvl+0x34/0x48
[  276.945887]  print_address_description.constprop.0+0x86/0x1e7
[  276.946421]  print_report+0x36/0x4f
[  276.947358]  kasan_report+0xad/0x130
[  276.948234]  kasan_check_range+0x35/0x1c0
[  276.948674]  _raw_spin_lock_bh+0x78/0xe0
[  276.949989]  iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]
[  276.951765]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]
[  276.952185]  dev_attr_show+0x3f/0x80
[  276.953005]  sysfs_kf_seq_show+0x1fb/0x3e0
[  276.953401]  seq_read_iter+0x402/0x1020
[  276.954260]  vfs_read+0x532/0x7b0
[  276.955113]  ksys_read+0xed/0x1c0
[  276.955952]  do_syscall_64+0x38/0x90
[  276.956347]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.956769] RIP: 0033:0x7f5d3a679222
[  276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[  276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222
[  276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003
[  276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000
[  276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000
[  276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58
[  276.960536]  </TASK>
[  276.961357] Allocated by task 2209:
[  276.961756]  kasan_save_stack+0x1e/0x40
[  276.962170]  kasan_set_track+0x21/0x30
[  276.962557]  __kasan_kmalloc+0x7e/0x90
[  276.962923]  __kmalloc+0x5b/0x140
[  276.963308]  iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]
[  276.963712]  iscsi_session_setup+0xda/0xba0 [libiscsi]
[  276.964078]  iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]
[  276.964431]  iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]
[  276.964793]  iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]
[  276.965153]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.965546]  netlink_unicast+0x4d5/0x7b0
[  276.965905]  netlink_sendmsg+0x78d/0xc30
[  276.966236]  sock_sendmsg+0xe5/0x120
[  276.966576]  ____sys_sendmsg+0x5fe/0x860
[  276.966923]  ___sys_sendmsg+0xe0/0x170
[  276.967300]  __sys_sendmsg+0xc8/0x170
[  276.967666]  do_syscall_64+0x38/0x90
[  276.968028]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.968773] Freed by task 2209:
[  276.969111]  kasan_save_stack+0x1e/0x40
[  276.969449]  kasan_set_track+0x21/0x30
[  276.969789]  kasan_save_free_info+0x2a/0x50
[  276.970146]  __kasan_slab_free+0x106/0x190
[  276.970470]  __kmem_cache_free+0x133/0x270
[  276.970816]  device_release+0x98/0x210
[  276.971145]  kobject_cleanup+0x101/0x360
[  276.971462]  iscsi_session_teardown+0x3fb/0x530 [libiscsi]
[  276.971775]  iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]
[  276.972143]  iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]
[  276.972485]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.972808]  netlink_unicast+0x4d5/0x7b0
[  276.973201]  netlink_sendmsg+0x78d/0xc30
[  276.973544]  sock_sendmsg+0xe5/0x120
[  276.973864]  ____sys_sendmsg+0x5fe/0x860
[  276.974248]  ___sys_sendmsg+0xe0/0x170
[  276.974583]  __sys_sendmsg+0xc8/0x170
[  276.974891]  do_syscall_64+0x38/0x90
[  276.975216]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

We can easily reproduce by two tasks:
1. while :; do iscsiadm -m node --login; iscsiadm -m node --logout; done
2. while :; do cat \
/sys/devices/platform/host*/iscsi_host/host*/ipaddress; done

            iscsid              |        cat
--------------------------------+---------------------------------------
|- iscsi_sw_tcp_session_destroy |
  |- iscsi_session_teardown     |
    |- device_release           |
      |- iscsi_session_release  ||- dev_attr_show
        |- kfree                |  |- show_host_param_
                                |             ISCSI_HOST_PARAM_IPADDRESS
                                |    |- iscsi_sw_tcp_host_get_param
                                |      |- r/w tcp_sw_host->session (UAF)
  |- iscsi_host_remove          |
  |- iscsi_host_free            |

Fix the above bug by splitting the session removal into 2 parts:

 1. removal from iSCSI class which includes sysfs and removal from host
    tracking.

 2. freeing of session.

During iscsi_tcp host and session removal we can remove the session from
sysfs then remove the host from sysfs. At this point we know userspace is
not accessing the kernel via sysfs so we can free the session and host.

Link: https://lore.kernel.org/r/20230117193937.21244-2-michael.christie@oracle.comSigned-off-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Acked-by: NDing Hui <dinghui@sangfor.com.cn>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NWenchao Hao <haowenchao2@huawei.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      3835c5e9
    • O
      !420 backport CVEs and bugfixes · 6ef38034
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @LiuYongQiang0816 
 
Pull new CVEs:
CVE-2023-26545

a nbd bugfix from Zhong Jinghua
two selinux bugfixes from GONG, Ruiqi 
 
Link:https://gitee.com/openeuler/kernel/pulls/420 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      6ef38034
    • J
      net: mpls: fix stale pointer if allocation fails during device rename · 387bf44c
      由 Jakub Kicinski 提交于 
      stable inclusion
from stable-v4.19.273
commit aa07c86e43ed8780d610ecfb2ce13da326729201
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6HZHU
CVE: CVE-2023-26545

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

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

commit fda6c89f upstream.

lianhui reports that when MPLS fails to register the sysctl table
under new location (during device rename) the old pointers won't
get overwritten and may be freed again (double free).

Handle this gracefully. The best option would be unregistering
the MPLS from the device completely on failure, but unfortunately
mpls_ifdown() can fail. So failing fully is also unreliable.

Another option is to register the new table first then only
remove old one if the new one succeeds. That requires more
code, changes order of notifications and two tables may be
visible at the same time.

sysctl point is not used in the rest of the code - set to NULL
on failures and skip unregister if already NULL.
Reported-by: Nlianhui tang <bluetlh@gmail.com>
Fixes: 0fae3bf0 ("mpls: handle device renames for per-device sysctls")
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      387bf44c
    • Z
      nbd: fix assignment error for first_minor in nbd_dev_add · 659039b1
      由 Zhong Jinghua 提交于 
      hulk inclusion
category: bugfix
bugzilla: 188413, https://gitee.com/openeuler/kernel/issues/I6GWYG
CVE: NA

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

A panic error is like below:

nbd_genl_connect
 nbd_dev_add
   first_minor = index << part_shift; // index =-1
   ...
   __device_add_disk
     blk_alloc_devt
       *devt = MKDEV(disk->major, disk->first_minor + part->partno);
       // part->partno = 0， first_minor = 11...110000 major is covered

There, index < 0 will reassign an index, but here disk->first_minor is
assigned -1 << part_shift.

This causes to the creation of the device with the same major and minor
device numbers each time the incoming index<0, and this will lead to
creation of kobject failed:
Warning: kobject_add_internal failed for 4095:1048544 with -EEXIST, don't
try to register things with the same name in the same directory.

Fix it by moving the first_minor assignment down to after getting the new
index.

Fixes: 01f7594e ("nbd: Fix use-after-free in blk_mq_free_rqs")
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      659039b1
    • G
      selinux: further adjust init order for cred_* hooks · 2a72e51d
      由 GONG, Ruiqi 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DRJ1
CVE: NA

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

After backporting commit cfff75d8 ("selinux: reorder hooks to make
runtime disable less broken") to the 4.19 kernel of openEuler-1.0-LTS,
various kernel panic problems were still triggered by running the POC of
the aforementioned commit.

Here's a case from selinux_file_alloc_security():

BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
PGD 8000000002273067 P4D 8000000002273067 PUD 225c067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 299 Comm: exe Tainted: G           OE     4.19.90+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:selinux_file_alloc_security+0x2a/0x50
Code: 0f 1f 44 00 00 55 be c0 80 60 00 53 48 89 fb 48 8b 3d c2 f3 98 01 65 48 8b 04 25 80 64 01 00 48 8b 80 b8 0a 00 00 48 8b 40 78 <8b> 68 04 e8 ce ce ee ff 48 85 c0 74 11 89 28 89 68 04 48 89 83 c0
RSP: 0018:ffffa3ff40967c48 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff94e881b6a600 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000006080c0 RDI: ffff94e8811472c0
RBP: ffff94e881b6a600 R08: 0000000000000100 R09: 0000000000000000
R10: ffff94e881b6a600 R11: 0000000000000020 R12: ffff94e881b6a600
R13: 0000000000000041 R14: ffffa3ff40967d10 R15: ffff94e882202c80
FS:  00000000007d28c0(0000) GS:ffff94e8be800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 0000000002862000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 security_file_alloc+0x22/0x40
 __alloc_file+0x52/0x110
 alloc_empty_file+0x41/0xb0
 path_openat+0x43/0x280
 do_filp_open+0x91/0x100
 ? filemap_map_pages+0x424/0x460
 ? do_fault+0x21b/0x4c0
 do_open_execat+0x79/0x180
 __do_execve_file.isra.0+0x6dd/0x8b0
 __x64_sys_execve+0x35/0x40
 do_syscall_64+0x63/0x250
 ? async_page_fault+0x8/0x30
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x49a5db
Code: 41 89 01 eb da 66 2e 0f 1f 84 00 00 00 00 00 f7 d8 64 41 89 01 eb d6 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 3b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffce51a0148 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
RAX: ffffffffffffffda RBX: 00000000007d4ee0 RCX: 000000000049a5db
RDX: 00000000007d4f08 RSI: 00000000007d4ee0 RDI: 00000000007d4f48
RBP: 00000000007d4f48 R08: fefefefefefefeff R09: fefefeff666d686f
R10: 00000000007d2b90 R11: 0000000000000246 R12: 00000000007d4f08
R13: 0000000000655894 R14: 00000000007d4f08 R15: 00000000007d3ed0
Modules linked in: e1000(OE)
CR2: 0000000000000004
---[ end trace 4a826955419bd28a ]---
RIP: 0010:selinux_file_alloc_security+0x2a/0x50
Code: 0f 1f 44 00 00 55 be c0 80 60 00 53 48 89 fb 48 8b 3d c2 f3 98 01 65 48 8b 04 25 80 64 01 00 48 8b 80 b8 0a 00 00 48 8b 40 78 <8b> 68 04 e8 ce ce ee ff 48 85 c0 74 11 89 28 89 68 04 48 89 83 c0
RSP: 0018:ffffa3ff40967c48 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff94e881b6a600 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000006080c0 RDI: ffff94e8811472c0
RBP: ffff94e881b6a600 R08: 0000000000000100 R09: 0000000000000000
R10: ffff94e881b6a600 R11: 0000000000000020 R12: ffff94e881b6a600
R13: 0000000000000041 R14: ffffa3ff40967d10 R15: ffff94e882202c80
FS:  00000000007d28c0(0000) GS:ffff94e8be800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 0000000002862000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x33400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---

Another one from selinux_inode_alloc_security():

BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
PGD 8000000002187067 P4D 8000000002187067 PUD 2170067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 7 PID: 521 Comm: ping Tainted: G           OE     4.19.90+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:selinux_inode_alloc_security+0x2a/0x80
Code: 0f 1f 44 00 00 55 be 40 80 60 00 53 48 89 fb 48 8b 3d 6a 0c 99 01 65 48 8b 04 25 80 64 01 00 48 8b 80 b8 0a 00 00 48 8b 40 78 <8b> 68 04 e8 6e e7 ee ff 48 85 c0 74 36 48 8d 50 08 c7 40 24 00 00
RSP: 0018:ffffbd7741077b08 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff95c48251e738 RCX: 0000000000000000
RDX: ffffffff85d11344 RSI: 0000000000608040 RDI: ffff95c481004380
RBP: ffff95c48251e738 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff95c48251e738
R13: ffff95c4822ac2c0 R14: ffffbd7741077dd0 R15: 0000000000000000
FS:  00000000018f08c0(0000) GS:ffff95c4be9c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000000022dc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 security_inode_alloc+0x2a/0x40
 inode_init_always+0x1b9/0x1d0
 alloc_inode+0x2f/0x90
 new_inode_pseudo+0xd/0x60
 new_inode+0x13/0x30
 proc_pid_make_inode+0x18/0xb0
 proc_pid_instantiate+0x1e/0x90
 proc_pid_lookup+0x4e/0x80
 proc_root_lookup+0x18/0x40
 __lookup_slow+0x94/0x160
 lookup_slow+0x36/0x50
 walk_component+0x1c4/0x340
 ? inode_permission+0x35/0x1a0
 link_path_walk.part.0+0x1af/0x540
 ? proc_ns_get_link+0xb0/0xb0
 path_lookupat.isra.0+0x4e/0x230
 filename_lookup+0xae/0x180
 ? simple_attr_release+0x20/0x20
 ? strncpy_from_user+0x47/0x160
 do_readlinkat+0x5d/0x130
 __x64_sys_readlink+0x1b/0x20
 do_syscall_64+0x63/0x250
 ? async_page_fault+0x8/0x30
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x5185e3
Code: 53 48 81 ec 00 10 00 00 48 83 0c 24 00 48 83 ec 08 ba 00 10 00 00 48 8d 3d f7 af 15 00 b8 59 00 00 00 48 89 e5 48 89 ee 0f 05 <3d> 00 f0 ff ff 77 5e 85 c0 7e 5a 0f b6 14 24 80 fa 5b 74 51 80 fa
RSP: 002b:00007ffe7aa96960 EFLAGS: 00000206 ORIG_RAX: 0000000000000059
RAX: ffffffffffffffda RBX: 0000000000400770 RCX: 00000000005185e3
RDX: 0000000000001000 RSI: 00007ffe7aa96960 RDI: 00000000006735cd
RBP: 00007ffe7aa96960 R08: 0000000000000003 R09: 00007ffe7aa97a64
R10: 0000000000671d9a R11: 0000000000000206 R12: 00007ffe7aa97b58
R13: 00007ffe7aa97b80 R14: 0000000000690018 R15: 0000000000000000
Modules linked in: e1000(OE)
CR2: 0000000000000004
---[ end trace a5121fc2d5201098 ]---
RIP: 0010:selinux_inode_alloc_security+0x2a/0x80
Code: 0f 1f 44 00 00 55 be 40 80 60 00 53 48 89 fb 48 8b 3d 6a 0c 99 01 65 48 8b 04 25 80 64 01 00 48 8b 80 b8 0a 00 00 48 8b 40 78 <8b> 68 04 e8 6e e7 ee ff 48 85 c0 74 36 48 8d 50 08 c7 40 24 00 00
RSP: 0018:ffffbd7741077b08 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff95c48251e738 RCX: 0000000000000000
RDX: ffffffff85d11344 RSI: 0000000000608040 RDI: ffff95c481004380
RBP: ffff95c48251e738 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff95c48251e738
R13: ffff95c4822ac2c0 R14: ffffbd7741077dd0 R15: 0000000000000000
FS:  00000000018f08c0(0000) GS:ffff95c4be9c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000000022dc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x3000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---

These problems were all caused by accessing a credential's tsec being
NULL. Given that many "allocating" hooks would access tsec as well
(e.g. selinux_{key,bpf_{map,prog}}_alloc, selinux_ib_alloc_security
etc), make a fourth block and move cred hooks of allocating tsec out
there.

Fixes: 87d41806 ("selinux: reorder hooks to make runtime disable less broken")
Signed-off-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      2a72e51d
    • G
      selinux: further adjust init order for file_alloc_security hook · 5e10c473
      由 GONG, Ruiqi 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DRJ1
CVE: NA

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

After backporting commit cfff75d8 ("selinux: reorder hooks to make
runtime disable less broken") to the 4.19 kernel of openEuler-1.0-LTS,
another kernel panic was triggered by running the POC of the
aforementioned commit:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
PGD 800000001840b067 P4D 800000001840b067 PUD 1840c067 PMD 0
Oops: 0002 [#1] SMP PTI
CPU: 7 PID: 273 Comm: exe Tainted: G           OE     4.19.90+ #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:selinux_file_open+0x49/0xf0
Code: 00 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 31 c0 4c 89 e7 e8 a6 ec ff ff 49 8b 44 24 38 48 c7 c7 e0 a5 13 97 8b 40 1c <89> 45 08 e8 6f 80 ff ff ba 02 00 00 00 89 45 0c 8b 43 44 8b 73 40
RSP: 0018:ffffbb7300867ba0 EFLAGS: 00010246
RAX: 0000000000000003 RBX: ffff9dc301961400 RCX: 00000000000081ed
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff9713a5e0
RBP: 0000000000000000 R08: 0000000000000001 R09: ffff9dc301fedcb0
R10: 0000000000000007 R11: 7fffffffffffffff R12: ffff9dc30204fd70
R13: 0000000000000000 R14: ffff9dc301961410 R15: ffffbb7300867c70
FS:  0000000000d258c0(0000) GS:ffff9dc33e9c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000000022bc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ? generic_permission+0x10a/0x190
 security_file_open+0x26/0x90
 do_dentry_open+0xd9/0x380
 do_last+0x197/0x8d0
 path_openat+0x89/0x280
 do_filp_open+0x91/0x100
 do_open_execat+0x79/0x180
 __do_execve_file.isra.0+0x6dd/0x8b0
 __x64_sys_execve+0x35/0x40
 do_syscall_64+0x63/0x250
 ? async_page_fault+0x8/0x30
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x49a5db
Code: 41 89 01 eb da 66 2e 0f 1f 84 00 00 00 00 00 f7 d8 64 41 89 01 eb d6 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 3b 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe7b1cebd8 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
RAX: ffffffffffffffda RBX: 0000000000d27ee0 RCX: 000000000049a5db
RDX: 0000000000d27f08 RSI: 0000000000d27ee0 RDI: 0000000000d27f48
RBP: 0000000000d27f48 R08: fefefefefefefeff R09: fefefeff666d686f
R10: 0000000000d25b90 R11: 0000000000000246 R12: 0000000000d27f08
R13: 0000000000655894 R14: 0000000000d27f08 R15: 0000000000d26ed0
Modules linked in: e1000(OE)
CR2: 0000000000000008
---[ end trace e4eb884974c22e2d ]---
RIP: 0010:selinux_file_open+0x49/0xf0
Code: 00 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 31 c0 4c 89 e7 e8 a6 ec ff ff 49 8b 44 24 38 48 c7 c7 e0 a5 13 97 8b 40 1c <89> 45 08 e8 6f 80 ff ff ba 02 00 00 00 89 45 0c 8b 43 44 8b 73 40
RSP: 0018:ffffbb7300867ba0 EFLAGS: 00010246
RAX: 0000000000000003 RBX: ffff9dc301961400 RCX: 00000000000081ed
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff9713a5e0
RBP: 0000000000000000 R08: 0000000000000001 R09: ffff9dc301fedcb0
R10: 0000000000000007 R11: 7fffffffffffffff R12: ffff9dc30204fd70
R13: 0000000000000000 R14: ffff9dc301961410 R15: ffffbb7300867c70
FS:  0000000000d258c0(0000) GS:ffff9dc33e9c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000000022bc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x14400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---

The problem was caused by selinux_file_open() accessing a file's fsec
being NULL, which indicated that the file_alloc_security hook should be
deleted later (at least after the file_open hook) when disabling SELinux
at runtime. Here I put it into the "allocating" part.

Fixes: 87d41806 ("selinux: reorder hooks to make runtime disable less broken")
Signed-off-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      5e10c473
  5. 27 2月, 2023 1 次提交
    • O
      !415 mainline bugfix backport · 18e32b66
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @LiuYongQiang0816 
 
|标题| 分析结果|
|--------| ------|
|crypto: rsa-pkcs1pad - fix buffer overread in pkcs1pad_verify_complete() |	在进行读取之前需要检查digest_info大小是否足够 |
|crypto: algif_skcipher - EBUSY on aio should be an error				 |	正确返回错误 |
|crypto: algif_skcipher - Use chunksize instead of blocksize				 |	修复CTR场景下参数错误的问题 |
|ipmi: use %*ph to print small buffer									 |	修复可能buffer溢出的问题 |
|component: do not dereference opaque pointer in debugfs					 |	match->compare[i].data不一定是struct device* 指针类型，这里使用dev_name(data)打印设备名，有可能造成空指针访问。改使用dev_name(component->dev)来打印设备名称|
|drivers/iommu: Export core IOMMU API symbols to permit modular drivers	 |	导出构建IOMMU驱动时所需要的iommu core api。此补丁能够解决iommu driver编译为模块时符号缺失的问题 |
|drivers/iommu: Allow IOMMU bus ops to be unregistered					 |	在iommu类KO卸载的情况下，ops指针非法，有可能触发访问非法地址。修复方式：让bus_set_iommu（）接受一个NULL值ops参数来让给定bus类型ops重置 |
|of: unittest: Add of_node_put() before return							 |	修复driver/of/unittest.c中异常返回路径上的内存泄漏问题 |
|of: resolver: Add of_node_put() before return and break					 |	修复从for_each_child_of_node循环中break/return时没有put node而导致内存泄漏的问题 |
|iommu: Properly export iommu_group_get_for_dev()						 |	修复一个iommu core api未使用EXPORT_SYMBOL_GPL导出的问题。是drivers/iommu: Export core IOMMU API symbols to permit modular drivers的后置补丁|
|evm: Check also if *tfm is an error pointer in init_desc()				 |	修补一种在多线程场景下可能的竞争状态|
|evm: Fix a small race in init_desc()									 |	在极端条件下，即便使用了 IS_ERR_OR_NULL() 也会出现竞争状态：其内部会针对 error pointer 和 NULL 做两次判断，而竞争状态可能出现在两次判断之间|
|selinux: reorder hooks to make runtime disable less broken				 |	由于该补丁（v5.6）于 LSM Blob 机制（v5.1）之后合入，一些 hooks 在 4.19 上的实现逻辑与该补丁合入时的有变化，因此它们的位置需要进一步调整|				
 
 
Link:https://gitee.com/openeuler/kernel/pulls/415 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      18e32b66
  7. 25 2月, 2023 13 次提交
  9. 23 2月, 2023 1 次提交
  11. 22 2月, 2023 1 次提交
    • W
      mm/sharepool: Fix null-pointer-deference in sp_free_area · 77978cd7
      由 Wang Wensheng 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6G76L
CVE: NA

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

When a process is deleted from a group, the process does not apply for
memory from the shared group. Otherwise, the UAF problem occurs. We checked
this, but it didn't do a good job of preventing sp_alloc and del_task
concurrency. The process applies for memory after passing the check, which
violates our requirements and causes problems. The solution is to place the
checked code in the critical area to ensure that no memory can be allocated
after the check is passed.

[ T7596] Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000098
[ T7596] Mem abort info:
[ T7596]   ESR = 0x96000004
[ T7596]   EC = 0x25: DABT (current EL), IL = 32 bits
[ T7596]   SET = 0, FnV = 0
[ T7596]   EA = 0, S1PTW = 0
[ T7596] Data abort info:
[ T7596]   ISV = 0, ISS = 0x00000004
[ T7596]   CM = 0, WnR = 0
[ T7596] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001040a3000
[ T7596] [0000000000000098] pgd=0000000000000000, p4d=0000000000000000
[ T7596] Internal error: Oops: 96000004 [#1] SMP
[ T7596] Modules linked in: sharepool_dev(OE) [last unloaded: demo]
[ T7596] CPU: 1 PID: 7596 Comm: test_sp_group_d Tainted: G OE 5.10.0+ #8
[ T7596] Hardware name: linux,dummy-virt (DT)
[ T7596] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
[ T7596] pc : sp_free_area+0x34/0x120
[ T7596] lr : sp_free_area+0x30/0x120
[ T7596] sp : ffff80001c6a3b20
[ T7596] x29: ffff80001c6a3b20 x28: 0000000000000009
[ T7596] x27: 0000000000000000 x26: ffff800011c49d20
[ T7596] x25: ffff0000c227f6c0 x24: 0000000000000008
[ T7596] x23: ffff0000c0cf0ce8 x22: 0000000000000001
[ T7596] x21: ffff0000c4082b30 x20: 0000000000000000
[ T7596] x19: ffff0000c4082b00 x18: 0000000000000000
[ T7596] x17: 0000000000000000 x16: 0000000000000000
[ T7596] x15: 0000000000000000 x14: 0000000000000000
[ T7596] x13: 0000000000000000 x12: ffff0005fffe12c0
[ T7596] x11: 0000000000000008 x10: ffff0005fffe12c0
[ T7596] x9 : ffff8000103eb690 x8 : 0000000000000001
[ T7596] x7 : 0000000000210d00 x6 : 0000000000000000
[ T7596] x5 : ffff8000123edea0 x4 : 0000000000000030
[ T7596] x3 : ffffeff000000000 x2 : 0000eff000000000
[ T7596] x1 : 0000e80000000000 x0 : 0000000000000000
[ T7596] Call trace:
[ T7596]  sp_free_area+0x34/0x120
[ T7596]  __sp_area_drop_locked+0x3c/0x60
[ T7596]  sp_area_drop+0x80/0xbc
[ T7596]  remove_vma+0x54/0x70
[ T7596]  exit_mmap+0x114/0x1d0
[ T7596]  mmput+0x90/0x1ec
[ T7596]  exit_mm+0x1d0/0x2f0
[ T7596]  do_exit+0x180/0x400
[ T7596]  do_group_exit+0x40/0x114
[ T7596]  get_signal+0x1e8/0x720
[ T7596]  do_signal+0x11c/0x1e4
[ T7596]  do_notify_resume+0x15c/0x250
[ T7596]  work_pending+0xc/0x6d8
[ T7596] Code: f9400001 f9402c00 97fff0e5 aa0003f4 (f9404c00)
[ T7596] ---[ end trace 3c8368d77e758ebd ]---
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
      77978cd7
  13. 18 2月, 2023 1 次提交
  15. 16 2月, 2023 5 次提交
  17. 15 2月, 2023 2 次提交
  19. 14 2月, 2023 3 次提交
  21. 13 2月, 2023 2 次提交