* Re: [Linux-kernel-mentees] Analyze syzbot report technisat_usb2_rc_query KASAN
@ 2019-07-02 4:45 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2019-07-02 4:45 UTC (permalink / raw)
To: Phong Tran
Cc: mchehab, hans.verkuil, keescook, skhan, linux-kernel-mentees,
linux-media
On Tue, Jul 02, 2019 at 07:49:26AM +0700, Phong Tran wrote:
> Hello,
>
> I did a checking for this report of syzbot [1]
> From the call stack of dump log:
>
> There shows that a problem within technisat_usb2_get_ir()
>
> BUG: KASAN: slab-out-of-bounds in technisat_usb2_get_ir
> drivers/media/usb/dvb-usb/technisat-usb2.c:664 [inline]
> BUG: KASAN: slab-out-of-bounds in technisat_usb2_rc_query+0x5fa/0x660
> drivers/media/usb/dvb-usb/technisat-usb2.c:679
> Read of size 1 at addr ffff8880a8791ea8 by task kworker/0:1/12
>
> Take a look into while loop in technisat_usb2_get_ir().
> I recognized that a problem. The loop will not break out with the condition
> doesn't reach. Then "b++" will go wrong and buffer will be overflow.
>
> while (1) {
> [...]
> b++;
> if (*b == 0xff) {
> ev.pulse = 0;
> ev.duration = 888888*2;
> ir_raw_event_store(d->rc_dev, &ev);
> break;
> }
> }
>
> I would propose changing the loop condition by checking the address of the
> buffer. If acceptable, I will send this patch to the mailing-list.
> eg:
>
> - while (1) {
> + while (b != (buf + 63)) {
> [...]
> }
>
> Tested with syzbot, result is good [2].
>
> [1] https://syzkaller.appspot.com/bug?extid=eaaaf38a95427be88f4b
> [2] https://groups.google.com/d/msg/syzkaller-bugs/CySBCKuUOOs/0hKq1CdjCwAJ
Great, can you submit a patch for this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread* [Linux-kernel-mentees] Analyze syzbot report technisat_usb2_rc_query KASAN
@ 2019-07-02 4:45 ` Greg KH
0 siblings, 0 replies; 9+ messages in thread
From: Greg KH @ 2019-07-02 4:45 UTC (permalink / raw)
On Tue, Jul 02, 2019 at 07:49:26AM +0700, Phong Tran wrote:
> Hello,
>
> I did a checking for this report of syzbot [1]
> From the call stack of dump log:
>
> There shows that a problem within technisat_usb2_get_ir()
>
> BUG: KASAN: slab-out-of-bounds in technisat_usb2_get_ir
> drivers/media/usb/dvb-usb/technisat-usb2.c:664 [inline]
> BUG: KASAN: slab-out-of-bounds in technisat_usb2_rc_query+0x5fa/0x660
> drivers/media/usb/dvb-usb/technisat-usb2.c:679
> Read of size 1 at addr ffff8880a8791ea8 by task kworker/0:1/12
>
> Take a look into while loop in technisat_usb2_get_ir().
> I recognized that a problem. The loop will not break out with the condition
> doesn't reach. Then "b++" will go wrong and buffer will be overflow.
>
> while (1) {
> [...]
> b++;
> if (*b == 0xff) {
> ev.pulse = 0;
> ev.duration = 888888*2;
> ir_raw_event_store(d->rc_dev, &ev);
> break;
> }
> }
>
> I would propose changing the loop condition by checking the address of the
> buffer. If acceptable, I will send this patch to the mailing-list.
> eg:
>
> - while (1) {
> + while (b != (buf + 63)) {
> [...]
> }
>
> Tested with syzbot, result is good [2].
>
> [1] https://syzkaller.appspot.com/bug?extid=eaaaf38a95427be88f4b
> [2] https://groups.google.com/d/msg/syzkaller-bugs/CySBCKuUOOs/0hKq1CdjCwAJ
Great, can you submit a patch for this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 9+ messages in thread* [Linux-kernel-mentees] Analyze syzbot report technisat_usb2_rc_query KASAN
@ 2019-07-02 14:06 ` Phong Tran
0 siblings, 0 replies; 9+ messages in thread
From: tranmanphong @ 2019-07-02 14:06 UTC (permalink / raw)
On 7/2/19 11:45 AM, Greg KH wrote:
> On Tue, Jul 02, 2019 at 07:49:26AM +0700, Phong Tran wrote:
>> Hello,
>>
>> I did a checking for this report of syzbot [1]
>> From the call stack of dump log:
>>
>> There shows that a problem within technisat_usb2_get_ir()
>>
>> BUG: KASAN: slab-out-of-bounds in technisat_usb2_get_ir
>> drivers/media/usb/dvb-usb/technisat-usb2.c:664 [inline]
>> BUG: KASAN: slab-out-of-bounds in technisat_usb2_rc_query+0x5fa/0x660
>> drivers/media/usb/dvb-usb/technisat-usb2.c:679
>> Read of size 1 at addr ffff8880a8791ea8 by task kworker/0:1/12
>>
>> Take a look into while loop in technisat_usb2_get_ir().
>> I recognized that a problem. The loop will not break out with the condition
>> doesn't reach. Then "b++" will go wrong and buffer will be overflow.
>>
>> while (1) {
>> [...]
>> b++;
>> if (*b == 0xff) {
>> ev.pulse = 0;
>> ev.duration = 888888*2;
>> ir_raw_event_store(d->rc_dev, &ev);
>> break;
>> }
>> }
>>
>> I would propose changing the loop condition by checking the address of the
>> buffer. If acceptable, I will send this patch to the mailing-list.
>> eg:
>>
>> - while (1) {
>> + while (b != (buf + 63)) {
>> [...]
>> }
>>
>> Tested with syzbot, result is good [2].
>>
>> [1] https://syzkaller.appspot.com/bug?extid=eaaaf38a95427be88f4b
>> [2] https://groups.google.com/d/msg/syzkaller-bugs/CySBCKuUOOs/0hKq1CdjCwAJ
>
> Great, can you submit a patch for this?
>
Yes, sent a patch
https://lore.kernel.org/lkml/20190702140211.28399-1-tranmanphong at gmail.com/
Phong.
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Linux-kernel-mentees] Analyze syzbot report technisat_usb2_rc_query KASAN
@ 2019-07-02 14:06 ` Phong Tran
0 siblings, 0 replies; 9+ messages in thread
From: Phong Tran @ 2019-07-02 14:06 UTC (permalink / raw)
To: Greg KH
Cc: tranmanphong, mchehab, hans.verkuil, keescook, skhan,
linux-kernel-mentees, linux-media
On 7/2/19 11:45 AM, Greg KH wrote:
> On Tue, Jul 02, 2019 at 07:49:26AM +0700, Phong Tran wrote:
>> Hello,
>>
>> I did a checking for this report of syzbot [1]
>> From the call stack of dump log:
>>
>> There shows that a problem within technisat_usb2_get_ir()
>>
>> BUG: KASAN: slab-out-of-bounds in technisat_usb2_get_ir
>> drivers/media/usb/dvb-usb/technisat-usb2.c:664 [inline]
>> BUG: KASAN: slab-out-of-bounds in technisat_usb2_rc_query+0x5fa/0x660
>> drivers/media/usb/dvb-usb/technisat-usb2.c:679
>> Read of size 1 at addr ffff8880a8791ea8 by task kworker/0:1/12
>>
>> Take a look into while loop in technisat_usb2_get_ir().
>> I recognized that a problem. The loop will not break out with the condition
>> doesn't reach. Then "b++" will go wrong and buffer will be overflow.
>>
>> while (1) {
>> [...]
>> b++;
>> if (*b == 0xff) {
>> ev.pulse = 0;
>> ev.duration = 888888*2;
>> ir_raw_event_store(d->rc_dev, &ev);
>> break;
>> }
>> }
>>
>> I would propose changing the loop condition by checking the address of the
>> buffer. If acceptable, I will send this patch to the mailing-list.
>> eg:
>>
>> - while (1) {
>> + while (b != (buf + 63)) {
>> [...]
>> }
>>
>> Tested with syzbot, result is good [2].
>>
>> [1] https://syzkaller.appspot.com/bug?extid=eaaaf38a95427be88f4b
>> [2] https://groups.google.com/d/msg/syzkaller-bugs/CySBCKuUOOs/0hKq1CdjCwAJ
>
> Great, can you submit a patch for this?
>
Yes, sent a patch
https://lore.kernel.org/lkml/20190702140211.28399-1-tranmanphong@gmail.com/
Phong.
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 9+ messages in thread* [Linux-kernel-mentees] Analyze syzbot report technisat_usb2_rc_query KASAN
@ 2019-07-02 14:06 ` Phong Tran
0 siblings, 0 replies; 9+ messages in thread
From: Phong Tran @ 2019-07-02 14:06 UTC (permalink / raw)
On 7/2/19 11:45 AM, Greg KH wrote:
> On Tue, Jul 02, 2019 at 07:49:26AM +0700, Phong Tran wrote:
>> Hello,
>>
>> I did a checking for this report of syzbot [1]
>> From the call stack of dump log:
>>
>> There shows that a problem within technisat_usb2_get_ir()
>>
>> BUG: KASAN: slab-out-of-bounds in technisat_usb2_get_ir
>> drivers/media/usb/dvb-usb/technisat-usb2.c:664 [inline]
>> BUG: KASAN: slab-out-of-bounds in technisat_usb2_rc_query+0x5fa/0x660
>> drivers/media/usb/dvb-usb/technisat-usb2.c:679
>> Read of size 1 at addr ffff8880a8791ea8 by task kworker/0:1/12
>>
>> Take a look into while loop in technisat_usb2_get_ir().
>> I recognized that a problem. The loop will not break out with the condition
>> doesn't reach. Then "b++" will go wrong and buffer will be overflow.
>>
>> while (1) {
>> [...]
>> b++;
>> if (*b == 0xff) {
>> ev.pulse = 0;
>> ev.duration = 888888*2;
>> ir_raw_event_store(d->rc_dev, &ev);
>> break;
>> }
>> }
>>
>> I would propose changing the loop condition by checking the address of the
>> buffer. If acceptable, I will send this patch to the mailing-list.
>> eg:
>>
>> - while (1) {
>> + while (b != (buf + 63)) {
>> [...]
>> }
>>
>> Tested with syzbot, result is good [2].
>>
>> [1] https://syzkaller.appspot.com/bug?extid=eaaaf38a95427be88f4b
>> [2] https://groups.google.com/d/msg/syzkaller-bugs/CySBCKuUOOs/0hKq1CdjCwAJ
>
> Great, can you submit a patch for this?
>
Yes, sent a patch
https://lore.kernel.org/lkml/20190702140211.28399-1-tranmanphong at gmail.com/
Phong.
> thanks,
>
> greg k-h
>
^ permalink raw reply [flat|nested] 9+ messages in thread