In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced by following steps:
run nginx/wrk test: smcrun nginx smcrun wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>
continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D'
BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:smcdiagdump.constprop.0+0x5e5/0x620 [smcdiag] Call Trace: <TASK> ? _die+0x24/0x70 ? pagefaultoops+0x66/0x150 ? excpagefault+0x69/0x140 ? asmexcpagefault+0x26/0x30 ? _smcdiagdump.constprop.0+0x5e5/0x620 [smcdiag] ? _kmallocnodetrackcaller+0x35d/0x430 ? _allocskb+0x77/0x170 smcdiagdumpproto+0xd0/0xf0 [smcdiag] smcdiagdump+0x26/0x60 [smcdiag] netlinkdump+0x19f/0x320 _netlinkdumpstart+0x1dc/0x300 smcdiaghandlerdump+0x6a/0x80 [smcdiag] ? _pfxsmcdiagdump+0x10/0x10 [smcdiag] sockdiagrcvmsg+0x121/0x140 ? _pfxsockdiagrcvmsg+0x10/0x10 netlinkrcvskb+0x5a/0x110 sockdiagrcv+0x28/0x40 netlinkunicast+0x22a/0x330 netlinksendmsg+0x1f8/0x420 _socksendmsg+0xb0/0xc0 _syssendmsg+0x24e/0x300 ? copymsghdrfromuser+0x62/0x80 _syssendmsg+0x7c/0xd0 ? _dofault+0x34/0x160 ? doreadfault+0x5f/0x100 ? dofault+0xb0/0x110 ? _handlemmfault+0x2b0/0x6c0 _syssendmsg+0x4d/0x80 dosyscall64+0x69/0x180 entrySYSCALL64after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smcconncreate() but the rmbdesc has not yet been initialized by smcbufcreate(), thus causing the illegal access to conn->rmbdesc. So fix it by checking before dump.