| commit | 373cb7d625abd3414cdf454b8540670ff43a0901 | |
| author | Dan Carpenter <dan.carpenter@oracle.com> | |
| Tue, 4 Nov 2014 08:14:54 +0000 (4 11:14 +0300) | ||
| committer | Dan Carpenter <dan.carpenter@oracle.com> | |
| Tue, 4 Nov 2014 08:14:54 +0000 (4 11:14 +0300) | ||
| tree | 4948c58c9f882fbb5d5f26c2cb99c33b68135cc7 | treesnapshot (tar.gz zip) |
| parent | dec2de454634fa9a7d190c4e5c3777857b581692 | commitdiff |
db, kernel: when kmalloc() succeeds that implies the size was reasonable
There are lots of places where we do:
p = kmalloc(user_controlled_value, GFP_KERNEL);
If p is non-NULL then it means that user_controlled_value is a positive
and below 128MB. This is useful information to have.
Also I've recorded that zero sizes return 0x16.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
There are lots of places where we do:
p = kmalloc(user_controlled_value, GFP_KERNEL);
If p is non-NULL then it means that user_controlled_value is a positive
and below 128MB. This is useful information to have.
Also I've recorded that zero sizes return 0x16.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
| smatch_data/db/fixup_kernel.sh | diffblobblamehistory |