- Linux-stable-mirror - lists.linaro.org

stable-rc/linux-6.6.y: new boot regression: WARNING at drivers/base/core.c:2515 device_release+0x80/...

by KernelCI bot

Hello, New boot regression found on stable-rc/linux-6.6.y: WARNING at drivers/base/core.c:2515 device_release+0x80/0x90 [logspec:generic_linux_boot,linux.kernel.warning] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:18a6cd3bd705698b4… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:18a6cd3bd705698b4… Log excerpt: [ 10.292722] mtk-wdt 10007000.watchdog: Watchdog enabled (timeout=31 sec, nowayout=0) [ 10.300525] Device 'conn' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. [ 10.300855] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.312539] WARNING: CPU: 4 PID: 76 at drivers/base/core.c:2515 device_release+0x80/0x90 [ 10.320803] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.328862] Modules linked in: videodev(+) [ 10.337116] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.337122] ecdh_generic [ 10.344606] videodev: Linux video capture interface: v2.00 [ 10.344795] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344808] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344813] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344820] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344825] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344829] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344862] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.344867] OF: graph: no port node found in /soc/spi@11012000/cros-ec@0/typec/connector@0 [ 10.349449] ecc mtk_mutex cfg80211(+) cros_ec_typec(+) pwm_bl videobuf2_common mtk_rpmsg mtk_mmsys mc rfkill elan_i2c auxadc_thermal sbs_battery mtk_pmic_keys mtk_wdt(+) pwm_mediatek mtk_scp_ipi mt6577_auxadc backlight [ 10.443014] CPU: 4 PID: 76 Comm: kworker/u18:7 Tainted: G W 6.6.76-rc1 #1 [ 10.451183] Hardware name: Google juniper sku16 board (DT) [ 10.456659] Workqueue: events_unbound deferred_probe_work_func [ 10.462491] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.469443] pc : device_release+0x80/0x90 [ 10.473443] lr : device_release+0x80/0x90 [ 10.477441] sp : ffff8000806a3a80 [ 10.480744] x29: ffff8000806a3a80 x28: 0000000000000000 x27: 0000000000000000 [ 10.487871] x26: 0000000000000000 x25: 0000000000000000 x24: ffffb3a8b7360500 [ 10.494998] x23: 0000000000000000 x22: 0000000000000000 x21: ffffb3a8b735db90 [ 10.502124] x20: 0000000000000000 x19: ffff514146120880 x18: 0000000000000006 [ 10.509250] x17: 61206e656b6f7262 x16: 207369207469202c x15: 6e6f6974636e7566 [ 10.516376] x14: 202928657361656c x13: 2e7473722e746365 x12: 6a626f6b2f697061 [ 10.523502] x11: 2d65726f632f6e6f x10: 697461746e656d75 x9 : 6572206120657661 [ 10.530628] x8 : 6820746f6e207365 x7 : 205d353235303033 x6 : 332e30312020205b [ 10.537754] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff [ 10.544880] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff514140e28f00 [ 10.552007] Call trace: [ 10.554442] device_release+0x80/0x90 [ 10.558095] kobject_put+0xa4/0x120 [ 10.561577] put_device+0x14/0x24 [ 10.564881] genpd_remove+0x118/0x1bc [ 10.568534] pm_genpd_remove+0x2c/0x50 [ 10.572274] scpsys_probe+0x13c/0x218 [ 10.575927] platform_probe+0x68/0xc4 [ 10.579579] really_probe+0x148/0x2ac [ 10.583232] __driver_probe_device+0x78/0x12c [ 10.587579] driver_probe_device+0xd8/0x15c [ 10.591754] __device_attach_driver+0xb8/0x134 [ 10.596188] bus_for_each_drv+0x84/0xe0 [ 10.600015] __device_attach+0x9c/0x188 [ 10.603841] device_initial_probe+0x14/0x20 [ 10.608015] bus_probe_device+0xac/0xb0 [ 10.611841] deferred_probe_work_func+0x88/0xc0 [ 10.616361] process_one_work+0x148/0x2a0 [ 10.620364] worker_thread+0x324/0x43c [ 10.624104] kthread+0x114/0x118 [ 10.627323] ret_from_fork+0x10/0x20 # Hardware platforms affected: ## mt8183-kukui-jacuzzi-juniper-sku16 - Compatibles: google,juniper-sku16 | google,juniper | mediatek,mt8183 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a173d8661a7bc874… #kernelci issue maestro:18a6cd3bd705698b41106eef2a1d7f2e411c7aab Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 3 days

