CVE-2025-22053: net: ibmveth: make veth_pool_store stop hanging
In the Linux kernel, the following vulnerability has been resolved:
net: ibmveth: make vethpoolstore stop hanging
v2: - Created a single error handling unlock and exit in vethpoolstore - Greatly expanded commit message with previous explanatory-only text
Summary: Use rtnlmutex to synchronize vethpoolstore with itself, ibmvethclose and ibmvethopen, preventing multiple calls in a row to napidisable.
Background: Two (or more) threads could call vethpoolstore through writing to /sys/devices/vio/30000002/pool/. You can do this easily with a little shell script. This causes a hang.
I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw:
Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 taskflags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] switchto+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedulepreemptdisabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] mutexlock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napienable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmvethopen+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] vethpoolstore+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfskfwrite+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfsfopwriteiter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfswrite+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksyswrite+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] systemcallexception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] systemcallvectoredcommon+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcureadlock){....}-{1:2}, at: debugshowalllocks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sbwriters#3){.+.+}-{0:0}, at: ksyswrite+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfsfopwriteiter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfsfopwriteiter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napienable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sbwriters#3){.+.+}-{0:0}, at: ksyswrite+0x88/0x150 [ 243. ---truncated---
Affected Software
Remediation
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the ibmveth driver are exposed when users or processes can write to the pool attributes under /sys/devices/vio/30000002/pool*/. The issue requires local access; the CVSS vector specifies local attack access and low privileges.
What is required to trigger the hang?
Two or more threads must make overlapping calls to veth_pool_store by writing pool attributes, such as pool*/active. Repeated or concurrent writes can cause multiple napi_disable calls in succession and leave the system hung.
What can be done before applying the patch?
Avoid concurrent writes to the affected ibmveth pool sysfs attributes. Ensure any administrative scripts or management processes serialize updates to pool*/ attributes so only one veth_pool_store operation runs at a time.
How can an administrator recognize the problem?
The failure can occur during concurrent pool configuration changes and may show ibmveth close/open activity that does not complete, followed by a hang. Testing should focus on overlapping writes to the affected pool sysfs files rather than single isolated updates.