The following kernel null pointer dereference is noticed on qemu-arm64 while running kunit tests with the Linux next-20240603 tag kernel.
This is always reproducible and the system is stable after this.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Boot log: ----------- <6>[ 114.143436] # Subtest: kunit_fault <6>[ 114.143983] # module: kunit_test <6>[ 114.144252] 1..1 <1>[ 114.150801] Unable to handle kernel paging request at virtual address dfff800000000000 <1>[ 114.151837] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] <1>[ 114.153897] Mem abort info: <1>[ 114.154370] ESR = 0x0000000096000005 <1>[ 114.155537] EC = 0x25: DABT (current EL), IL = 32 bits <1>[ 114.156222] SET = 0, FnV = 0 <1>[ 114.157238] EA = 0, S1PTW = 0 <1>[ 114.157971] FSC = 0x05: level 1 translation fault <1>[ 114.158886] Data abort info: <1>[ 114.159543] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 <1>[ 114.161296] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 <1>[ 114.161892] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 <1>[ 114.162950] [dfff800000000000] address between user and kernel address ranges <0>[ 114.164434] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP <4>[ 114.164730] Modules linked in: <4>[ 114.164974] CPU: 0 PID: 601 Comm: kunit_try_catch Tainted: G B N 6.10.0-rc1-next-20240603 #1 <4>[ 114.165058] Tainted: [B]=BAD_PAGE, [N]=TEST <4>[ 114.165088] Hardware name: linux,dummy-virt (DT) <4>[ 114.165198] pstate: 12400009 (nzcV daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) <4>[ 114.165290] pc : kunit_test_null_dereference+0x70/0x170 <4>[ 114.165390] lr : kunit_generic_run_threadfn_adapter+0x88/0x100 <4>[ 114.165446] sp : ffff800082d97dc0 <4>[ 114.165513] x29: ffff800082d97e20 x28: 0000000000000000 x27: 0000000000000000 <4>[ 114.165678] x26: 0000000000000000 x25: 0000000000000000 x24: fff00000c1dec280 <4>[ 114.165763] x23: ffff9bc22413e7c0 x22: ffff9bc2241469f8 x21: fff00000c1dec288 <4>[ 114.165846] x20: 1ffff000105b2fb8 x19: ffff8000800879f0 x18: 0000000000000068 <4>[ 114.165929] x17: ffff9bc2231cf524 x16: ffff9bc2231cf29c x15: ffff9bc2240feb9c <4>[ 114.166014] x14: ffff9bc22384b8d0 x13: 6461657268745f68 x12: fffd8000195d88b2 <4>[ 114.166098] x11: 1ffe0000195d88b1 x10: fffd8000195d88b1 x9 : ffff9bc22413e848 <4>[ 114.166219] x8 : ffff800082d97cb8 x7 : 0000000000000000 x6 : 0000000041b58ab3 <4>[ 114.166302] x5 : ffff7000105b2fb8 x4 : 00000000f1f1f1f1 x3 : 0000000000000003 <4>[ 114.166383] x2 : dfff800000000000 x1 : fff00000caec3cc0 x0 : ffff8000800879f0 <4>[ 114.166494] Call trace: <4>[ 114.166526] kunit_test_null_dereference+0x70/0x170 <4>[ 114.166585] kunit_generic_run_threadfn_adapter+0x88/0x100 <4>[ 114.166638] kthread+0x24c/0x2d0 <4>[ 114.166687] ret_from_fork+0x10/0x20 <0>[ 114.167025] Code: b90004a3 d5384101 52800063 aa0003f3 (39c00042) <4>[ 114.167311] ---[ end trace 0000000000000000 ]--- <3>[ 114.184100] # kunit_test_fault_null_dereference: try faulted: last line seen lib/kunit/kunit-test.c:95 <6>[ 114.189639] ok 1 kunit_test_fault_null_dereference
metadata: git_ref: master git_describe: next-20240603 git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
Links: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240603/tes... - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1PsJeaL7kuebSowrou... - https://storage.tuxsuite.com/public/linaro/lkft/builds/2hM1PsJeaL7kuebSowrou...
-- Linaro LKFT https://lkft.linaro.org
On Mon, Jun 03, 2024 at 07:39:24PM +0530, Naresh Kamboju wrote:
The following kernel null pointer dereference is noticed on qemu-arm64 while running kunit tests with the Linux next-20240603 tag kernel.
This is always reproducible and the system is stable after this.
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
These are intentional... The function name just changed so it's showing up as a new bug. I tried to add a big printk before this NULL dereference but the printk message never showed up in dmesg...
+ kunit_info(test, "Testing that a NULL dereference causes a test failure\n"); + kunit_info(test, "*** This will lead to an intentional stack trace ***\n");
regards, dan carpenter