1
0
0 0

stable-rc/linux-6.6.y: new boot regression: NULL pointer dereference at virtual address 000000000000...

by KernelCI bot

Hello, New boot regression found on stable-rc/linux-6.6.y: NULL pointer dereference at virtual address 0000000000000030 [logspec:generic_linux_boot,linux.kernel.null_pointer_dereference] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:295973ea60dd4385e… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:295973ea60dd4385e… Log excerpt: [ 4.896353] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 [ 4.896354] Mem abort info: [ 4.896355] ESR = 0x0000000096000004 [ 4.896356] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.896357] SET = 0, FnV = 0 [ 4.896358] EA = 0, S1PTW = 0 [ 4.896358] FSC = 0x04: level 0 translation fault [ 4.896360] Data abort info: [ 4.896366] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.896367] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.896368] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.896369] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001089d9000 [ 4.896370] [0000000000000030] pgd=0000000000000000, p4d=0000000000000000 [ 4.896374] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.896376] Modules linked in: mtk_mdp3(+) v4l2_mem2mem joydev ecc pcie_mediatek_gen3(+) videobuf2_dma_contig elan_i2c mtk_svs lvts_thermal r8152(+) mii cros_ec_rpmsg snd_sof_mt8195 mtk_adsp_common snd_sof_xtensa_dsp mtk_scp snd_sof_of cros_ec_sensorhub cros_kbd_led_backlight mtk_rpmsg snd_sof rpmsg_core mt6359_auxadc snd_soc_mt8195_afe mt6577_auxadc snd_sof_utils mtk_scp_ipi mtk_wdt mt8195_mt6359 uvcvideo videobuf2_vmalloc uvc videobuf2_v4l2 videobuf2_memops videobuf2_common [ 4.896396] CPU: 7 UID: 0 PID: 207 Comm: (udev-worker) Not tainted 6.13.2-rc1 #1 8f7a24f5cbfa3d4f7c9dce5f7e52657669893a6c [ 4.896399] Hardware name: Acer Tomato (rev2) board (DT) [ 4.896400] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.896402] pc : klist_put+0x28/0xf0 [ 4.896410] lr : klist_iter_exit+0x24/0x38 [ 4.896412] sp : ffff800080cab810 [ 4.896412] x29: ffff800080cab810 x28: ffffc4e77c077518 x27: 0000000000000001 [ 4.896415] x26: ffff800080cabb10 x25: ffffc4e79fb98a50 x24: ffff1beb48832bb8 [ 4.896417] x23: ffffc4e79dedd540 x22: 0000000000000000 x21: ffffc4e79d6f8f00 [ 4.896418] x20: 0000000000000000 x19: ffff1beb41095178 x18: ffffffffffffffff [ 4.896420] x17: 656469762f766564 x16: ffffc4e79d6fb3f0 x15: 2d35393138746d2c [ 4.896422] x14: ffffc4e79fe0e750 x13: 616964656d43746f x12: 0000000000000000 [ 4.896424] x11: 00353639333d4d55 x10: 0000a8fc3b570378 x9 : ffffc4e79dd32458 [ 4.896426] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 5c175b1c0b544003 [ 4.896427] x5 : 0340540b1c5b175c x4 : 0000000000000000 x3 : 0000000014f08001 [ 4.896429] x2 : 00000000dead4ead x1 : 0000000000000000 x0 : 0000000000000000 [ 4.896431] Call trace: [ 4.896432] klist_put+0x28/0xf0 (P) [ 4.896435] klist_iter_exit+0x24/0x38 [ 4.896436] bus_for_each_dev+0x90/0xe8 [ 4.896440] driver_attach+0x2c/0x40 [ 4.896442] bus_add_driver+0xec/0x218 [ 4.896443] driver_register+0x68/0x138 [ 4.896445] __platform_driver_register+0x2c/0x40 [ 4.896447] mdp_driver_init+0x28/0xff8 [mtk_mdp3 368282916f4a555c99cbc06147f8cea6ac3d5634] [ 4.896452] do_one_initcall+0x60/0x320 [ 4.896455] do_init_module+0x60/0x238 [ 4.896458] load_module+0x1cf8/0x1de8 [ 4.896460] init_module_from_file+0x8c/0xd8 [ 4.896461] __arm64_sys_finit_module+0x150/0x338 [ 4.896463] invoke_syscall+0x70/0x100 [ 4.896466] el0_svc_common.constprop.0+0x48/0xf0 [ 4.896469] do_el0_svc+0x24/0x38 [ 4.896471] el0_svc+0x34/0xf0 [ 4.896473] el0t_64_sync_handler+0x10c/0x138 [ 4.896474] el0t_64_sync+0x1b0/0x1b8 [ 4.896477] Code: 12001c36 f9400014 927ffa94 aa1403e0 (f9401a95) # Hardware platforms affected: ## mt8195-cherry-tomato-r2 - Compatibles: google,tomato-rev2 | google,tomato | mediatek,mt8195 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a12193661a7bc874… #kernelci issue maestro:295973ea60dd4385ec6b04faa6ddce9707f879a4 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks, 3 days

