Larry Finger <Larry.Finger(a)gmail.com> wrote:
> As discussed in the links below, the SDIO part of RTW8821CS fails to
> start correctly if such startup happens while the UART portion of
> the chip is initializing.
I checked with SDIO team internally, but they didn't meet this case, so we may
take this workaround.
SDIO team wonder if something other than BT cause this failure, and after
system boots everything will be well. Could you boot the system without WiFi/BT
drivers, but insmod drivers manually after booting?
> ---
> drivers/net/wireless/realtek/rtw88/sdio.c | 28 +++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
> index 0cae5746f540..eec0ad85be72 100644
> --- a/drivers/net/wireless/realtek/rtw88/sdio.c
> +++ b/drivers/net/wireless/realtek/rtw88/sdio.c
> @@ -1325,6 +1325,34 @@ int rtw_sdio_probe(struct sdio_func *sdio_func,
[...]
> + mdelay(500);
Will it better to use sleep function?
As discussed in the links below, the SDIO part of RTW8821CS fails to
start correctly if such startup happens while the UART portion of
the chip is initializing. The logged results with such failure is
[ 10.230516] rtw_8821cs mmc3:0001:1: Start of rtw_sdio_probe
[ 10.306569] Bluetooth: HCI UART driver ver 2.3
[ 10.306717] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 10.307167] of_dma_request_slave_channel: dma-names property of node '/serial@fe650000' missing or empty
[ 10.307199] dw-apb-uart fe650000.serial: failed to request DMA
[ 10.543474] rtw_8821cs mmc3:0001:1: Firmware version 24.8.0, H2C version 12
[ 10.730744] rtw_8821cs mmc3:0001:1: sdio read32 failed (0x11080): -110
[ 10.730923] rtw_8821cs mmc3:0001:1: sdio write32 failed (0x11080): -110
Due to the above errors, wifi fails to work.
For those instances when wifi works, the following is logged:
[ 10.452861] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 10.453580] of_dma_request_slave_channel: dma-names property of node '/serial@fe650000' missing or empty
[ 10.453621] dw-apb-uart fe650000.serial: failed to request DMA
[ 10.455741] rtw_8821cs mmc3:0001:1: Start of rtw_sdio_probe
[ 10.639186] rtw_8821cs mmc3:0001:1: Firmware version 24.8.0, H2C version 12
In this case, SDIO wifi works correctly. The correct case is ensured by
adding an mdelay(500) statement before the call to rtw_core_init(). No
adverse effects are observed.
Link: https://1EHFQ.trk.elasticemail.com/tracking/click?d=1UfsVowwwMAM6kBoyumkHP3…
Link: https://1EHFQ.trk.elasticemail.com/tracking/click?d=XUEf4t8W9xt0czASPOeeDt8…
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Signed-off-by: Larry Finger <Larry.Finger(a)gmail.com>
Cc: stable(a)vger.kernel.org # v6.4+
---
drivers/net/wireless/realtek/rtw88/sdio.c | 28 +++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/sdio.c b/drivers/net/wireless/realtek/rtw88/sdio.c
index 0cae5746f540..eec0ad85be72 100644
--- a/drivers/net/wireless/realtek/rtw88/sdio.c
+++ b/drivers/net/wireless/realtek/rtw88/sdio.c
@@ -1325,6 +1325,34 @@ int rtw_sdio_probe(struct sdio_func *sdio_func,
rtwdev->hci.ops = &rtw_sdio_ops;
rtwdev->hci.type = RTW_HCI_TYPE_SDIO;
+ /* Insert a delay of 500 ms. Without the delay, the wifi part
+ * and the UART that controls Bluetooth interfere with one
+ * another resulting in the following being logged:
+ *
+ * Start of SDIO probe function.
+ * Bluetooth: HCI UART driver ver 2.3
+ * Bluetooth: HCI UART protocol Three-wire (H5) registered
+ * of_dma_request_slave_channel: dma-names property of node '/serial@fe650000'
+ * missing or empty
+ * dw-apb-uart fe650000.serial: failed to request DMA
+` * rtw_8821cs mmc3:0001:1: Firmware version 24.8.0, H2C version 12
+ * rtw_8821cs mmc3:0001:1: sdio read32 failed (0x11080): -110
+ *
+ * If the UART is finished initializing before the SDIO probe
+ * function startw, the following is logged:
+ *
+ * Bluetooth: HCI UART protocol Three-wire (H5) registered
+ * of_dma_request_slave_channel: dma-names property of node '/serial@fe650000'
+ * missing or empty
+ * dw-apb-uart fe650000.serial: failed to request DMA
+ * Start of SDIO probe function.
+ * rtw_8821cs mmc3:0001:1: Firmware version 24.8.0, H2C version 12
+ * Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
+ * SDIO wifi works correctly.
+ *
+ * No adverse effects are observed from the delay.
+ */
+ mdelay(500);
ret = rtw_core_init(rtwdev);
if (ret)
goto err_release_hw;
--
2.44.0
https://1EHFQ.trk.elasticemail.com/tracking/unsubscribe?d=XjvOA0R6jwFES_UmJ…
On Wed, Apr 10, 2024 at 10:31 PM Cem Topcuoglu
<topcuoglu.c(a)northeastern.edu> wrote:
>
> Hi,
>
>
>
> We encountered a bug labelled “KASAN: slab-out-of-bounds Write in ops_init” while fuzzing kernel version 5.15.124 with Syzkaller (lines exist in 5.15.154 as well).
>
>
>
> In the net_namespace.c file, we have an if condition at line 89. Subsequently, Syzkaller encounters the bug at line 90.
>
>
>
> 89 if (old_ng->s.len > id) {
>
> 90 old_ng->ptr[id] = data;
>
> 91 return 0;
>
> 92 }
>
>
>
> Upon inspecting the net_generic struct, we noticed that this struct uses union which puts the array and the header (including the array length information) together.
>
> We suspect that with this union, modifying the ng->ptr[0] is essentially modifying ng->s.len, which might fail the check in 89. This might be the cause for Syzkaller detecting this slab-out-of-bound.
>
Look for MIN_PERNET_OPS_ID (this should be 3)
ng->ptr[0] , [1], [2] can not be overwritten.
Do you have a repro ?
Also please use the latest stable (5.15.154).
> Since we are CS PhD students and Linux hobbyists, we do not have a full understanding of what could lead to this. We would really appreciate if you guys can share some insights into this matter : )
>
>
>
> We attached the syzkaller’s bug report below.
>
>
>
> ==================================================================
>
> BUG: KASAN: slab-out-of-bounds in net_assign_generic
>
> usr/src/kernel/net/core/net_namespace.c:90 [inline]
>
> BUG: KASAN: slab-out-of-bounds in ops_init+0x44b/0x4d0
>
> usr/src/kernel/net/core/net_namespace.c:129
>
> Write of size 8 at addr ffff888043c62ae8 by task (coredump)/5424
>
> CPU: 1 PID: 5424 Comm: (coredump) Not tainted 5.15.124-yocto-standard #1
>
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
>
> Call Trace:
>
> <TASK>
>
> __dump_stack usr/src/kernel/lib/dump_stack.c:88 [inline]
>
> dump_stack_lvl+0x51/0x70 usr/src/kernel/lib/dump_stack.c:106
>
> print_address_description.constprop.0+0x24/0x140 usr/src/kernel/mm/kasan/report.c:248
>
> __kasan_report usr/src/kernel/mm/kasan/report.c:434 [inline]
>
> kasan_report.cold+0x7d/0x117 usr/src/kernel/mm/kasan/report.c:451
>
> __asan_report_store8_noabort+0x17/0x20 usr/src/kernel/mm/kasan/report_generic.c:314
>
> net_assign_generic usr/src/kernel/net/core/net_namespace.c:90 [inline]
>
> ops_init+0x44b/0x4d0 usr/src/kernel/net/core/net_namespace.c:129
>
> setup_net+0x40a/0x970 usr/src/kernel/net/core/net_namespace.c:329
>
> copy_net_ns+0x2ac/0x680 usr/src/kernel/net/core/net_namespace.c:473
>
> create_new_namespaces+0x390/0xa50 usr/src/kernel/kernel/nsproxy.c:110
>
> unshare_nsproxy_namespaces+0xb0/0x1d0 usr/src/kernel/kernel/nsproxy.c:226
>
> ksys_unshare+0x30c/0x850 usr/src/kernel/kernel/fork.c:3094
>
> __do_sys_unshare usr/src/kernel/kernel/fork.c:3168 [inline]
>
> __se_sys_unshare usr/src/kernel/kernel/fork.c:3166 [inline]
>
> __x64_sys_unshare+0x36/0x50 usr/src/kernel/kernel/fork.c:3166
>
> do_syscall_x64 usr/src/kernel/arch/x86/entry/common.c:50 [inline]
>
> do_syscall_64+0x40/0x90 usr/src/kernel/arch/x86/entry/common.c:80
>
> entry_SYSCALL_64_after_hwframe+0x61/0xcb
>
> RIP: 0033:0x7fbafce1b39b
>
> Code: 73 01 c3 48 8b 0d 85 2a 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00
>
> 00 90 f3 0f 1e fa b8 10 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 2a 0e 00 f7
>
> d8 64 89 01 48
>
> RSP: 002b:00007ffddc8dfda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
>
> RAX: ffffffffffffffda RBX: 0000557e645dd018 RCX: 00007fbafce1b39b
>
> RDX: 0000000000000000 RSI: 00007ffddc8dfd10 RDI: 0000000040000000
>
> RBP: 00007ffddc8dfde0 R08: 0000000000000000 R09: 00007ffd00000067
>
> R10: 0000000000000000 R11: 0000000000000246 R12: 00000000fffffff5
>
> R13: 00007fbafd26ba60 R14: 0000000040000000 R15: 0000000000000000
>
> </TASK>
>
> Allocated by task 5424:
>
> kasan_save_stack+0x26/0x60 usr/src/kernel/mm/kasan/common.c:38
>
> kasan_set_track usr/src/kernel/mm/kasan/common.c:46 [inline]
>
> set_alloc_info usr/src/kernel/mm/kasan/common.c:434 [inline]
>
> ____kasan_kmalloc usr/src/kernel/mm/kasan/common.c:513 [inline]
>
> ____kasan_kmalloc usr/src/kernel/mm/kasan/common.c:472 [inline]
>
> __kasan_kmalloc+0xae/0xe0 usr/src/kernel/mm/kasan/common.c:522
>
> kasan_kmalloc usr/src/kernel/include/linux/kasan.h:264 [inline]
>
> __kmalloc+0x308/0x560 usr/src/kernel/mm/slub.c:4407
>
> kmalloc usr/src/kernel/include/linux/slab.h:596 [inline]
>
> kzalloc usr/src/kernel/include/linux/slab.h:721 [inline]
>
> net_alloc_generic+0x28/0x80 usr/src/kernel/net/core/net_namespace.c:74
>
> net_alloc usr/src/kernel/net/core/net_namespace.c:401 [inline]
>
> copy_net_ns+0xc3/0x680 usr/src/kernel/net/core/net_namespace.c:460
>
> create_new_namespaces+0x390/0xa50 usr/src/kernel/kernel/nsproxy.c:110
>
> unshare_nsproxy_namespaces+0xb0/0x1d0 usr/src/kernel/kernel/nsproxy.c:226
>
> ksys_unshare+0x30c/0x850 usr/src/kernel/kernel/fork.c:3094
>
> __do_sys_unshare usr/src/kernel/kernel/fork.c:3168 [inline]
>
> __se_sys_unshare usr/src/kernel/kernel/fork.c:3166 [inline]
>
> __x64_sys_unshare+0x36/0x50 usr/src/kernel/kernel/fork.c:3166
>
> do_syscall_x64 usr/src/kernel/arch/x86/entry/common.c:50 [inline]
>
> do_syscall_64+0x40/0x90 usr/src/kernel/arch/x86/entry/common.c:80
>
> entry_SYSCALL_64_after_hwframe+0x61/0xcb
>
> The buggy address belongs to the object at ffff888043c62a00
>
> which belongs to the cache kmalloc-256 of size 256
>
> The buggy address is located 232 bytes inside of
>
> 256-byte region [ffff888043c62a00, ffff888043c62b00)
>
> The buggy address belongs to the page:
>
> page:000000008dd0a6b6 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x43c62
>
> head:000000008dd0a6b6 order:1 compound_mapcount:0
>
> flags: 0x4000000000010200(slab|head|zone=1)
>
> raw: 4000000000010200 ffffea0001108f00 0000000700000007 ffff888001041b40
>
> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
>
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>
> ffff888043c62980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> ffff888043c62a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> >ffff888043c62a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
>
> ^
>
> ffff888043c62b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> ffff888043c62b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> ==================================================================
>
> kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
>
>
>
> Best
>
>
Hi,
We encountered a bug labelled “KASAN: slab-out-of-bounds Write in ops_init” while fuzzing kernel version 5.15.124 with Syzkaller (lines exist in 5.15.154 as well).
In the net_namespace.c file, we have an if condition at line 89. Subsequently, Syzkaller encounters the bug at line 90.
89 if (old_ng->s.len > id) {
90 old_ng->ptr[id] = data;
91 return 0;
92 }
Upon inspecting the net_generic struct, we noticed that this struct uses union which puts the array and the header (including the array length information) together.
We suspect that with this union, modifying the ng->ptr[0] is essentially modifying ng->s.len, which might fail the check in 89. This might be the cause for Syzkaller detecting this slab-out-of-bound.
Since we are CS PhD students and Linux hobbyists, we do not have a full understanding of what could lead to this. We would really appreciate if you guys can share some insights into this matter : )
We attached the syzkaller’s bug report below.
==================================================================
BUG: KASAN: slab-out-of-bounds in net_assign_generic
usr/src/kernel/net/core/net_namespace.c:90 [inline]
BUG: KASAN: slab-out-of-bounds in ops_init+0x44b/0x4d0
usr/src/kernel/net/core/net_namespace.c:129
Write of size 8 at addr ffff888043c62ae8 by task (coredump)/5424
CPU: 1 PID: 5424 Comm: (coredump) Not tainted 5.15.124-yocto-standard #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
<TASK>
__dump_stack usr/src/kernel/lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x51/0x70 usr/src/kernel/lib/dump_stack.c:106
print_address_description.constprop.0+0x24/0x140 usr/src/kernel/mm/kasan/report.c:248
__kasan_report usr/src/kernel/mm/kasan/report.c:434 [inline]
kasan_report.cold+0x7d/0x117 usr/src/kernel/mm/kasan/report.c:451
__asan_report_store8_noabort+0x17/0x20 usr/src/kernel/mm/kasan/report_generic.c:314
net_assign_generic usr/src/kernel/net/core/net_namespace.c:90 [inline]
ops_init+0x44b/0x4d0 usr/src/kernel/net/core/net_namespace.c:129
setup_net+0x40a/0x970 usr/src/kernel/net/core/net_namespace.c:329
copy_net_ns+0x2ac/0x680 usr/src/kernel/net/core/net_namespace.c:473
create_new_namespaces+0x390/0xa50 usr/src/kernel/kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xb0/0x1d0 usr/src/kernel/kernel/nsproxy.c:226
ksys_unshare+0x30c/0x850 usr/src/kernel/kernel/fork.c:3094
__do_sys_unshare usr/src/kernel/kernel/fork.c:3168 [inline]
__se_sys_unshare usr/src/kernel/kernel/fork.c:3166 [inline]
__x64_sys_unshare+0x36/0x50 usr/src/kernel/kernel/fork.c:3166
do_syscall_x64 usr/src/kernel/arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x40/0x90 usr/src/kernel/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fbafce1b39b
Code: 73 01 c3 48 8b 0d 85 2a 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00
00 90 f3 0f 1e fa b8 10 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 2a 0e 00 f7
d8 64 89 01 48
RSP: 002b:00007ffddc8dfda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 0000557e645dd018 RCX: 00007fbafce1b39b
RDX: 0000000000000000 RSI: 00007ffddc8dfd10 RDI: 0000000040000000
RBP: 00007ffddc8dfde0 R08: 0000000000000000 R09: 00007ffd00000067
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000fffffff5
R13: 00007fbafd26ba60 R14: 0000000040000000 R15: 0000000000000000
</TASK>
Allocated by task 5424:
kasan_save_stack+0x26/0x60 usr/src/kernel/mm/kasan/common.c:38
kasan_set_track usr/src/kernel/mm/kasan/common.c:46 [inline]
set_alloc_info usr/src/kernel/mm/kasan/common.c:434 [inline]
____kasan_kmalloc usr/src/kernel/mm/kasan/common.c:513 [inline]
____kasan_kmalloc usr/src/kernel/mm/kasan/common.c:472 [inline]
__kasan_kmalloc+0xae/0xe0 usr/src/kernel/mm/kasan/common.c:522
kasan_kmalloc usr/src/kernel/include/linux/kasan.h:264 [inline]
__kmalloc+0x308/0x560 usr/src/kernel/mm/slub.c:4407
kmalloc usr/src/kernel/include/linux/slab.h:596 [inline]
kzalloc usr/src/kernel/include/linux/slab.h:721 [inline]
net_alloc_generic+0x28/0x80 usr/src/kernel/net/core/net_namespace.c:74
net_alloc usr/src/kernel/net/core/net_namespace.c:401 [inline]
copy_net_ns+0xc3/0x680 usr/src/kernel/net/core/net_namespace.c:460
create_new_namespaces+0x390/0xa50 usr/src/kernel/kernel/nsproxy.c:110
unshare_nsproxy_namespaces+0xb0/0x1d0 usr/src/kernel/kernel/nsproxy.c:226
ksys_unshare+0x30c/0x850 usr/src/kernel/kernel/fork.c:3094
__do_sys_unshare usr/src/kernel/kernel/fork.c:3168 [inline]
__se_sys_unshare usr/src/kernel/kernel/fork.c:3166 [inline]
__x64_sys_unshare+0x36/0x50 usr/src/kernel/kernel/fork.c:3166
do_syscall_x64 usr/src/kernel/arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x40/0x90 usr/src/kernel/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x61/0xcb
The buggy address belongs to the object at ffff888043c62a00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 232 bytes inside of
256-byte region [ffff888043c62a00, ffff888043c62b00)
The buggy address belongs to the page:
page:000000008dd0a6b6 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x43c62
head:000000008dd0a6b6 order:1 compound_mapcount:0
flags: 0x4000000000010200(slab|head|zone=1)
raw: 4000000000010200 ffffea0001108f00 0000000700000007 ffff888001041b40
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888043c62980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888043c62a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888043c62a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
^
ffff888043c62b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888043c62b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
Best
The patch titled
Subject: fork: defer linking file vma until vma is fully initialized
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Miaohe Lin <linmiaohe(a)huawei.com>
Subject: fork: defer linking file vma until vma is fully initialized
Date: Wed, 10 Apr 2024 17:14:41 +0800
Thorvald reported a WARNING [1]. And the root cause is below race:
CPU 1 CPU 2
fork hugetlbfs_fallocate
dup_mmap hugetlbfs_punch_hole
i_mmap_lock_write(mapping);
vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree.
i_mmap_unlock_write(mapping);
hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem!
i_mmap_lock_write(mapping);
hugetlb_vmdelete_list
vma_interval_tree_foreach
hugetlb_vma_trylock_write -- Vma_lock is cleared.
tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem!
hugetlb_vma_unlock_write -- Vma_lock is assigned!!!
i_mmap_unlock_write(mapping);
hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside
i_mmap_rwsem lock while vma lock can be used in the same time. Fix this
by deferring linking file vma until vma is fully initialized. Those vmas
should be initialized first before they can be used.
Link: https://lkml.kernel.org/r/20240410091441.3539905-1-linmiaohe@huawei.com
Fixes: 8d9bfb260814 ("hugetlb: add vma based lock for pmd sharing")
Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com>
Reported-by: Thorvald Natvig <thorvald(a)google.com>
Closes: https://lore.kernel.org/linux-mm/20240129161735.6gmjsswx62o4pbja@revolver/T/ [1]
Cc: Christian Brauner <brauner(a)kernel.org>
Cc: Heiko Carstens <hca(a)linux.ibm.com>
Cc: Jane Chu <jane.chu(a)oracle.com>
Cc: Kent Overstreet <kent.overstreet(a)linux.dev>
Cc: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Mateusz Guzik <mjguzik(a)gmail.com>
Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org>
Cc: Miaohe Lin <linmiaohe(a)huawei.com>
Cc: Muchun Song <muchun.song(a)linux.dev>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Peng Zhang <zhangpeng.00(a)bytedance.com>
Cc: Tycho Andersen <tandersen(a)netflix.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/fork.c | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
--- a/kernel/fork.c~fork-defer-linking-file-vma-until-vma-is-fully-initialized
+++ a/kernel/fork.c
@@ -714,6 +714,23 @@ static __latent_entropy int dup_mmap(str
} else if (anon_vma_fork(tmp, mpnt))
goto fail_nomem_anon_vma_fork;
vm_flags_clear(tmp, VM_LOCKED_MASK);
+ /*
+ * Copy/update hugetlb private vma information.
+ */
+ if (is_vm_hugetlb_page(tmp))
+ hugetlb_dup_vma_private(tmp);
+
+ /*
+ * Link the vma into the MT. After using __mt_dup(), memory
+ * allocation is not necessary here, so it cannot fail.
+ */
+ vma_iter_bulk_store(&vmi, tmp);
+
+ mm->map_count++;
+
+ if (tmp->vm_ops && tmp->vm_ops->open)
+ tmp->vm_ops->open(tmp);
+
file = tmp->vm_file;
if (file) {
struct address_space *mapping = file->f_mapping;
@@ -730,25 +747,9 @@ static __latent_entropy int dup_mmap(str
i_mmap_unlock_write(mapping);
}
- /*
- * Copy/update hugetlb private vma information.
- */
- if (is_vm_hugetlb_page(tmp))
- hugetlb_dup_vma_private(tmp);
-
- /*
- * Link the vma into the MT. After using __mt_dup(), memory
- * allocation is not necessary here, so it cannot fail.
- */
- vma_iter_bulk_store(&vmi, tmp);
-
- mm->map_count++;
if (!(tmp->vm_flags & VM_WIPEONFORK))
retval = copy_page_range(tmp, mpnt);
- if (tmp->vm_ops && tmp->vm_ops->open)
- tmp->vm_ops->open(tmp);
-
if (retval) {
mpnt = vma_next(&vmi);
goto loop_out;
_
Patches currently in -mm which might be from linmiaohe(a)huawei.com are
mm-memory-failure-fix-deadlock-when-hugetlb_optimize_vmemmap-is-enabled.patch
fork-defer-linking-file-vma-until-vma-is-fully-initialized.patch
Hi Greg, Sasha, Thadeu,
Today there was mentioning of
https://www.jmpeax.dev/The-tale-of-a-GSM-Kernel-LPE.html
a LPE from the n_gsm module. I do realize, Thadeu mentioned the
possible attack surface already back in
https://lore.kernel.org/all/ZMuRoDbMcQrsCs3m@quatroqueijos.cascardo.eti.br/…
Published exploits are referenced as well through the potential
initial finder in https://github.com/YuriiCrimson/ExploitGSM .
While 67c37756898a ("tty: n_gsm: require CAP_NET_ADMIN to attach
N_GSM0710 ldisc") is not the fix itself, it helps mitigating against
this issue.
Thus can you consider applying this still to the stable series as
needed? I think it should go at least back to 5.15.y but if
Iunderstood Thadeu correctly then even further back to the still
supported stable branches.
What do you think?
Regards,
Salvatore