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] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1544392233.507078927@decadent.org.uk>
Date:   Sun, 09 Dec 2018 21:50:33 +0000
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org,
        "Mauro Carvalho Chehab" <mchehab+samsung@...nel.org>
Subject: [PATCH 3.16 119/328] media: rtl28xxu: be sure that it won't go
 past the array size

3.16.62-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>

commit 845b978a871bff3707eee611b32e4be0b9a94dd2 upstream.

smatch warns that the RC query code could go past the array size:

	drivers/media/usb/dvb-usb-v2/rtl28xxu.c:1757 rtl2832u_rc_query() error: buffer overflow 'buf' 128 <= 130
	drivers/media/usb/dvb-usb-v2/rtl28xxu.c:1758 rtl2832u_rc_query() error: buffer overflow 'buf' 128 <= 130

The driver logic gets the length of the IR RX buffer with:

        ret = rtl28xxu_rd_reg(d, IR_RX_BC, &buf[0]);
	...
        len = buf[0];

In thesis, this could range between 0 and 255 [1].

While this should never happen in practice, due to hardware limits,
smatch is right when it complains about that, as there's nothing at
the logic that would prevent it. So, if for whatever reason, buf[0]
gets filled by rtl28xx read functions with a value bigger than 128,
it will go past the array.

So, add an explicit check.

[1] I've no idea why smatch thinks that the maximum value is 130.
I double-checked the code several times. Was unable to find any
reason for assuming 130. Perhaps smatch is not properly parsing
u8 here?

Fixes: b5cbaa43a676 ("[media] rtl28xx: initial support for rtl2832u")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1379,7 +1379,7 @@ static int rtl2832u_rc_query(struct dvb_
 		goto exit;
 
 	ret = rtl28xx_rd_reg(d, IR_RX_BC, &buf[0]);
-	if (ret)
+	if (ret || buf[0] > sizeof(buf))
 		goto err;
 
 	len = buf[0];

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