1
0
0 0

[PATCH v3] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it be hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitely waiting in an unkillable state. Also, a normal uninterruptible wait should not have resulted in the hung-task watchdog getting triggered, but the endless loop would. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v3: - Use mutex_lock() instead of mutex_lock_killable(). - Update commit message to incorporate Arnd's feedback. Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 35 ++++++++--------------------------- 1 file changed, 8 insertions(+), 27 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..d0f397c90242 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,18 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { + if (wait_for_completion_killable(&req->c)) { mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ - if (req->in_queue) { - list_del(&req->link); - req->in_queue = false; - } + if (req->in_queue) { + list_del(&req->link); + req->in_queue = false; } mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

3 weeks, 3 days

3
2
0 0

[PATCH] arm64: dts: exynos: gs101: disable pinctrl_gsacore node

by Peter Griffin

gsacore registers are not accessible from normal world. Disable this node, so that the suspend/resume callbacks in the pinctrl driver don't cause a Serror attempting to access the registers. Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> To: Rob Herring <robh(a)kernel.org> To: Krzysztof Kozlowski <krzk+dt(a)kernel.org> To: Conor Dooley <conor+dt(a)kernel.org> To: Alim Akhtar <alim.akhtar(a)samsung.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: devicetree(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: tudor.ambarus(a)linaro.org Cc: andre.draszik(a)linaro.org Cc: kernel-team(a)android.com Cc: willmcvicker(a)google.com Cc: stable(a)vger.kernel.org --- arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi index 302c5beb224a..b8f8255f840b 100644 --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi @@ -1451,6 +1451,7 @@ pinctrl_gsacore: pinctrl@17a80000 { /* TODO: update once support for this CMU exists */ clocks = <0>; clock-names = "pclk"; + status = "disabled"; }; cmu_top: clock-controller@1e080000 { --- base-commit: ed9a4ad6e5bd3a443e81446476718abebee47e82 change-id: 20241213-contrib-pg-pinctrl_gsacore_disable-3457c942b0fe Best regards, -- Peter Griffin <peter.griffin(a)linaro.org>

3 weeks, 3 days

2
1
0 0

Linux 6.6.76-rc1 regression due to crypto-api-fix-boot-up-self-test-race

by Barry K. Nathan

