[v2] serial: 8250_pci1xxxx: fix off by one in pci1xxxx_process_read_data()

These > comparisons should be >= to prevent writing one element beyond
the end of the rx_buff[] array.  The rx_buff[] buffer has RX_BUF_SIZE
elements.  Fix the buffer overflow.

Fixes: aba8290f368d ("8250: microchip: pci1xxxx: Add Burst mode reception support in uart driver for writing into FIFO")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
v2: Add "fix" to the subject.  Fix a typo in the commit message as well.

 drivers/tty/serial/8250/8250_pci1xxxx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Hi,
it is not simply a matter of adding "fix" to the title.

You must explain what and why vs. how.

Please see:
  https://cbea.ms/git-commit/#why-not-how

for some guidelines on writing a good commit message.

Hugo Villeneuve


On Wed, 10 Jan 2024 22:25:21 +0300
Dan Carpenter <dan.carpenter@linaro.org> wrote:

> These > comparisons should be >= to prevent writing one element beyond
> the end of the rx_buff[] array.  The rx_buff[] buffer has RX_BUF_SIZE
> elements.  Fix the buffer overflow.
>
> Fixes: aba8290f368d ("8250: microchip: pci1xxxx: Add Burst mode reception support in uart driver for writing into FIFO")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
> v2: Add "fix" to the subject.  Fix a typo in the commit message as well.
> 
>  drivers/tty/serial/8250/8250_pci1xxxx.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_pci1xxxx.c b/drivers/tty/serial/8250/8250_pci1xxxx.c
> index 558c4c7f3104..cd258922bd78 100644
> --- a/drivers/tty/serial/8250/8250_pci1xxxx.c
> +++ b/drivers/tty/serial/8250/8250_pci1xxxx.c
> @@ -302,7 +302,7 @@ static void pci1xxxx_process_read_data(struct uart_port *port,
>  	 * to read, the data is received one byte at a time.
>  	 */
>  	while (valid_burst_count--) {
> -		if (*buff_index > (RX_BUF_SIZE - UART_BURST_SIZE))
> +		if (*buff_index >= (RX_BUF_SIZE - UART_BURST_SIZE))
>  			break;
>  		burst_buf = (u32 *)&rx_buff[*buff_index];
>  		*burst_buf = readl(port->membase + UART_RX_BURST_FIFO);
> @@ -311,7 +311,7 @@ static void pci1xxxx_process_read_data(struct uart_port *port,
>  	}
>  
>  	while (*valid_byte_count) {
> -		if (*buff_index > RX_BUF_SIZE)
> +		if (*buff_index >= RX_BUF_SIZE)
>  			break;
>  		rx_buff[*buff_index] = readb(port->membase +
>  					     UART_RX_BYTE_FIFO);
> -- 
> 2.43.0

On Wed, Jan 10, 2024 at 02:46:05PM -0500, Hugo Villeneuve wrote:
> Hi,
> it is not simply a matter of adding "fix" to the title.
> 
> You must explain what and why vs. how.
> 
> Please see:
>   https://cbea.ms/git-commit/#why-not-how
> 
> for some guidelines on writing a good commit message.
> 

If you can't understand why a buffer overflow is bad then I honestly
don't know what to say...

When I was a newbie, I encountered a driver which was written in
terrible style.  And I thought why do people allow it???  This is
garbage and it's messing up the Linux kernel with its bad style.

But after I got older, I realized that he was the only person with that
hardware and the only person who cared about it.   If I started fighting
with him about style then he would leave.  He was a quirky guy with bad
taste but he was still making useful contributions so it was better to
tolerate him.

These days I'm the old quirky guy.  If you want to fight with me about
commit messages, that's fine.  I can easily just add you to my list of
subsystems which only receive bug reports instead of patches.  (I think
only BPF is on the list currently because it's annoying to track the
bpf vs bpf-next tree).

Feel free to re-write this patch however you want and give me
Reported-by credit.

regards,
dan carpenter

On Wed, 10 Jan 2024 23:19:28 +0300
Dan Carpenter <dan.carpenter@linaro.org> wrote:

> On Wed, Jan 10, 2024 at 02:46:05PM -0500, Hugo Villeneuve wrote:
> > Hi,
> > it is not simply a matter of adding "fix" to the title.
> > 
> > You must explain what and why vs. how.
> > 
> > Please see:
> >   https://cbea.ms/git-commit/#why-not-how
> > 
> > for some guidelines on writing a good commit message.
> > 
> 
> If you can't understand why a buffer overflow is bad then I honestly
> don't know what to say...

Hi Dan,
I am also an old quirky guy, and pretty much know why a buffer overflow
is bad :)

My whole point was only related to the title of the commit
message, not the body of the commit message, which explained well
enough the problem and the solution, or the code fix itself.

Regards,
Hugo Villeneuve


> When I was a newbie, I encountered a driver which was written in
> terrible style.  And I thought why do people allow it???  This is
> garbage and it's messing up the Linux kernel with its bad style.
> 
> But after I got older, I realized that he was the only person with that
> hardware and the only person who cared about it.   If I started fighting
> with him about style then he would leave.  He was a quirky guy with bad
> taste but he was still making useful contributions so it was better to
> tolerate him.
> 
> These days I'm the old quirky guy.  If you want to fight with me about
> commit messages, that's fine.  I can easily just add you to my list of
> subsystems which only receive bug reports instead of patches.  (I think
> only BPF is on the list currently because it's annoying to track the
> bpf vs bpf-next tree).
> 
> Feel free to re-write this patch however you want and give me
> Reported-by credit.
> 
> regards,
> dan carpenter