On Thu, Jul 04, 2019 at 08:13:44AM +0300, Dan Carpenter wrote: > On Wednesday, July 3, 2019, Andrew Murray <andrew.murray@xxxxxxx> wrote: > > > Hello, > > > > When looking at the smatch database, I see the following: > > > > kernel/sys.c|prctl_set_mm|find_vma|556035|0|8017|1|$|0-s32max[c] > > kernel/sys.c|prctl_set_mm|find_vma|556035|0|1001|1|$|0- > > 18446744073709551614 > > > I'm traveling and only have my phone. The user controlled data is somewhat > independent from param value (it's a subset). That's no problem, thanks for responding. > > One oddity is that if the kernel has if (user_int > > unknown_kernel_variable) then for user data we assume that the kernel > variable is less than INT_MAX. So in this case (prctl_set_mm) we have... if (addr >= TASK_SIZE || addr < mmap_min_addr) return -EINVAL I believe that TASK_SIZE is unknown when smatch runs (it's set by assembly on boot). Thus as TASK_SIZE is unknown we cap it at INT_MAX. Why do we only do this for user values, shouldn't the same logic apply to DATA_SOURCE (1001)? Isn't it safer, in these suitations, to add the cap flag [c] but not limit the range? As here we report the range is 0-s32max, when in fact it may be higher? Thanks, Andrew Murray > > I don't know if this is a useful answer without my computer though... > > Regards, > Dan Carpenter
