linux-kernel - Re: [PATCH v1 1/3] Bluetooth: btnxpuart: fix recv

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] [day] [month] [year] [list]

Message-ID: <ZWWZZQUzZpnTm4i5@francesco-nb.int.toradex.com>
Date:   Tue, 28 Nov 2023 08:40:21 +0100
From:   Francesco Dolcini <francesco@...cini.it>
To:     Jiri Slaby <jirislaby@...nel.org>
Cc:     Francesco Dolcini <francesco@...cini.it>,
        Amitkumar Karwar <amitkumar.karwar@....com>,
        Neeraj Kale <neeraj.sanjaykale@....com>,
        Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Francesco Dolcini <francesco.dolcini@...adex.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH v1 1/3] Bluetooth: btnxpuart: fix recv_buf() return value

On Tue, Nov 28, 2023 at 06:23:21AM +0100, Jiri Slaby wrote:
> On 27. 11. 23, 20:14, Francesco Dolcini wrote:
> > From: Francesco Dolcini <francesco.dolcini@...adex.com>
> > 
> > Serdev recv_buf() callback is supposed to return the amount of bytes
> > consumed, therefore an int in between 0 and count.
> > 
> > Do not return negative number in case of issue, just print an error and
> > return count.  This fixes a WARN in ttyport_receive_buf().

...

> >   drivers/bluetooth/btnxpuart.c | 7 +++----
> >   1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> > index b7e66b7ac570..951fe3014a3f 100644
> > --- a/drivers/bluetooth/btnxpuart.c
> > +++ b/drivers/bluetooth/btnxpuart.c
> > @@ -1276,11 +1276,10 @@ static int btnxpuart_receive_buf(struct serdev_device *serdev, const u8 *data,
> >   	if (IS_ERR(nxpdev->rx_skb)) {
> >   		int err = PTR_ERR(nxpdev->rx_skb);
> >   		/* Safe to ignore out-of-sync bootloader signatures */
> > -		if (is_fw_downloading(nxpdev))
> > -			return count;
> > -		bt_dev_err(nxpdev->hdev, "Frame reassembly failed (%d)", err);
> > +		if (!is_fw_downloading(nxpdev))
> > +			bt_dev_err(nxpdev->hdev, "Frame reassembly failed (%d)", err);
> >   		nxpdev->rx_skb = NULL;
> 
> Is this NULLing not needed in the good case?
NULLing in the good case would be a bug, in addition to that NULLing is
not needed at all even in the bad case and it will be removed in the
last patch, as a cleanup. Here I just maintained the existing logic.

> > -		return err;
> > +		return count;
> 
> Should you return 0? I don't know, maybe not
My reasoning is that we have some corrupted data, so we should just
use it all and maybe we'll get something valid at a later point, this is
what was already done before this change in the is_fw_downloading()
branch.

In my specific case it makes no difference, it will never recover from
this state.

Any other opinion?

> but you should document it in the commit log.
Ack

Francesco