Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220926204657.3147968-1-iam@sung-woo.kim>
In-Reply-To: <20220926204657.3147968-1-iam@sung-woo.kim>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 26 Sep 2022 14:33:30 -0700
Message-ID: <CABBYNZLdvOzTwnHp4GX9PiXVMr2SDjD1NCXLRJw1_XLvSuZyjw@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: L2CAP: fix an illegal state transition from BT_DISCONN
To:     Sungwoo Kim <iam@sung-woo.kim>
Cc:     syzkaller@googlegroups.com, Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Kim,

On Mon, Sep 26, 2022 at 1:47 PM Sungwoo Kim <iam@sung-woo.kim> wrote:
>
> Prevent an illegal state transition from BT_DISCONN to BT_CONFIG.
> L2CAP_CONN_RSP and L2CAP_CREATE_CHAN_RSP events should be ignored
> for BT_DISCONN state according to the Bluetooth Core v5.3 p.1096.
> It is found by BTFuzz, a modified version of syzkaller.
>
> Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
> ---
>  net/bluetooth/l2cap_core.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 2c9de67da..a15d64b13 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -4307,6 +4307,9 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn,
>                 }
>         }

Perhaps it would be better to switch to use l2cap_get_chan_by_scid and
l2cap_get_chan_by_ident, since I suspect this is caused by the socket
being terminated while the response is in course so the chan reference
is already 0 thus why l2cap_chan_hold_unless_zero is probably
preferable instead of checking the state directly.

> +       if (chan->state == BT_DISCONN)
> +               goto unlock;
> +
>         err = 0;
>
>         l2cap_chan_lock(chan);
> --
> 2.25.1
>


-- 
Luiz Augusto von Dentz