Re: [PATCH 0/5] Bluetooth: 6LoWPAN lifecycle fixes

[Cen Zhang]

Hi Luiz,

Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> 于2026年9月22日周二 00:07写道：
>
> Something suggests none of this was tested, as IPSP was never
> mentioned once in this set.
>
Thank you for the feedback, and sorry that the patch series is not clear enough.

This series addresses six Bluetooth 6LoWPAN/IPSP lifetime bugs found
by our tools.
They were not submitted as static guesses: each bug was confirmed by dynamic
execution in a controlled, instrumented kernel. Two of them produced
native reports:
a KASAN use-after-free in send_pkt(), and an instruction-fetch fault
after unloading
bluetooth_6lowpan. The other four were confirmed as semantic or state-management
bugs where the harmful state or broken invariant was observed at runtime.

Because these bugs are related, I tried to fix them together in one series.
However, this turned out to be more difficult than I expected, and the
current result is not good enough. I will try either to narrow the fixes or
to send detailed bug reports first and work through the solutions together.

Do you think it would be better to start from separate bug reports, or from
narrower patches for a smaller subset of these issues?

For reference, the six bugs were:

    - A transmit race between ndo_start_xmit() and peer/channel removal,
      producing a native KASAN use-after-free report in send_pkt().
    - A module-lifetime bug where Bluetooth 6LoWPAN callback code could keep
      executing or return through module text after the module reference was
      dropped, producing a native instruction-fetch-fault report after unload.
    - A pre-publication setup failure where an IPSP channel could be deleted
      before lowpan_peer publication, leaving the creator-side channel
      reference without an owner.
    - A close-path race where local close could continue from stale connected
      state after concurrent deletion had set FLAG_DEL, rearming the timer and
      sending another disconnect for the deleted channel.
    - A listener/disable race where a request that had already looked up the
      listener could still create and publish a child peer after 6LoWPAN had
      been disabled and existing peers swept.
    - A ready/publication failure where add_peer_chan() could fail while the
      void ready callback returned normally, leaving a connected channel
      without a peer and running ifup() on a zero-peer netdev.


Best regards,

Cen Zhang