linux-kernel - Re: [PATCH 1/2] serial: sprd: Assign sprd_port after initialized to avoid wrong access

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: <CAAfSe-vNv=58k2b31xDqLmzSonWTsb5QJcXEyE3CoX81ND57mQ@mail.gmail.com>
Date:   Wed, 12 Jul 2023 11:11:25 +0800
From:   Chunyan Zhang <zhang.lyra@...il.com>
To:     Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc:     Chunyan Zhang <chunyan.zhang@...soc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org, Orson Zhai <orsonzhai@...il.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] serial: sprd: Assign sprd_port after initialized to
 avoid wrong access

On Wed, 12 Jul 2023 at 09:39, Baolin Wang <baolin.wang@...ux.alibaba.com> wrote:
>
>
>
> On 7/11/2023 10:57 AM, Chunyan Zhang wrote:
> > On Mon, 10 Jul 2023 at 17:57, Baolin Wang <baolin.wang@...ux.alibaba.com> wrote:
> >>
> >>
> >>
> >> On 7/10/2023 4:03 PM, Chunyan Zhang wrote:
> >>> The global pointer 'sprd_port' maybe not zero when sprd_probe returns
> >>> fail, that is a risk for sprd_port to be accessed afterward, and will
> >>> lead unexpected errors.
> >>>
> >>> For example:
> >>>
> >>> There're two UART ports, UART1 is used for console and configured in kernel
> >>> command line, i.e. "console=";
> >>>
> >>> The UART1 probe fail and the memory allocated to sprd_port[1] was released,
> >>> but sprd_port[1] was not set to NULL;
> >>
> >> IMO, we should just set sprd_port[1] to be NULL, which seems simpler?
> >
> > This patch just does like this indeed, in the label of 'clean_port'.
> > Adding a local variable instead of using global pointer (sprd_port[])
> > to store the virtual address allocated for sprd_port can avoid
> > overmany goto labels.
> >
> >>
> >>>
> >>> In UART2 probe, the same virtual address was allocated to sprd_port[2],
> >>> and UART2 probe process finally will go into sprd_console_setup() to
> >>> register UART1 as console since it is configured as preferred console
> >>> (filled to console_cmdline[]), but the console parameters (sprd_port[1])
> >>> actually belongs to UART2.
> >>
> >> I'm confusing why the console parameters belongs to UART2? Since the
> >> console_cmdline[] will specify the serial index, that belongs to UART1.
> >
> > The same virtual address stored in sprd_port[1] was reallocated to
> > sprd_port[2] after the UART1 probe returned failure.
> >
>
> After more thinking, I understood your case. :)
>
> But I see a nit in this patch, you added a 'clean_port' label to clear
> the resource for the fail-probe-port instead of sprd_remove(), however
> sprd_remove() will call sprd_rx_free_buf() to free the DMA buffer
> originally. I know the 2nd patch will add it back, but patch 1 is not
> git-bisect safe, right?

Actually it doesn't make git-bisect unsafe, the driver can work with a
memory leak issue which has been there and fixed in another patch.
But I can add back sprd_remove() to keep the unrelated code logic the same.

Thanks for the review,
Chunyan

>
> So I think you should also add sprd_rx_free_buf() under the 'clean_port'
> label in patch 1, then patch 2 moves the sprd_rx_free_buf() to the
> correct place.
>