[bug report] Potential atomicity bug in drivers/target/sbp/sbp_target.c, between sbp_management_request_reconnect() and session_reconnect_expired()

Dear Linux kernel maintainers,

My research-based static analyzer found a potential atomicity bug
within the 'drivers/target/sbp' subsystem, more specifically, in
'drivers/target/sbp/sbp_target.c', where sbp_management_request_reconnect()
reads login->sess fields with the risk of null pointer dereference.

This potential issue is present as of git commit
eb3f4b7426cfd2b79d65b7d37155480b32259a11 of the mainline kernel.

The potential race is described below:

T0:
sbp_management_request_reconnect
  --> login = sbp_login_find_by_id(tpg, ...); [t0]
  --> if (login->sess->guid != guid) [t2]
        ....
  --> spin_lock_bh(&login->sess->lock)
  ...

T1:
session_reconnect_expired
   --> spin_lock_bh(&sess->lock);
   --> login->sess = NULL; [t1]
   --> list_move_tail(&login->link, &login_list); [t3]
   --> spin_unlock_bh(&sess->lock);

It is possible for t1 to occur before t2, i.e., the nullification of login->sess
happens before the usage in t2, causing null pointer dereference.

Regarding the potential concurrency of sbp_management_request_reconnect()
and session_reconnect_expired(), it is possible for 'sbp_mgt_agent_process()'
to be invoked with two requests leading to 'MANAGEMENT_ORB_FUNCTION_LOGIN'
and 'MANAGEMENT_ORB_FUNCTION_RECONNECT', chronologically.

Then, the maintenance work launched by 'sbp_management_request_login'
may still be
working and calling 'session_reconnect_expired()', while the second
request of reconnection
reaches the agent work.

Best regards,
Ginger