Re: UBSan: Undefined Behavior in lf_advlock

2020-06-05 Thread Kamil Rytarowski
On 06.06.2020 00:25, Jaromír Doleček wrote:
> Le ven. 5 juin 2020 à 21:49, syzbot
>  a écrit :
>> [  44.1699615] panic: UBSan: Undefined Behavior in 
>> /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/vfs_lockf.c:843:16, signed 
>> integer overflow: 131072 + 9223372036854771712 cannot be represented in type 
>> 'long int'
>>
>> [  44.1931600] cpu0: Begin traceback...
>> [  44.1999503] vpanic() at netbsd:vpanic+0x287 sys/kern/subr_prf.c:290
>> [  44.2299515] isAlreadyReported() at netbsd:isAlreadyReported
>> [  44.2599494] HandleOverflow() at netbsd:HandleOverflow+0x1c9 
>> sys/../common/lib/libc/misc/ubsan.c:375
>> [  44.2899499] lf_advlock() at netbsd:lf_advlock+0x2124 
>> sys/kern/vfs_lockf.c:843
> 
> This happens in:
> if (fl->l_len > 0)
> end = start + fl->l_len - 1;
> else {
> 
> when call to fcntl() is arranged so that 'start' ends up 0x2 and
> fl->l_len 0x7000, overflowing the off_t.
> 
> I wonder, Is it important to fix cases like that?
> 
> Jaromir
> 

Generally we want to mute noise so signal is high on serious issues.

Overflowing off_t shall not happen as it is a signed integer. A compiler
is free to impose assumptions that the result is not overflowed and
miscompile. In this case it is probably safe, but better to silent it.



signature.asc
Description: OpenPGP digital signature


Re: UBSan: Undefined Behavior in lf_advlock

2020-06-05 Thread Jaromír Doleček
Le ven. 5 juin 2020 à 21:49, syzbot
 a écrit :
> [  44.1699615] panic: UBSan: Undefined Behavior in 
> /syzkaller/managers/netbsd-kubsan/kernel/sys/kern/vfs_lockf.c:843:16, signed 
> integer overflow: 131072 + 9223372036854771712 cannot be represented in type 
> 'long int'
>
> [  44.1931600] cpu0: Begin traceback...
> [  44.1999503] vpanic() at netbsd:vpanic+0x287 sys/kern/subr_prf.c:290
> [  44.2299515] isAlreadyReported() at netbsd:isAlreadyReported
> [  44.2599494] HandleOverflow() at netbsd:HandleOverflow+0x1c9 
> sys/../common/lib/libc/misc/ubsan.c:375
> [  44.2899499] lf_advlock() at netbsd:lf_advlock+0x2124 
> sys/kern/vfs_lockf.c:843

This happens in:
if (fl->l_len > 0)
end = start + fl->l_len - 1;
else {

when call to fcntl() is arranged so that 'start' ends up 0x2 and
fl->l_len 0x7000, overflowing the off_t.

I wonder, Is it important to fix cases like that?

Jaromir