* [PATCH v2] serial: max310x: Fix out of bounds access
@ 2015-08-12 7:22 Su Kang Yin
[not found] ` <CABJLtPHPCw7VN+wG4ApDxB-ZM7wRz_1xHfpNLL4o4_80JYyKaQ@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Su Kang Yin @ 2015-08-12 7:22 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Jiri Slaby, linux-serial, linux-kernel, Su Kang Yin
Max310x driver supports up to 4 UART devices but array size of
"struct max310x_one" is set to 1. That leads to out of bounds
access on UART port registration.
This patch fixed it by increase the array size to 4 which is
maximum supported UART.
Signed-off-by: Su Kang Yin <cantona@cantona.net>
---
v2: add Signed-off-by: line.
drivers/tty/serial/max310x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 182549f..b523552 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -33,6 +33,9 @@
#define MAX310X_MAJOR 204
#define MAX310X_MINOR 209
+/* Maximum supported device */
+#define MAX_DEVICE 4
+
/* MAX310X register definitions */
#define MAX310X_RHR_REG (0x00) /* RX FIFO */
#define MAX310X_THR_REG (0x00) /* TX FIFO */
@@ -273,7 +276,7 @@ struct max310x_port {
#ifdef CONFIG_GPIOLIB
struct gpio_chip gpio;
#endif
- struct max310x_one p[0];
+ struct max310x_one p[MAX_DEVICE];
};
static u8 max310x_port_read(struct uart_port *port, u8 reg)
--
1.9.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] serial: max310x: Fix out of bounds access
[not found] ` <CABJLtPHPCw7VN+wG4ApDxB-ZM7wRz_1xHfpNLL4o4_80JYyKaQ@mail.gmail.com>
@ 2015-08-12 9:46 ` Alexander Shiyan
2015-08-12 11:50 ` Kang Yin Su
0 siblings, 1 reply; 4+ messages in thread
From: Alexander Shiyan @ 2015-08-12 9:46 UTC (permalink / raw)
To: cantona; +Cc: Jiri Slaby, linux-serial, linux-kernel, Greg Kroah-Hartman
> Среда, 12 августа 2015, 15:36 +08:00 от cantona <cantona@cantona.net>:
>
>
> added Alexander Shiyan < shc_work@mail.ru >.
>
> On 12 August 2015 at 15:22, Su Kang Yin < cantona@cantona.net > wrote:
> >Max310x driver supports up to 4 UART devices but array size of
> >"struct max310x_one" is set to 1. That leads to out of bounds
> >access on UART port registration.
> >
> >This patch fixed it by increase the array size to 4 which is
> >maximum supported UART.
> >
> >Signed-off-by: Su Kang Yin < cantona@cantona.net >
> >---
...
This seems incorrect. The number of ports is allocated dynamically by:
...
/* Alloc port structure */
s = devm_kzalloc(dev, sizeof(*s) + sizeof(struct max310x_one) * devtype->nr, GFP_KERNEL);
...
Thanks.
---
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] serial: max310x: Fix out of bounds access
2015-08-12 9:46 ` Alexander Shiyan
@ 2015-08-12 11:50 ` Kang Yin Su
2015-08-12 15:17 ` Greg Kroah-Hartman
0 siblings, 1 reply; 4+ messages in thread
From: Kang Yin Su @ 2015-08-12 11:50 UTC (permalink / raw)
To: Alexander Shiyan
Cc: Jiri Slaby, linux-serial, linux-kernel, Greg Kroah-Hartman
On 12 August 2015 at 17:46, Alexander Shiyan <shc_work@mail.ru> wrote:
>> Среда, 12 августа 2015, 15:36 +08:00 от cantona <cantona@cantona.net>:
>>
>>
>> added Alexander Shiyan < shc_work@mail.ru >.
>>
>> On 12 August 2015 at 15:22, Su Kang Yin < cantona@cantona.net > wrote:
>> >Max310x driver supports up to 4 UART devices but array size of
>> >"struct max310x_one" is set to 1. That leads to out of bounds
>> >access on UART port registration.
>> >
>> >This patch fixed it by increase the array size to 4 which is
>> >maximum supported UART.
>> >
>> >Signed-off-by: Su Kang Yin < cantona@cantona.net >
>> >---
> ...
>
> This seems incorrect. The number of ports is allocated dynamically by:
> ...
> /* Alloc port structure */
> s = devm_kzalloc(dev, sizeof(*s) + sizeof(struct max310x_one) * devtype->nr, GFP_KERNEL);
> ...
>
> Thanks.
>
> ---
>
Oh, my bad. But it looks confusing. So we must ensure "struct
max310x_one p[0]" must the last element of "struct max310x_port".
Thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] serial: max310x: Fix out of bounds access
2015-08-12 11:50 ` Kang Yin Su
@ 2015-08-12 15:17 ` Greg Kroah-Hartman
0 siblings, 0 replies; 4+ messages in thread
From: Greg Kroah-Hartman @ 2015-08-12 15:17 UTC (permalink / raw)
To: Kang Yin Su; +Cc: Alexander Shiyan, Jiri Slaby, linux-serial, linux-kernel
On Wed, Aug 12, 2015 at 07:50:25PM +0800, Kang Yin Su wrote:
> On 12 August 2015 at 17:46, Alexander Shiyan <shc_work@mail.ru> wrote:
> >> Среда, 12 августа 2015, 15:36 +08:00 от cantona <cantona@cantona.net>:
> >>
> >>
> >> added Alexander Shiyan < shc_work@mail.ru >.
> >>
> >> On 12 August 2015 at 15:22, Su Kang Yin < cantona@cantona.net > wrote:
> >> >Max310x driver supports up to 4 UART devices but array size of
> >> >"struct max310x_one" is set to 1. That leads to out of bounds
> >> >access on UART port registration.
> >> >
> >> >This patch fixed it by increase the array size to 4 which is
> >> >maximum supported UART.
> >> >
> >> >Signed-off-by: Su Kang Yin < cantona@cantona.net >
> >> >---
> > ...
> >
> > This seems incorrect. The number of ports is allocated dynamically by:
> > ...
> > /* Alloc port structure */
> > s = devm_kzalloc(dev, sizeof(*s) + sizeof(struct max310x_one) * devtype->nr, GFP_KERNEL);
> > ...
> >
> > Thanks.
> >
> > ---
> >
>
>
> Oh, my bad. But it looks confusing. So we must ensure "struct
> max310x_one p[0]" must the last element of "struct max310x_port".
Yes, that is a very common pattern we use in the kernel.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-08-12 15:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-12 7:22 [PATCH v2] serial: max310x: Fix out of bounds access Su Kang Yin
[not found] ` <CABJLtPHPCw7VN+wG4ApDxB-ZM7wRz_1xHfpNLL4o4_80JYyKaQ@mail.gmail.com>
2015-08-12 9:46 ` Alexander Shiyan
2015-08-12 11:50 ` Kang Yin Su
2015-08-12 15:17 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox