Greg Kroah-Hartman wrote on Mon, Jan 06, 2025 at 04:17:02PM +0100:
5.10-stable review patch. If anyone has any objections, please let me know.
From: Kairui Song kasong@tencent.com
[ Upstream commit 74363ec674cb172d8856de25776c8f3103f05e2f ]
Setting backing device is done before ZRAM initialization. If we set the backing device, then remove the ZRAM module without initializing the device, the backing device reference will be leaked and the device will be hold forever.
Fix this by always reset the ZRAM fully on rmmod or reset store.
This causes a null pointer deref when reseting an uninitialized device:
armadillo:/sys/block/zram0# echo 1 > reset [ 28.054565] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 28.063377] Mem abort info: [ 28.066182] ESR = 0x96000004 [ 28.069241] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.074557] SET = 0, FnV = 0 [ 28.077612] EA = 0, S1PTW = 0 [ 28.080755] Data abort info: [ 28.083633] ISV = 0, ISS = 0x00000004 [ 28.087473] CM = 0, WnR = 0 [ 28.090445] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000464f9000 [ 28.096888] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 28.103700] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 28.109965] Modules linked in: moal(E) cfg80211(E) mlan(E) [ 28.115458] CPU: 3 PID: 1900 Comm: sh Tainted: G E 5.10.233-rc1-gbbdff754b92c #1 [ 28.124153] Hardware name: Atmark-Techno Armadillo-IoT Gateway G4 Board (DT) [ 28.131201] pstate: a0000005 (NzCv daif -PAN -UAO -TCO BTYPE=--) [ 28.137211] pc : zcomp_cpu_dead+0x20/0x70 [ 28.141220] lr : cpuhp_invoke_callback+0xd4/0x204 [ 28.145920] sp : ffff800011a1bb10 [ 28.149231] x29: ffff800011a1bb10 x28: ffff000006562580 [ 28.154542] x27: 0000000000000000 x26: ffff80001148aab8 [ 28.159855] x25: ffff800010716210 x24: 0000000000000000 [ 28.165169] x23: ffff80001149cb70 x22: 0000000000000000 [ 28.170480] x21: 0000000000000010 x20: ffff80002e856000 [ 28.175791] x19: ffff80001149d790 x18: 0000000000000000 [ 28.181102] x17: 0000000000000000 x16: 0000000000000000 [ 28.186413] x15: 0000ffff9aa2f5b0 x14: 0000000000000000 [ 28.191726] x13: ffff800011a1bc96 x12: ffff800011a1bc70 [ 28.197036] x11: 0fffffffffffffff x10: 000000000000000a [ 28.202349] x9 : 0000000000000000 x8 : ffff000002a102b8 [ 28.207660] x7 : 0000000000000000 x6 : 0000000000000040 [ 28.212973] x5 : ffff00003fb4f6f0 x4 : 0000000000000000 [ 28.218285] x3 : 0000000000000010 x2 : ffff80001148aab8 [ 28.223596] x1 : 0000000000000010 x0 : 0000000000000000 [ 28.228907] Call trace: [ 28.231353] zcomp_cpu_dead+0x20/0x70 [ 28.235013] cpuhp_invoke_callback+0xd4/0x204 [ 28.239370] cpuhp_issue_call+0x168/0x1b4 [ 28.243378] __cpuhp_state_remove_instance+0x144/0x1f0 [ 28.248513] zcomp_destroy+0x24/0x44 [ 28.252086] zram_reset_device+0xfc/0x11c [ 28.256093] reset_store+0xa4/0x130 [ 28.259581] dev_attr_store+0x18/0x30 [ 28.263244] sysfs_kf_write+0x44/0x54 [ 28.266903] kernfs_fop_write_iter+0x134/0x1c4 [ 28.271346] new_sync_write+0xfc/0x1b0 [ 28.275093] vfs_write+0x240/0x2b0 [ 28.278492] ksys_write+0x74/0x110 [ 28.281891] __arm64_sys_write+0x1c/0x30 [ 28.285815] el0_svc_common.constprop.0+0x78/0x1c0 [ 28.290603] do_el0_svc+0x1c/0x30 [ 28.293916] el0_svc+0x10/0x20 [ 28.296968] el0_sync_handler+0x108/0x114 [ 28.300975] el0_sync+0x180/0x1c0 [ 28.304290] Code: 912ae042 a90153f3 f90013f5 f8605854 (f85f0033) [ 28.310382] ---[ end trace e91dc675f5f4a195 ]---
I'll look a bit more into it today and reply to this mail with anything I've found. (didn't test on master or anything else either)