Re: Bluetooth: mgmt: Fix heap overflow in mgmt_mesh_add

[Daniel Matsumoto]

Hi Luiz,

Makes perfect sense regarding EXPORT_SYMBOL. Thanks for taking a look
and dropping it.

Regards,
Daniel


On Thu, Feb 19, 2026 at 1:16 PM Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
>
> Hi Daniel,
>
> On Tue, Feb 17, 2026 at 1:09 PM Daniel Matsumoto <me@xxxxxxxx> wrote:
> >
> > Regarding commit ac0c6f1b6a58 ("Bluetooth: mgmt: Fix heap overflow in
> > mgmt_mesh_add"):
> >
> > I reviewed the call path for this patch and the overflow condition
> > appears to be unreachable in the current tree.
> > The only caller of mgmt_mesh_add() is mesh_send() in
> > net/bluetooth/mgmt_util.c. The length parameter is explicitly
> > sanitized before the call:
> >
> > if (!hci_dev_test_flag(hdev, HCI_LE_ENABLED) ||
> >    len <= MGMT_MESH_SEND_SIZE ||
> >    len > (MGMT_MESH_SEND_SIZE + 31))
> > return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
> >       MGMT_STATUS_REJECTED);
> >
> > Given that mgmt_mesh_add() allocates sizeof(*mesh_tx), which includes
> > the param buffer sized for this maximum length, the bounds check
> > introduced in the commit is redundant.
> > While defensive programming is valid, tagging this as a fix for a heap
> > overflow is misleading for backporters and security scanners, as the
> > overflow cannot be triggered.
>
> Yeah, well I would say it would only be valid to apply defensive
> programming if that function would be marked with EXPORT_SYMBOL so it
> could be used outside of net/bluetooth context.
>
> > Please consider dropping this from the stable queue to avoid
> > unnecessary code churn.
>
> +1, will drop it entirely, it seems I will need to ask for more
> evidence as apparently people are relying too much on LLVM nowadays.
>
> --
> Luiz Augusto von Dentz
>