- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] tty: serial: uartlite: register uart driver in init
by Yi Yang 11 Jul '25

11 Jul '25

From: Jakub Lewalski <jakub.lewalski(a)nokia.com> stable inclusion from stable-v6.6.96 commit 8e958d10dd0ce5ae674cce460db5c9ca3f25243b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICL7YU CVE: CVE-2025-38262 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6bd697b5fc39fd24e2aa418c7b7d14469f550a93 ] When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference: [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8 [ 8.156982] #PF: supervisor write access in kernel mode [ 8.156984] #PF: error_code(0x0002) - not-present page [ 8.156986] PGD 0 P4D 0 ... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30 [ 8.188624] Call Trace: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called. Signed-off-by: Jakub Lewalski <jakub.lewalski(a)nokia.com> Signed-off-by: Elodie Decerle <elodie.decerle(a)nokia.com> Link: https://lore.kernel.org/r/20250331160732.2042-1-elodie.decerle@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/uartlite.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c index b225a78f6175..9f39bafa7fa9 100644 --- a/drivers/tty/serial/uartlite.c +++ b/drivers/tty/serial/uartlite.c @@ -872,16 +872,6 @@ static int ulite_probe(struct platform_device *pdev) pm_runtime_set_active(&pdev->dev); pm_runtime_enable(&pdev->dev); - if (!ulite_uart_driver.state) { - dev_dbg(&pdev->dev, "uartlite: calling uart_register_driver()\n"); - ret = uart_register_driver(&ulite_uart_driver); - if (ret < 0) { - dev_err(&pdev->dev, "Failed to register driver\n"); - clk_disable_unprepare(pdata->clk); - return ret; - } - } - ret = ulite_assign(&pdev->dev, id, res->start, irq, pdata); pm_runtime_mark_last_busy(&pdev->dev); @@ -922,16 +912,25 @@ static struct platform_driver ulite_platform_driver = { static int __init ulite_init(void) { + int ret; + + pr_debug("uartlite: calling uart_register_driver()\n"); + ret = uart_register_driver(&ulite_uart_driver); + if (ret) + return ret; pr_debug("uartlite: calling platform_driver_register()\n"); - return platform_driver_register(&ulite_platform_driver); + ret = platform_driver_register(&ulite_platform_driver); + if (ret) + uart_unregister_driver(&ulite_uart_driver); + + return ret; } static void __exit ulite_exit(void) { platform_driver_unregister(&ulite_platform_driver); - if (ulite_uart_driver.state) - uart_unregister_driver(&ulite_uart_driver); + uart_unregister_driver(&ulite_uart_driver); } module_init(ulite_init); -- 2.25.1

2 1

[PATCH OLK-5.10 v2] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 1ff7bddaac37 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 0831821d04c4..2222e1d2c648 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2213,8 +2213,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-6.6 v2] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 3c02fff414d4 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 6d9da768604d..9200e13cf97e 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2315,8 +2315,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-6.6] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 3c02fff414d4 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 6d9da768604d..9200e13cf97e 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2315,8 +2315,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-5.10] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 1ff7bddaac37 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 0831821d04c4..2222e1d2c648 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2213,8 +2213,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-6.6] drm/amd/display: Fix && vs || typos
by Xinyu Zheng 11 Jul '25

11 Jul '25

From: Dan Carpenter <dan.carpenter(a)linaro.org> mainline inclusion from mainline-v6.8-rc5 commit 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMKW Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- These ANDs should be ORs or it will lead to a NULL dereference. Fixes: 45716b01839a ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'") Fixes: 2de9bab01e39 ("drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'") Reviewed-by: Anthony Koo <anthony.koo(a)amd.com> Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c [lc: adjust context] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c index 840dfd237247..990374857d9a 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c @@ -211,7 +211,7 @@ void dcn21_set_pipe(struct pipe_ctx *pipe_ctx) struct dmcu *dmcu = pipe_ctx->stream->ctx->dc->res_pool->dmcu; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return; otg_inst = tg->inst; @@ -245,7 +245,7 @@ bool dcn21_set_backlight_level(struct pipe_ctx *pipe_ctx, struct panel_cntl *panel_cntl = pipe_ctx->stream->link->panel_cntl; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return false; otg_inst = tg->inst; -- 2.34.1

2 1

[PATCH OLK-6.6 0/6] hns3: Fix debugfs inconsistency and optimize driver code (stack usage, timer init, readability)
by huangdonghua 11 Jul '25

11 Jul '25

This patchset fixes debugfs query inconsistencies and optimizes the hns3 driver by reducing stack usage, improving timer initialization, and enhancing array handling readability. These changes improve the reliability and maintainability of the hns3 networking driver. Arnd Bergmann (1): net: hns3: reduce stack usage in hclge_dbg_dump_tm_pri() Hao Lan (1): net: hns3: Resolved the issue that the debugfs query result is inconsistent. Jian Shen (1): net: hns3: initialize reset_timer before hclgevf_misc_irq_init() Zhang Zekun (1): net: hns3: Use ARRAY_SIZE() to improve readability huangdonghua (2): Revert "net: hns3: initialize reset_timer before hclgevf_misc_irq_init()" Revert "net: hns3: Resolved the issue that the debugfs query result is inconsistent." drivers/net/ethernet/hisilicon/hns3/hnae3.h | 3 - .../ethernet/hisilicon/hns3/hns3_debugfs.c | 98 ++++++------------- .../hisilicon/hns3/hns3pf/hclge_debugfs.c | 21 ++-- .../hisilicon/hns3/hns3vf/hclgevf_main.c | 2 + .../hisilicon/hns3/hns3vf/hclgevf_regs.c | 8 +- 5 files changed, 51 insertions(+), 81 deletions(-) -- 2.33.0

2 7

[PATCH OLK-6.6] serial: Fix potential null-ptr-deref in mlb_usio_probe()
by Yi Yang 11 Jul '25

11 Jul '25

From: Henry Martin <bsdhenrymartin(a)gmail.com> stable inclusion from stable-v6.6.94 commit a6c7c365734cd0fa1c5aa225a6294fdf80cad2ea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICJT9C CVE: CVE-2025-38135 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 86bcae88c9209e334b2f8c252f4cc66beb261886 ] devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. Fixes: ba44dc043004 ("serial: Add Milbeaut serial control") Signed-off-by: Henry Martin <bsdhenrymartin(a)gmail.com> Link: https://lore.kernel.org/r/20250403070339.64990-1-bsdhenrymartin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/milbeaut_usio.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/milbeaut_usio.c b/drivers/tty/serial/milbeaut_usio.c index 70a910085e93..9de3883a4e0b 100644 --- a/drivers/tty/serial/milbeaut_usio.c +++ b/drivers/tty/serial/milbeaut_usio.c @@ -522,7 +522,10 @@ static int mlb_usio_probe(struct platform_device *pdev) } port->membase = devm_ioremap(&pdev->dev, res->start, resource_size(res)); - + if (!port->membase) { + ret = -ENOMEM; + goto failed; + } ret = platform_get_irq_byname(pdev, "rx"); mlb_usio_irq[index][RX] = ret; -- 2.25.1

2 1

[PATCH OLK-6.6 0/6] hns3: Fix debugfs inconsistency and optimize driver code (stack usage, timer init, readability)
by huangdonghua 11 Jul '25

11 Jul '25

This patchset fixes debugfs query inconsistencies and optimizes the hns3 driver by reducing stack usage, improving timer initialization, and enhancing array handling readability. These changes improve the reliability and maintainability of the hns3 networking driver. Arnd Bergmann (1): net: hns3: reduce stack usage in hclge_dbg_dump_tm_pri() Hao Lan (1): net: hns3: Resolved the issue that the debugfs query result is inconsistent. Jian Shen (1): net: hns3: initialize reset_timer before hclgevf_misc_irq_init() Zhang Zekun (1): net: hns3: Use ARRAY_SIZE() to improve readability huangdonghua (2): Revert "net: hns3: initialize reset_timer before hclgevf_misc_irq_init()" Revert "net: hns3: Resolved the issue that the debugfs query result is inconsistent." drivers/net/ethernet/hisilicon/hns3/hnae3.h | 3 - .../ethernet/hisilicon/hns3/hns3_debugfs.c | 98 ++++++------------- .../hisilicon/hns3/hns3pf/hclge_debugfs.c | 21 ++-- .../hisilicon/hns3/hns3vf/hclgevf_main.c | 2 + .../hisilicon/hns3/hns3vf/hclgevf_regs.c | 8 +- 5 files changed, 51 insertions(+), 81 deletions(-) -- 2.33.0

2 7

[PATCH OLK-6.6] smb: client: fix use-after-free in crypt_message when using async crypto
by Wang Zhaolong 11 Jul '25

11 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICL9Y9 -------------------------------- The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes: crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req); // Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Free creq while async operation is still in progress kvfree_sensitive(creq, ...); Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory. This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences. The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected. Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix. Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") Link: https://lore.kernel.org/all/8b784a13-87b0-4131-9ff9-7a8993538749@huaweiclou… Cc: stable(a)vger.kernel.org Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/smb/client/smb2ops.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index 91dbf48de9d0..ce1fb2f3e095 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -4272,10 +4272,11 @@ crypt_message(struct TCP_Server_Info *server, int num_rqst, struct scatterlist *sg; u8 sign[SMB2_SIGNATURE_SIZE] = {}; u8 key[SMB3_ENC_DEC_KEY_SIZE]; struct aead_request *req; u8 *iv; + DECLARE_CRYPTO_WAIT(wait); unsigned int crypt_len = le32_to_cpu(tr_hdr->OriginalMessageSize); void *creq; size_t sensitive_size; rc = smb2_get_enc_key(server, le64_to_cpu(tr_hdr->SessionId), enc, key); @@ -4322,11 +4323,15 @@ crypt_message(struct TCP_Server_Info *server, int num_rqst, aead_request_set_tfm(req, tfm); aead_request_set_crypt(req, sg, sg, crypt_len, iv); aead_request_set_ad(req, assoc_data_len); - rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); + aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, + crypto_req_done, &wait); + + rc = crypto_wait_req(enc ? crypto_aead_encrypt(req) + : crypto_aead_decrypt(req), &wait); if (!rc && enc) memcpy(&tr_hdr->Signature, sign, SMB2_SIGNATURE_SIZE); kvfree_sensitive(creq, sensitive_size); -- 2.34.3

2 1