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: <20220610110749.110881-1-soenke.huster@eknoes.de>
 <CANn89i+YHqMddY68Qk1rZexqhYYX9gah-==WGttFbp4urLS7Qg@mail.gmail.com>
 <9f214837-dc68-ef1a-0199-27d6af582115@eknoes.de> <CANn89iKS7npfHvBJNP2PBtR9RAQGsVdykELX8mK8DQbFbLeybA@mail.gmail.com>
 <22131ee2-914c-3aad-d2c3-f340ad0c8ad0@eknoes.de>
In-Reply-To: <22131ee2-914c-3aad-d2c3-f340ad0c8ad0@eknoes.de>
From:   Eric Dumazet <edumazet@google.com>
Date:   Tue, 14 Jun 2022 07:17:06 -0700
Message-ID: <CANn89i+FeNoxYVTG8xu6yU_iOf94cQkrAiP=3JeUwJSvuBW5QA@mail.gmail.com>
Subject: Re: [PATCH v2] Bluetooth: RFCOMM: Use skb_trim to trim checksum
To:     =?UTF-8?Q?S=C3=B6nke_Huster?= <soenke.huster@eknoes.de>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        linux-bluetooth@vger.kernel.org, netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jun 14, 2022 at 6:42 AM S=C3=B6nke Huster <soenke.huster@eknoes.de>=
 wrote:
>
> Hi Eric,
>
> On 10.06.22 18:55, Eric Dumazet wrote:
> > On Fri, Jun 10, 2022 at 8:35 AM S=C3=B6nke Huster <soenke.huster@eknoes=
.de> wrote:
> >>
> >> Hi Eric,
> >>
> >> On 10.06.22 15:59, Eric Dumazet wrote:
> >>> On Fri, Jun 10, 2022 at 4:08 AM Soenke Huster <soenke.huster@eknoes.d=
e> 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:1=
751)
> >>>>
> >>>> 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@eknoes.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_fram=
e(struct rfcomm_session *s,
> >>>>         type =3D __get_type(hdr->ctrl);
> >>>>
> >>>>         /* Trim FCS */
> >>>> -       skb->len--; skb->tail--;
> >>>> +       skb_trim(skb, skb->len - 1);
> >>>>         fcs =3D *(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.
> >>>
> >>
> >> Sorry, I thought that might be a right place as there is not much code=
 in the kernel
> >> that manipulates ->tail directly.
> >>
> >>> A driver missed an skb_put() perhaps.
> >>>
> >>
> >> I am using the (I guess quite unused) virtio_bt driver, and figured ou=
t that the following
> >> fixes the bug:
> >>
> >> --- a/drivers/bluetooth/virtio_bt.c
> >> +++ b/drivers/bluetooth/virtio_bt.c
> >> @@ -219,7 +219,7 @@ static void virtbt_rx_work(struct work_struct *wor=
k)
> >>         if (!skb)
> >>                 return;
> >>
> >> -       skb->len =3D len;
> >> +       skb_put(skb, len);
> >
> > Removing skb->len=3Dlen seems about right.
> > But skb_put() should be done earlier.
> >
> > We are approaching the skb producer :)
> >
> > Now you have to find/check who added this illegal skb in the virt queue=
.
> >
> > Maybe virtbt_add_inbuf() ?
>
> I think here, the length of the skb can't really be known - an empty SKB =
is put into
> the virtqueue, and then filled with data in the device, which is implemen=
ted in a Hypervisor.
> Maybe my implementation of that device might then be wrong, on the other =
hand I am pretty
> sure the driver should be the one that sets the length of the skb. But th=
e driver only
> knows it in virtbt_rx_work, as it learns the size of the added buffer the=
re for the first time.
>
> >
> > Also there is kernel info leak I think.
> >
>
> I think your are right!

If this patch in drivers/bluetooth/virtio_bt.c fixes the issue, please
submit a formal patch.
You can take ownership of it, of course.

If not, more investigation is needed on your side ;)

Thanks !

>
> > diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_b=
t.c
> > index 67c21263f9e0f250f0719b8e7f1fe15b0eba5ee0..c9b832c447ee451f027430b=
284d7bb246f6ecb24
> > 100644
> > --- a/drivers/bluetooth/virtio_bt.c
> > +++ b/drivers/bluetooth/virtio_bt.c
> > @@ -37,6 +37,9 @@ static int virtbt_add_inbuf(struct virtio_bluetooth *=
vbt)
> >         if (!skb)
> >                 return -ENOMEM;
> >
> > +       skb_put(skb, 1000);
> > +       memset(skb->data, 0, 1000);
> > +
> >         sg_init_one(sg, skb->data, 1000);
> >
> >         err =3D virtqueue_add_inbuf(vq, sg, 1, skb, GFP_KERNEL);
> >
> >
> >>         virtbt_rx_handle(vbt, skb);
> >>
> >>         if (virtbt_add_inbuf(vbt) < 0)
> >>
> >> I guess this is the root cause? I just used Bluetooth for a while in t=
he VM
> >> and no error occurred, everything worked fine.
> >>
> >>> Can you please dump the skb here  ?
> >>>
> >>> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.=
c
> >>> index 7324764384b6773074032ad671777bf86bd3360e..358ccb4fe7214aea0bb40=
84188c7658316fe0ff7
> >>> 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 =3D __get_dlci(hdr->addr);
> >>>         type =3D __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 =3D *(u8 *)skb_tail_pointer(skb);
> >>
> >> If it might still help:
> >>
> >> skb len=3D4 headroom=3D9 headlen=3D4 tailroom=3D1728
> >> mac=3D(-1,-1) net=3D(0,-1) trans=3D-1
> >> shinfo(txflags=3D0 nr_frags=3D0 gso(size=3D0 type=3D0 segs=3D0))
> >> csum(0x0 ip_summed=3D0 complete_sw=3D0 valid=3D0 level=3D0)
> >> hash(0x0 sw=3D0 l4=3D0) proto=3D0x0000 pkttype=3D0 iif=3D0
> >> skb linear:   00000000: 03 3f 01 1c
> >>