linux-kernel - Re: [PATCH v2] Bluetooth: RFCOMM: Use skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+YHqMddY68Qk1rZexqhYYX9gah-==WGttFbp4urLS7Qg@mail.gmail.com>
Date:   Fri, 10 Jun 2022 06:59:29 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Soenke Huster <soenke.huster@...oes.de>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        linux-bluetooth@...r.kernel.org, netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Bluetooth: RFCOMM: Use skb_trim to trim checksum

On Fri, Jun 10, 2022 at 4:08 AM Soenke Huster <soenke.huster@...oes.de> wrote:
>
> As skb->tail might be zero, it can underflow. This leads to a page
> fault: skb_tail_pointer simply adds skb->tail (which is now MAX_UINT)
> to skb->head.
>
>     BUG: unable to handle page fault for address: ffffed1021de29ff
>     #PF: supervisor read access in kernel mode
>     #PF: error_code(0x0000) - not-present page
>     RIP: 0010:rfcomm_run+0x831/0x4040 (net/bluetooth/rfcomm/core.c:1751)
>
> By using skb_trim instead of the direct manipulation, skb->tail
> is reset. Thus, the correct pointer to the checksum is used.
>
> Signed-off-by: Soenke Huster <soenke.huster@...oes.de>
> ---
> v2: Clarified how the bug triggers, minimize code change
>
>  net/bluetooth/rfcomm/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 7324764384b6..443b55edb3ab 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1747,7 +1747,7 @@ static struct rfcomm_session *rfcomm_recv_frame(struct rfcomm_session *s,
>         type = __get_type(hdr->ctrl);
>
>         /* Trim FCS */
> -       skb->len--; skb->tail--;
> +       skb_trim(skb, skb->len - 1);
>         fcs = *(u8 *)skb_tail_pointer(skb);
>
>         if (__check_fcs(skb->data, type, fcs)) {
> --
> 2.36.1
>

Again, I do not see how skb->tail could possibly zero at this point.

If it was, skb with illegal layout has been queued in the first place,
we need to fix the producer, not the consumer.

A driver missed an skb_put() perhaps.

Can you please dump the skb here  ?

diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 7324764384b6773074032ad671777bf86bd3360e..358ccb4fe7214aea0bb4084188c7658316fe0ff7
100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1746,6 +1746,11 @@ static struct rfcomm_session
*rfcomm_recv_frame(struct rfcomm_session *s,
        dlci = __get_dlci(hdr->addr);
        type = __get_type(hdr->ctrl);

+       if (!skb->tail) {
+               DO_ONCE_LITE(skb_dump(KERN_ERR, skb, false));
+               kfree_skb(skb);
+               return s;
+       }
        /* Trim FCS */
        skb->len--; skb->tail--;
        fcs = *(u8 *)skb_tail_pointer(skb);