[Nut-upsuser] Bug#439055: hid driver tries to mmap huge area, fails

[Arjen de Korte]

>> I tried stracing /lib/nut/newhidups:
>>
>> write(2, "Path: UPS.Battery.ff86001b, Type"..., 59) = 59
>> write(2, "entering path_to_string()\n", 26) = 26
>> write(2, "Looking up 00840004\n", 20)   = 20
>> write(2, "Looking up 00840012\n", 20)   = 20
>> write(2, "Looking up ff860016\n", 20)   = 20
>> write(2, "entering string_to_path()\n", 26) = 26
>> write(2, "parsing UPS\n", 12)           = 12
>> write(2, "Looking up UPS\n", 15)        = 15
>> write(2, "hid_lookup_usage: found 840004\n", 31) = 31
>> write(2, "parsing Battery\n", 16)       = 16
>> write(2, "Looking up Battery\n", 19)    = 19
>> write(2, "hid_lookup_usage: found 840012\n", 31) = 31
>> write(2, "parsing APCBattReplaceDate\n", 27) = 27
>> write(2, "Looking up APCBattReplaceDate\n", 30) = 30
>> write(2, "hid_lookup_usage: found ff860016"..., 33) = 33
>> write(2, "Path depth = 3\n", 15)        = 15
>> write(2, "0: Usage(00840004)\n", 19)    = 19
>> write(2, "1: Usage(00840012)\n", 19)    = 19
>> write(2, "2: Usage(ff860016)\n", 19)    = 19
>> mmap2(NULL, 822218752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
>> brk(0x31078000)                         = 0x46000
>> mmap2(NULL, 822349824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
>> mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xa221a000
>> munmap(0xa221a000, 942080)              = 0
>> munmap(0xa2400000, 106496)              = 0
>> mprotect(0xa2300000, 135168, PROT_READ|PROT_WRITE) = 0
>> mmap2(NULL, 822218752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
>> write(2, "Can\'t retrieve Report 69 (12): C"..., 54) = 54

It looks like it fails while attempting to read a variable from the UPS
(it would be better though to run the driver in debug mode though, mmap
should only be used as a last resort).


>> These mmaps are suspicious. 822218752 bytes is 784 megabytes. I have
>> attached the whole strace. I also have this problem with nut 2.2.0,
>> using the usbhid-ups driver, strace looks the same. The strace using
>> version 2.0.4-4 shows much more sane looking mmaps:
>>
>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4
>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4
>> mmap2(NULL, 22877, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40157000

That may just be a coincidence. We had a problem with uninitialized
storage space in the hidparser, which caused the size of expected
replies from the UPS to be calculated wrong for report ids 64-255. Since
the driver will attempt to allocate the length of the expected reply
*before* reading it, this may case this problem.

This bug has been in the newhidups driver from day 1, so this is not
something that was introduced after nut-2.0.4. It has been fixed in SVN
version 1079 though, so could you try out the development version from
the trunk?

Best regards, Arjen