6LoWPAN shares L2CAP channels between connection setup, published peers
and packet transmission, while teardown also schedules asynchronous
cleanup. These paths currently disagree on when channel ownership, peer
visibility and module lifetime end. The resulting failures range from
leaked or unusable connections and peers surviving disable to transmit
use-after-free and execution of unloaded module code.

This series establishes a consistent ownership and teardown order across
those paths. Shared L2CAP and workqueue changes provide the lifetime
guarantees needed by the following 6LoWPAN changes, which make failed setup
recoverable and stop users of a peer before releasing its resources.
Keeping the changes together avoids fixing one lifetime while shortening
another.

The timer support adds one ordered workqueue per L2CAP connection and
serializes that connection's channel timers.

Assisted-by: LLM

Hi Cen,

On Mon, Sep 21, 2026 at 11:39 AM Cen Zhang <zzzccc427@gmail.com> wrote:
>
> 6LoWPAN shares L2CAP channels between connection setup, published peers
> and packet transmission, while teardown also schedules asynchronous
> cleanup. These paths currently disagree on when channel ownership, peer
> visibility and module lifetime end. The resulting failures range from
> leaked or unusable connections and peers surviving disable to transmit
> use-after-free and execution of unloaded module code.
>
> This series establishes a consistent ownership and teardown order across
> those paths. Shared L2CAP and workqueue changes provide the lifetime
> guarantees needed by the following 6LoWPAN changes, which make failed setup
> recoverable and stop users of a peer before releasing its resources.
> Keeping the changes together avoids fixing one lifetime while shortening
> another.
>
> The timer support adds one ordered workqueue per L2CAP connection and
> serializes that connection's channel timers.
>
> Assisted-by: LLM

Something suggests none of this was tested, as IPSP was never
mentioned once in this set.

-- 
Luiz Augusto von Dentz

Hi Luiz,

Luiz Augusto von Dentz <luiz.dentz@gmail.com> 于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