CVE-2025-40064: smc: Fix use-after-free in __pnet_find_base_ndev().

Published Oct 28, 2025
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

smc: Fix use-after-free in pnetfindbasendev().

syzbot reported use-after-free of netdevice in pnetfindbasendev(), which was called during connect(). [0]

smcpnetfindismresource() fetches skdstget(sk)->dev and passes down to pnetfindbasendev(), where RTNL is held. Then, UAF happened at pnetfindbasendev() when the dev is first used.

This means dev had already been freed before acquiring RTNL in pnetfindbasendev().

While dev is going away, dst->dev could be swapped with blackholenetdev, and the dev's refcnt by dst will be released.

We must hold dev's refcnt before calling smcpnetfindismresource().

Also, smcpnetfindroceresource() has the same problem.

Let's use skdstget() and dstdevrcu() in the two functions.

[0]: BUG: KASAN: use-after-free in pnetfindbasendev+0x1b1/0x1c0 net/smc/smcpnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609

CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 pnetfindbasendev+0x1b1/0x1c0 net/smc/smcpnet.c:926 pnetfindbasendev net/smc/smcpnet.c:946 [inline] smcpnetfindismbypnetid net/smc/smcpnet.c:1103 [inline] smcpnetfindismresource+0xef/0x390 net/smc/smcpnet.c:1154 smcfindismdevice net/smc/afsmc.c:1030 [inline] smcfindproposaldevices net/smc/afsmc.c:1115 [inline] smcconnect+0x372/0x1890 net/smc/afsmc.c:1545 smcconnect+0x877/0xd90 net/smc/afsmc.c:1715 sysconnectfile net/socket.c:2086 [inline] sysconnect+0x313/0x440 net/socket.c:2105 dosysconnect net/socket.c:2111 [inline] sesysconnect net/socket.c:2108 [inline] x64sysconnect+0x7a/0x90 net/socket.c:2108 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfpmask 0x446dc0(GFPKERNELACCOUNT|GFPZERO|GFPNOWARN|GFPRETRYMAYFAIL|GFPCOMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, freets 380670750466 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x240/0x2a0 mm/pagealloc.c:1851 prepnewpage mm/pagealloc.c:1859 [inline] getpagefromfreelist+0x21e4/0x22c0 mm/pagealloc.c:3858 allocfrozenpagesnoprof+0x181/0x370 mm/pagealloc.c:5148 allocpagesmpol+0x232/0x4a0 mm/mempolicy.c:2416 kmalloclargenode+0x5f/0x1b0 mm/slub.c:4317 kmalloclargenodenoprof+0x18/0x90 mm/slub.c:4348 dokmallocnode mm/slub.c:4364 [inline] kvmallocnode ---truncated---

Other sources

In the Linux kernel, the following vulnerability has been resolved:

smc: Fix use-after-free in pnetfindbasendev().

syzbot reported use-after-free of netdevice in pnetfindbasendev(), which was called during connect(). [0]

smcpnetfindismresource() fetches skdstget(sk)-dev and passes down to pnetfindbasendev(), where RTNL is held. Then, UAF happened at pnetfindbasendev() when the dev is first used.

This means dev had already been freed before acquiring RTNL in pnetfindbasendev().

While dev is going away, dst-dev could be swapped with blackholenetdev, and the dev's refcnt by dst will be released.

We must hold dev's refcnt before calling smcpnetfindismresource().

Also, smcpnetfindroceresource() has the same problem.

Let's use skdstget() and dstdevrcu() in the two functions.

[0]: BUG: KASAN: use-after-free in pnetfindbasendev+0x1b1/0x1c0 net/smc/smcpnet.c:926 Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609

CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: TASK dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 pnetfindbasendev+0x1b1/0x1c0 net/smc/smcpnet.c:926 pnetfindbasendev net/smc/smcpnet.c:946 [inline] smcpnetfindismbypnetid net/smc/smcpnet.c:1103 [inline] smcpnetfindismresource+0xef/0x390 net/smc/smcpnet.c:1154 smcfindismdevice net/smc/afsmc.c:1030 [inline] smcfindproposaldevices net/smc/afsmc.c:1115 [inline] smcconnect+0x372/0x1890 net/smc/afsmc.c:1545 smcconnect+0x877/0xd90 net/smc/afsmc.c:1715 sysconnectfile net/socket.c:2086 [inline] sysconnect+0x313/0x440 net/socket.c:2105 dosysconnect net/socket.c:2111 [inline] sesysconnect net/socket.c:2108 [inline] x64sysconnect+0x7a/0x90 net/socket.c:2108 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0x3b0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f47cbf8eba9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 48 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9 RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 /TASK

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000 raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfpmask 0x446dc0(GFPKERNELACCOUNT|GFPZERO|GFPNOWARN|GFPRETRYMAYFAIL|GFPCOMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, freets 380670750466 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x240/0x2a0 mm/pagealloc.c:1851 prepnewpage mm/pagealloc.c:1859 [inline] getpagefromfreelist+0x21e4/0x22c0 mm/pagealloc.c:3858 allocfrozenpagesnoprof+0x181/0x370 mm/pagealloc.c:5148 allocpagesmpol+0x232/0x4a0 mm/mempolicy.c:2416 kmalloclargenode+0x5f/0x1b0 mm/slub.c:4317 kmalloclargenodenoprof+0x18/0x90 mm/slub.c:4348 dokmallocnode mm/slub.c:4364 [inline] kvmallocnode ---truncated---

IBM

Affected Software

8 affected components
Linux Linux kernel
Microsoft azl3 kernel 6.6.104.2-4
Microsoft azl3 kernel 6.6.112.1-2
Microsoft azl3 kernel 6.6.117.1-1
IBM Verify Identity Access<=11.0 - 11.0.2
IBM Security Verify Access<=10.0 - 10.0.9.1
IBM Verify Identity Access Container<=11.0 - 11.0.2
IBM Security Verify Access Container<=10.0 - 10.0.9.1

Event History

Oct 28, 2025
CVE Published
via MITRE·11:48 AM
Data Sourced
via MITRE·11:48 AM
Description
Data Sourced
via Red Hat·12:03 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·12:15 PM
Description
Oct 29, 2025
Data Sourced
via Microsoft·01:03 AM
DescriptionSeverityWeaknessAffected Software
Updated
via Microsoft·01:03 AM
Affected Software
Updated
via Microsoft·01:03 AM
DescriptionSeverity
Jul 8, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2025-40064?

CVE-2025-40064 has been classified as a moderate severity vulnerability in the Linux kernel.

2

How do I fix CVE-2025-40064?

To fix CVE-2025-40064, you should update to the patched version of the Linux kernel that addresses the use-after-free vulnerability.

3

What types of systems are affected by CVE-2025-40064?

CVE-2025-40064 affects systems running vulnerable versions of the Linux kernel that utilize the smc networking feature.

4

What could happen if CVE-2025-40064 is exploited?

If exploited, CVE-2025-40064 could potentially lead to denial of service or arbitrary code execution due to the use-after-free condition.

5

Who reported CVE-2025-40064?

CVE-2025-40064 was reported by the syzbot, a kernel fuzzer for detecting bugs and vulnerabilities in the Linux kernel.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203