Compared to 6.6.75, 6.6.76-rc1 freezes up for roughly one minute during boot, and I think the log messages are indicating a crypto self-test failure afterward. I have tried it on two different computers (a Core 2 Duo-based PC and a Haswell-based 2015 15" MacBook Pro) and it happens 100% of the time on both. I bisected it down to crypto-api-fix-boot-up-self-test-race ("crypto: api - Fix boot-up self-test race"). Reverting that one patch from 6.6.76-rc1 fixes the regression for me. By the way, I also tested 6.13.2-rc1 and 6.12.13-rc1, and this bug did not reproduce on either. Log excerpt: [ 4.523861] ima: No TPM chip found, activating TPM-bypass! [ 4.534858] ima: Allocated hash algorithm: sha256 [ 4.544294] ima: No architecture policies found [ 4.553384] evm: Initialising EVM extended attributes: [ 4.563682] evm: security.selinux [ 4.570339] evm: security.SMACK64 (disabled) [ 4.578900] evm: security.SMACK64EXEC (disabled) [ 4.588156] evm: security.SMACK64TRANSMUTE (disabled) [ 4.598279] evm: security.SMACK64MMAP (disabled) [ 4.607534] evm: security.apparmor [ 4.614363] evm: security.ima [ 4.620326] evm: security.capability [ 4.627502] evm: HMAC attrs: 0x1 [ 65.685967] random: crng init done [ 68.452968] DRBG: could not allocate digest TFM handle: hmac(sha512) [ 68.465701] alg: drbg: Failed to reset rng [ 68.473914] alg: drbg: Test 0 failed for drbg_nopr_hmac_sha512 [ 68.485595] alg: self-tests for stdrng using drbg_nopr_hmac_sha512 failed (rc=-22) [ 68.485597] ------------[ cut here ]------------ [ 68.510017] alg: self-tests for stdrng using drbg_nopr_hmac_sha512 failed (rc=-22) [ 68.510035] WARNING: CPU: 1 PID: 78 at crypto/testmgr.c:5936 alg_test+0x49e/0x610 [ 68.540198] Modules linked in: [ 68.546332] CPU: 1 PID: 78 Comm: cryptomgr_test Not tainted 6.6.76-rc1 #1 [ 68.559920] Hardware name: Gigabyte Technology Co., Ltd. G41MT-S2PT/G41MT-S2PT, BIOS F2 12/06/2011 [ 68.579005] RIP: 0010:alg_test+0x49e/0x610 [ 68.587220] Code: de 48 89 df 89 04 24 e8 70 ed fe ff 44 8b 0c 24 e9 bc fc ff ff 44 89 c9 48 89 ea 4c 89 ee 48 c7 c7 80 9a ed ad e8 f2 74 b2 ff <0f> 0b 44 8b 0c 24 e9 a1 fe ff ff 8b 05 21 04 c2 01 85 c0 74 56 83 [ 68.624782] RSP: 0018:ffffbc8380307e10 EFLAGS: 00010286 [ 68.635252] RAX: 0000000000000000 RBX: 00000000ffffffff RCX: c0000000ffffefff [ 68.649534] RDX: 0000000000000000 RSI: 00000000ffffefff RDI: 0000000000000001 [ 68.663816] RBP: ffffa01c47be0200 R08: 0000000000000000 R09: ffffbc8380307c98 [ 68.678100] R10: 0000000000000003 R11: ffffffffae0d1368 R12: 0000000000000058 [ 68.692384] R13: ffffa01c47be0280 R14: 0000000000000058 R15: 0000000000000058 [ 68.706665] FS: 0000000000000000(0000) GS:ffffa01d37c80000(0000) knlGS:0000000000000000 [ 68.722871] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 68.734381] CR2: 00007ff2f64622e0 CR3: 0000000146c20000 CR4: 00000000000406e0 [ 68.748664] Call Trace: [ 68.753588] <TASK> [ 68.757817] ? alg_test+0x49e/0x610 [ 68.764817] ? __warn+0x81/0x130 [ 68.771301] ? alg_test+0x49e/0x610 [ 68.778304] ? report_bug+0x171/0x1a0 [ 68.785652] ? console_unlock+0x78/0x120 [ 68.793521] ? handle_bug+0x58/0x90 [ 68.800525] ? exc_invalid_op+0x17/0x70 [ 68.808221] ? asm_exc_invalid_op+0x1a/0x20 [ 68.816611] ? alg_test+0x49e/0x610 [ 68.823614] ? finish_task_switch.isra.0+0x90/0x2d0 [ 68.833390] ? __schedule+0x3c8/0xb00 [ 68.840739] ? __pfx_cryptomgr_test+0x10/0x10 [ 68.849473] cryptomgr_test+0x24/0x40 [ 68.856824] kthread+0xe5/0x120 [ 68.863133] ? __pfx_kthread+0x10/0x10 [ 68.870656] ret_from_fork+0x31/0x50 [ 68.877832] ? __pfx_kthread+0x10/0x10 [ 68.885354] ret_from_fork_asm+0x1b/0x30 [ 68.893226] </TASK> [ 68.897626] ---[ end trace 0000000000000000 ]--- -- -Barry K. Nathan <barryn(a)pobox.com>

3 weeks, 3 days

1
0
0 0

[PATCH v2 1/1] scsi: ufs: core: Fix the HIGH/LOW_TEMP Bit Definitions

by Bao D. Nguyen

According to the UFS Device Specification, the dExtendedUFSFeaturesSupport defines the support for TOO_HIGH_TEMPERATURE as bit[4] and the TOO_LOW_TEMPERATURE as bit[5]. Correct the code to match with the UFS device specification definition. Fixes: e88e2d322 ("scsi: ufs: core: Probe for temperature notification support") Cc: stable(a)vger.kernel.org Signed-off-by: Bao D. Nguyen <quic_nguyenb(a)quicinc.com> Reviewed-by: Avri Altman <Avri.Altman(a)wdc.com> --- include/ufs/ufs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/ufs/ufs.h b/include/ufs/ufs.h index e594abe..f0c6111 100644 --- a/include/ufs/ufs.h +++ b/include/ufs/ufs.h @@ -386,8 +386,8 @@ enum { /* Possible values for dExtendedUFSFeaturesSupport */ enum { - UFS_DEV_LOW_TEMP_NOTIF = BIT(4), - UFS_DEV_HIGH_TEMP_NOTIF = BIT(5), + UFS_DEV_HIGH_TEMP_NOTIF = BIT(4), + UFS_DEV_LOW_TEMP_NOTIF = BIT(5), UFS_DEV_EXT_TEMP_NOTIF = BIT(6), UFS_DEV_HPB_SUPPORT = BIT(7), UFS_DEV_WRITE_BOOSTER_SUP = BIT(8), -- 2.7.4

3 weeks, 3 days

4
4
0 0

[PATCH v4] scsi: ufs: fix use-after free in init error and remove paths

by André Draszik

devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup Fixes: cb77cb5abe1f ("blk-crypto: rename blk_keyslot_manager to blk_crypto_profile") Fixes: d76d9d7d1009 ("scsi: ufs: use devm_blk_ksm_init()") Cc: stable(a)vger.kernel.org Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- Changes in v4: - add a kdoc note to ufshcd_alloc_host() to state why there is no ufshcd_dealloc_host() (Mani) - use return err, without goto (Mani) - drop register dump and abort info from commit message (Mani) - Link to v3: https://lore.kernel.org/r/20250116-ufshcd-fix-v3-1-6a83004ea85c@linaro.org Changes in v3: - rename devres action handler to ufshcd_devres_release() (Bart) - Link to v2: https://lore.kernel.org/r/20250114-ufshcd-fix-v2-1-2dc627590a4a@linaro.org Changes in v2: - completely new approach using devres action for Scsi_host cleanup, to ensure ordering - add Fixes: and CC: stable tags (Eric) - Link to v1: https://lore.kernel.org/r/20250113-ufshcd-fix-v1-1-ca63d1d4bd55@linaro.org --- In my case, as per above trace I initially encountered an error in ufshcd_verify_dev_init(), which made me notice this problem both during error handling and release. For reproducing, it'd be possible to change that function to just return an error, or rmmod the platform glue driver. Other approaches for solving this issue I see are the following, but I believe this one here is the cleanest: * turn 'struct ufs_hba::crypto_profile' into a dynamically allocated pointer, in which case it doesn't matter if cleanup runs after scsi_host_put() * add an explicit devm_blk_crypto_profile_deinit() to be called by API users when necessary, e.g. before ufshcd_dealloc_host() in this case * register the crypto cleanup handler against the scsi-host device instead, like in v1 of this patch --- drivers/ufs/core/ufshcd.c | 31 +++++++++++++++++++++---------- drivers/ufs/host/ufshcd-pci.c | 2 -- drivers/ufs/host/ufshcd-pltfrm.c | 28 +++++++++------------------- include/ufs/ufshcd.h | 1 - 4 files changed, 30 insertions(+), 32 deletions(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 43ddae7318cb..4328f769a7c8 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -10279,16 +10279,6 @@ int ufshcd_system_thaw(struct device *dev) EXPORT_SYMBOL_GPL(ufshcd_system_thaw); #endif /* CONFIG_PM_SLEEP */ -/** - * ufshcd_dealloc_host - deallocate Host Bus Adapter (HBA) - * @hba: pointer to Host Bus Adapter (HBA) - */ -void ufshcd_dealloc_host(struct ufs_hba *hba) -{ - scsi_host_put(hba->host); -} -EXPORT_SYMBOL_GPL(ufshcd_dealloc_host); - /** * ufshcd_set_dma_mask - Set dma mask based on the controller * addressing capability @@ -10307,12 +10297,26 @@ static int ufshcd_set_dma_mask(struct ufs_hba *hba) return dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(32)); } +/** + * ufshcd_devres_release - devres cleanup handler, invoked during release of + * hba->dev + * @host: pointer to SCSI host + */ +static void ufshcd_devres_release(void *host) +{ + scsi_host_put(host); +} + /** * ufshcd_alloc_host - allocate Host Bus Adapter (HBA) * @dev: pointer to device handle * @hba_handle: driver private handle * * Return: 0 on success, non-zero value on failure. + * + * NOTE: There is no corresponding ufshcd_dealloc_host() because this function + * keeps track of its allocations using devres and deallocates everything on + * device removal automatically. */ int ufshcd_alloc_host(struct device *dev, struct ufs_hba **hba_handle) { @@ -10334,6 +10338,13 @@ int ufshcd_alloc_host(struct device *dev, struct ufs_hba **hba_handle) err = -ENOMEM; goto out_error; } + + err = devm_add_action_or_reset(dev, ufshcd_devres_release, + host); + if (err) + return dev_err_probe(dev, err, + "failed to add ufshcd dealloc action\n"); + host->nr_maps = HCTX_TYPE_POLL + 1; hba = shost_priv(host); hba->host = host; diff --git a/drivers/ufs/host/ufshcd-pci.c b/drivers/ufs/host/ufshcd-pci.c index ea39c5d5b8cf..9cfcaad23cf9 100644 --- a/drivers/ufs/host/ufshcd-pci.c +++ b/drivers/ufs/host/ufshcd-pci.c @@ -562,7 +562,6 @@ static void ufshcd_pci_remove(struct pci_dev *pdev) pm_runtime_forbid(&pdev->dev); pm_runtime_get_noresume(&pdev->dev); ufshcd_remove(hba); - ufshcd_dealloc_host(hba); } /** @@ -605,7 +604,6 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) err = ufshcd_init(hba, mmio_base, pdev->irq); if (err) { dev_err(&pdev->dev, "Initialization failed\n"); - ufshcd_dealloc_host(hba); return err; } diff --git a/drivers/ufs/host/ufshcd-pltfrm.c b/drivers/ufs/host/ufshcd-pltfrm.c index 505572d4fa87..ffe5d1d2b215 100644 --- a/drivers/ufs/host/ufshcd-pltfrm.c +++ b/drivers/ufs/host/ufshcd-pltfrm.c @@ -465,21 +465,17 @@ int ufshcd_pltfrm_init(struct platform_device *pdev, struct device *dev = &pdev->dev; mmio_base = devm_platform_ioremap_resource(pdev, 0); - if (IS_ERR(mmio_base)) { - err = PTR_ERR(mmio_base); - goto out; - } + if (IS_ERR(mmio_base)) + return PTR_ERR(mmio_base); irq = platform_get_irq(pdev, 0); - if (irq < 0) { - err = irq; - goto out; - } + if (irq < 0) + return irq; err = ufshcd_alloc_host(dev, &hba); if (err) { dev_err(dev, "Allocation failed\n"); - goto out; + return err; } hba->vops = vops; @@ -488,13 +484,13 @@ int ufshcd_pltfrm_init(struct platform_device *pdev, if (err) { dev_err(dev, "%s: clock parse failed %d\n", __func__, err); - goto dealloc_host; + return err; } err = ufshcd_parse_regulator_info(hba); if (err) { dev_err(dev, "%s: regulator init failed %d\n", __func__, err); - goto dealloc_host; + return err; } ufshcd_init_lanes_per_dir(hba); @@ -502,25 +498,20 @@ int ufshcd_pltfrm_init(struct platform_device *pdev, err = ufshcd_parse_operating_points(hba); if (err) { dev_err(dev, "%s: OPP parse failed %d\n", __func__, err); - goto dealloc_host; + return err; } err = ufshcd_init(hba, mmio_base, irq); if (err) { dev_err_probe(dev, err, "Initialization failed with error %d\n", err); - goto dealloc_host; + return err; } pm_runtime_set_active(dev); pm_runtime_enable(dev); return 0; - -dealloc_host: - ufshcd_dealloc_host(hba); -out: - return err; } EXPORT_SYMBOL_GPL(ufshcd_pltfrm_init); @@ -534,7 +525,6 @@ void ufshcd_pltfrm_remove(struct platform_device *pdev) pm_runtime_get_sync(&pdev->dev); ufshcd_remove(hba); - ufshcd_dealloc_host(hba); pm_runtime_disable(&pdev->dev); pm_runtime_put_noidle(&pdev->dev); } diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h index da0fa5c65081..58eb6e897827 100644 --- a/include/ufs/ufshcd.h +++ b/include/ufs/ufshcd.h @@ -1311,7 +1311,6 @@ static inline void ufshcd_rmwl(struct ufs_hba *hba, u32 mask, u32 val, u32 reg) void ufshcd_enable_irq(struct ufs_hba *hba); void ufshcd_disable_irq(struct ufs_hba *hba); int ufshcd_alloc_host(struct device *, struct ufs_hba **); -void ufshcd_dealloc_host(struct ufs_hba *); int ufshcd_hba_enable(struct ufs_hba *hba); int ufshcd_init(struct ufs_hba *, void __iomem *, unsigned int); int ufshcd_link_recovery(struct ufs_hba *hba); --- base-commit: 4e16367cfe0ce395f29d0482b78970cce8e1db73 change-id: 20250113-ufshcd-fix-52409f2d32ff Best regards, -- André Draszik <andre.draszik(a)linaro.org>

3 weeks, 3 days

5
4
0 0

[PATCH v3] scsi: qedf: Replace kmalloc_array() with kcalloc()

by Jiasheng Jiang

Replace kmalloc_array() with kcalloc() to avoid old (dirty) data being used/freed. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Cc: <stable(a)vger.kernel.org> # v4.11+ Signed-off-by: Jiasheng Jiang <jiashengjiangcool(a)gmail.com> --- Changelog: v2 -> v3: 1. Remove the check for bdt_info. v1 -> v2: 1. Replace kzalloc() with kcalloc(). --- drivers/scsi/qedf/qedf_io.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/scsi/qedf/qedf_io.c b/drivers/scsi/qedf/qedf_io.c index fcfc3bed02c6..d52057b97a4f 100644 --- a/drivers/scsi/qedf/qedf_io.c +++ b/drivers/scsi/qedf/qedf_io.c @@ -254,9 +254,7 @@ struct qedf_cmd_mgr *qedf_cmd_mgr_alloc(struct qedf_ctx *qedf) } /* Allocate pool of io_bdts - one for each qedf_ioreq */ - cmgr->io_bdt_pool = kmalloc_array(num_ios, sizeof(struct io_bdt *), - GFP_KERNEL); - + cmgr->io_bdt_pool = kcalloc(num_ios, sizeof(*cmgr->io_bdt_pool), GFP_KERNEL); if (!cmgr->io_bdt_pool) { QEDF_WARN(&(qedf->dbg_ctx), "Failed to alloc io_bdt_pool.\n"); goto mem_err; -- 2.25.1

3 weeks, 3 days

1
0
0 0

[PATCH AUTOSEL 5.4 1/2] orangefs: fix a oob in orangefs_debug_write

by Sasha Levin

From: Mike Marshall <hubcap(a)omnibond.com> [ Upstream commit f7c848431632598ff9bce57a659db6af60d75b39 ] I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch. Signed-off-by: Mike Marshall <hubcap(a)omnibond.com> Reported-by: syzbot+fc519d7875f2d9186c1f(a)syzkaller.appspotmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/orangefs/orangefs-debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c index 1b508f5433846..fa41db0884880 100644 --- a/fs/orangefs/orangefs-debugfs.c +++ b/fs/orangefs/orangefs-debugfs.c @@ -393,9 +393,9 @@ static ssize_t orangefs_debug_write(struct file *file, * Thwart users who try to jamb a ridiculous number * of bytes into the debug file... */ - if (count > ORANGEFS_MAX_DEBUG_STRING_LEN + 1) { + if (count > ORANGEFS_MAX_DEBUG_STRING_LEN) { silly = count; - count = ORANGEFS_MAX_DEBUG_STRING_LEN + 1; + count = ORANGEFS_MAX_DEBUG_STRING_LEN; } buf = kzalloc(ORANGEFS_MAX_DEBUG_STRING_LEN, GFP_KERNEL); -- 2.39.5

3 weeks, 3 days

1
1
0 0

[PATCH AUTOSEL 5.10 1/2] orangefs: fix a oob in orangefs_debug_write

by Sasha Levin

From: Mike Marshall <hubcap(a)omnibond.com> [ Upstream commit f7c848431632598ff9bce57a659db6af60d75b39 ] I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch. Signed-off-by: Mike Marshall <hubcap(a)omnibond.com> Reported-by: syzbot+fc519d7875f2d9186c1f(a)syzkaller.appspotmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/orangefs/orangefs-debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/orangefs/orangefs-debugfs.c b/fs/orangefs/orangefs-debugfs.c index 1b508f5433846..fa41db0884880 100644 --- a/fs/orangefs/orangefs-debugfs.c +++ b/fs/orangefs/orangefs-debugfs.c @@ -393,9 +393,9 @@ static ssize_t orangefs_debug_write(struct file *file, * Thwart users who try to jamb a ridiculous number * of bytes into the debug file... */ - if (count > ORANGEFS_MAX_DEBUG_STRING_LEN + 1) { + if (count > ORANGEFS_MAX_DEBUG_STRING_LEN) { silly = count; - count = ORANGEFS_MAX_DEBUG_STRING_LEN + 1; + count = ORANGEFS_MAX_DEBUG_STRING_LEN; } buf = kzalloc(ORANGEFS_MAX_DEBUG_STRING_LEN, GFP_KERNEL); -- 2.39.5

3 weeks, 3 days

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror