ACK: [SRU][J][PATCH 0/1] CVE-2025-21801

Andrei Gherzan andrei.gherzan at canonical.com
Tue Sep 15 00:00:14 UTC 2026


On 26/09/09 11:51AM, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2025-21801
> 
> [ Impact ]
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> net: ravb: Fix missing rtnl lock in suspend/resume path
> 
> Fix the suspend/resume path by ensuring the rtnl lock is held where required.
> Calls to ravb_open, ravb_close and wol operations must be performed under the
> rtnl lock to prevent conflicts with ongoing ndo operations.
> 
> Without this fix, the following warning is triggered: [ 39.032969]
> ============================= [ 39.032983] WARNING: suspicious RCU usage [
> 39.033019] ----------------------------- [ 39.033033]
> drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage!
> ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm:
> python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c
> #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on
> r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c
> (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [
> 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682]
> phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703]
> ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721]
> dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [
> 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [
> 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769]
> pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788]
> kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808]
> kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [
> 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [
> 39.033841] invoke_syscall+0x44/0x104 [ 39.033852]
> el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [
> 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [
> 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0:
> Link is Down
> 
> [ Fix ]
> 
> jammy/linux: backported from 2c2ebb2b4957
> 
> This tree's ravb_suspend/ravb_resume predate upstream's reset_control and
> pm_runtime_force_* rework, so instead of upstream's early-return structure the
> backport wraps this tree's actual rtnl-requiring calls under rtnl_lock: the
> if/else ravb_wol_setup/ravb_close block in suspend, and the
> ravb_wol_restore/ravb_open sequence inside the netif_running block in resume
> (unlocking on the error paths). This preserves the WoL/close/open behaviour
> while carrying upstream's locking intent.
> 
> [ Test Plan ]
> 
> Build and boot tested.
> 
> [ Where Problems Could Occur ]
> 
> A bad fix would primarily affect Renesas SoCs using the ravb (Ethernet AVB)
> driver, such as R-Car and RZ/G platforms, during system suspend and resume,
> including Wake-on-LAN configuration and network interface open/close on those
> paths. An incorrect change to the rtnl locking could deadlock or leave the
> lock held on an error path, stalling the network stack during suspend/resume.
> Systems without ravb hardware are not affected, and this only exercises code
> reached through suspend/resume.
> 
> [ Other Info ]
> 
> Kybele flow-v11-22-gf3c7ff80. Reference: 6d5481ab/v1

Acked-by: Andrei Gherzan <andrei.gherzan at canonical.com>

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260915/0713aa3a/attachment-0001.sig>


More information about the kernel-team mailing list