From: "John Hsu (許永翰)" <John.Hsu@mediatek.com>
To: "catalin.marinas@arm.com" <catalin.marinas@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"Xiaobing Shi (史小兵)" <Xiaobing.Shi@mediatek.com>,
"Chunhui Li (李春辉)" <chunhui.li@mediatek.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Kuan-Ying Lee (李冠穎)" <Kuan-Ying.Lee@mediatek.com>,
"Casper Li (李中榮)" <casper.li@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: [BUG kernel-5.15] aarch64: __pi_strncmp() out-of-bound error
Date: Mon, 7 Aug 2023 12:31:45 +0000 [thread overview]
Message-ID: <e9f30f7d5b7d72a3521da31ab2002b49a26f542e.camel@mediatek.com> (raw)
Hi ARM maintainers,
We met this issue under our internal test.
It seems that __pi_strncmp() reads out-of-bound.
[ 7445.268043][ T382] ueventd: [name:fault&]Unable to handle kernel
paging request at virtual address ffffff803fd3f000
[ 7445.268078][ T382] ueventd: [name:fault&]Mem abort info:
[ 7445.268084][ T382] ueventd: [name:fault&] ESR = 0x96000007
[ 7445.268089][ T382] ueventd: [name:fault&] EC = 0x25: DABT (current
EL), IL = 32 bits
[ 7445.268095][ T382] ueventd: [name:fault&] SET = 0, FnV = 0
[ 7445.268100][ T382] ueventd: [name:fault&] EA = 0, S1PTW = 0
[ 7445.268105][ T382] ueventd: [name:fault&] FSC = 0x07: level 3
translation fault
[ 7445.268110][ T382] ueventd: [name:fault&]Data abort info:
[ 7445.268115][ T382] ueventd: [name:fault&] ISV = 0, ISS =
0x00000007
[ 7445.268120][ T382] ueventd: [name:fault&] CM = 0, WnR = 0
[ 7445.268126][ T382] ueventd: [name:fault&]swapper pgtable: 4k pages,
39-bit VAs, pgdp=00000000426c6000
[ 7445.268133][ T382] ueventd: [name:fault&][ffffff803fd3f000]
pgd=1800000327ff5003, p4d=1800000327ff5003, pud=1800000327ff5003,
pmd=1800000327fef003, pte=0000000000000000
[ 7445.268154][ T382] ueventd: [name:traps&]Internal error: Oops:
96000007 [#1] PREEMPT SMP
[ 7445.268278][ T382] ueventd: [name:mrdump&]Kernel Offset:
0x2825400000 from 0xffffffc008000000
[ 7445.268286][ T382] ueventd: [name:mrdump&]PHYS_OFFSET: 0x40000000
[ 7445.268294][ T382] ueventd: [name:mrdump&]pstate: 82400005 (Nzcv
daif +PAN -UAO)
[ 7445.268301][ T382] ueventd: [name:mrdump&]pc : [0xffffffe82d420210]
__pi_strncmp+0x1a0/0x1c4
[ 7445.268310][ T382] ueventd: [name:mrdump&]lr : [0xffffffe82dbe12c0]
__security_genfs_sid+0x100/0x168
[ 7445.268319][ T382] ueventd: [name:mrdump&]sp : ffffffc0097cb8b0
…
[ 7445.269337][ T382] ueventd: CPU: 0 PID: 382 Comm: ueventd Tainted:
G S W OE 5.15.41-android13-8-gb1f1ad628628 #1
[ 7445.269347][ T382] ueventd: Hardware name: MT6886(ENG) (DT)
[ 7445.269354][ T382] ueventd: Call trace:
[ 7445.269359][ T382] ueventd: dump_backtrace+0x0/0x2a8
[ 7445.269374][ T382] ueventd: dump_stack_lvl+0x74/0xa4
[ 7445.269384][ T382] ueventd: dump_stack+0x14/0x1c
[ 7445.269391][ T382] ueventd: mrdump_common_die+0x32c/0x5ac [mrdump]
[ 7445.269470][ T382] ueventd: ipanic_die+0x1c/0x28 [mrdump]
[ 7445.269539][ T382] ueventd: __die+0xbc/0x308
[ 7445.269548][ T382] ueventd: die+0xd8/0x500
[ 7445.269556][ T382] ueventd: die_kernel_fault+0x94/0xa8
[ 7445.269565][ T382] ueventd: __do_kernel_fault+0x1d8/0x214
[ 7445.269571][ T382] ueventd: do_bad_area+0x40/0x174
[ 7445.269579][ T382] ueventd: do_translation_fault+0x48/0x54
[ 7445.269585][ T382] ueventd: do_mem_abort+0x3c/0x100
[ 7445.269592][ T382] ueventd: el1_abort+0x38/0x54
[ 7445.269602][ T382] ueventd: el1h_64_sync_handler+0x54/0x88
[ 7445.269610][ T382] ueventd: el1h_64_sync+0x78/0x7c
[ 7445.269618][ T382] ueventd: __pi_strncmp+0x1a0/0x1c4
[ 7445.269626][ T382] ueventd: selinux_genfs_get_sid+0x114/0x220
[ 7445.269636][ T382] ueventd: inode_doinit_with_dentry+0x3d0/0x598
[ 7445.269644][ T382] ueventd: selinux_d_instantiate+0x1c/0x24
[ 7445.269652][ T382] ueventd: d_splice_alias+0x5c/0x280
[ 7445.269662][ T382] ueventd: kernfs_iop_lookup+0xec/0x21c
[ 7445.269674][ T382] ueventd: __lookup_slow+0xc4/0x150
[ 7445.269684][ T382] ueventd: lookup_slow+0x40/0xf0
[ 7445.269690][ T382] ueventd: walk_component+0x144/0x160
[ 7445.269696][ T382] ueventd: link_path_walk+0x25c/0x344
[ 7445.269703][ T382] ueventd: path_lookupat+0x64/0x120
[ 7445.269710][ T382] ueventd: filename_lookup+0xc4/0x1b0
[ 7445.269718][ T382] ueventd: user_path_at_empty+0x48/0xb4
[ 7445.269725][ T382] ueventd: do_faccessat+0xa8/0x1f0
[ 7445.269732][ T382] ueventd: __arm64_sys_faccessat+0x20/0x28
[ 7445.269738][ T382] ueventd: invoke_syscall+0x3c/0xf0
[ 7445.269746][ T382] ueventd: el0_svc_common+0x84/0xe8
[ 7445.269753][ T382] ueventd: do_el0_svc+0x20/0x84
[ 7445.269759][ T382] ueventd: el0_svc+0x1c/0x48
[ 7445.269766][ T382] ueventd: el0t_64_sync_handler+0x7c/0xd8
[ 7445.269773][ T382] ueventd: el0t_64_sync+0x15c/0x160
We found that we hit this issue when we compare these two strings.
________________address|_0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F
__ 0123456789ABCDEF
NSD:FFFFFF80089EDA00|>2F 64 65 76 69 63 65 73 2F 76 69 72 74 75 61
6C /devices/virtual
NSD:FFFFFF80089EDA10| 2F 62 6C 6F 63 6B 2F 00 E0 03 01 AA E1 03 02
AA /block/.........
________________address|_0__1__2__3__4__5__6__7__8__9__A__B__C__D__E__F
__ 0123456789ABCDEF
NSD:FFFFFF803FD3EFE0| 00 00 00 00 00 00 00 00 00 00 2F 64 65 76 69
63 ........../devic
NSD:FFFFFF803FD3EFF0| 65 73>2F 76 69 72 74 75 61 6C 2F 6D 69 73 63
00 es/virtual/misc.
NSD:FFFFFF803FD3F000| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
??
NSD:FFFFFF803FD3F0E0| ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
??
We observe the second string is put at the tail of the first page and
the next page is unreadable.
Thus, we made a simple test as below and it can reproduce this issue.
static noinline void strncmp_ut(void)
{
int ret = 0;
int size = 4096;
char *src1 = vmalloc(size);
char *src2 = vmalloc(size);
char *str1 = "/devices/virtual/block/";
char *str2 = "/devices/virtual/misc";
int len1 = strlen(str1);
int len2 = strlen(str2);
char *str1_start, *str2_start;
pr_info("src1: %px\n", src1);
pr_info("src2: %px\n", src2);
pr_info("len1 :%d, len2: %d\n", len1, len2);
memset(src1, 0, size);
strncpy(&src1[size-len1-1], str1, len1);
memset(src2, 0, size);
strncpy(&src2[size-len2-1], str2, len2);
str1_start = src1 + size - len1 - 1;
pr_info("str1_start: %px", str1_start);
str2_start = src2 + size - len2 - 1;
pr_info("str2_start: %px", str2_start);
ret = strncmp(str1_start, str2_start, len1);
pr_info("ret: %d\n", ret);
}
Does any issue exist in __pi_strncmp in kernel-5.15?
Any suggestion is appreciated.
Thanks,
John Hsu
next reply other threads:[~2023-08-07 12:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 12:31 John Hsu (許永翰) [this message]
2023-08-07 15:32 ` Mark Rutland
2023-08-10 12:23 ` Robin Murphy
2023-08-10 14:31 ` Will Deacon
2023-08-10 15:00 ` Robin Murphy
2023-08-10 16:09 ` Will Deacon
2023-09-06 18:07 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e9f30f7d5b7d72a3521da31ab2002b49a26f542e.camel@mediatek.com \
--to=john.hsu@mediatek.com \
--cc=Kuan-Ying.Lee@mediatek.com \
--cc=Xiaobing.Shi@mediatek.com \
--cc=casper.li@mediatek.com \
--cc=catalin.marinas@arm.com \
--cc=chunhui.li@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox