In the Linux kernel, the following vulnerability has been resolved:
can: j1939: fix errant WARNONONCE in j1939sessiondeactivate
The conclusion "j1939sessiondeactivate() should be called with a session ref-count of at least 2" is incorrect. In some concurrent scenarios, j1939sessiondeactivate can be called with the session ref-count less than 2. But there is not any problem because it will check the session active state before session putting in j1939sessiondeactivate_locked().
Here is the concurrent scenario of the problem reported by syzbot and my reproduction log.
cpu0 cpu1
j1939_xtp_rx_eoma
j1939xtprxabortone j1939sessiongetbyaddr [kref == 2] j1939sessiongetbyaddr [kref == 3] j1939sessiondeactivate [kref == 2] j1939sessionput [kref == 1] j1939sessioncompleted j1939sessiondeactivate WARNONONCE(kref < 2)
===================================================== WARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939sessiondeactivate+0x5f/0x70 CPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:j1939sessiondeactivate+0x5f/0x70 Call Trace: j1939sessiondeactivateactivatenext+0x11/0x28 j1939xtprxeoma+0x12a/0x180 j1939tprecv+0x4a2/0x510 j1939canrecv+0x226/0x380 canrcvfilter+0xf8/0x220 canreceive+0x102/0x220 ? processbacklog+0xf0/0x2c0 canrcv+0x53/0xf0 _netifreceiveskbonecore+0x67/0x90 ? processbacklog+0x97/0x2c0 _netifreceive_skb+0x22/0x80