On 17/12/2025 14:05, くさあさ wrote:
Hi Krzysztof,
Sorry about that — my previous response might not have made it to the list/thread. Replying here to address your concerns before sending v3.
- DM_DISC reply after LLCP_CLOSED
This is not a new behavior introduced by my change. In the old code, the LLCP_CLOSED branch did release_sock() and nfc_llcp_sock_put(), but it did not return/goto, so execution continued and still reached nfc_llcp_send_dm(..., LLCP_DM_DISC) afterwards. The disc patch only removes the redundant CLOSED-branch cleanup so release_sock()/nfc_llcp_sock_put() are performed exactly once via the common exit path, while keeping the existing DM_DISC reply behavior.
I understand that you did not change the flow. I did not claim you did. I ask why do you think your code is correct.
Do not top post and do not send new versions while the discussion is still going.
- Initial refcount / double free concern
nfc_llcp_recv_disc()/recv_hdlc() take an extra reference via nfc_llcp_sock_get() (sock_hold()). The issue is the mismatched put/unlock: the CLOSED branch drops the reference and releases the lock, and then the common exit path does the same again. This is a refcount/locking imbalance regardless of whether it immediately frees the object, and it may become a UAF depending on timing/refcounting.
You did not really address the problem. The refcnt has imbalance only if you assume initial refcnt was 0.
Best regards, Krzysztof