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

tags 439055 upstream
thanks

Hi Joey,
interesting setup! Do you use it (the arm) to monitor the UPS and send
notifications...
I've sadly not much time to investigate, but have you tested the latest
trunk?
also, you mention that it was working before: which nut version? what
has changed since?

2007/8/21, Joey Hess <joeyh at debian.org>:
> Package: nut
> Version: 2.0.5-3+b1
> Severity: normal
>
> root at slug:/home/joey>/sbin/upsdrvctl start
> Network UPS Tools - UPS driver controller 2.0.5
> Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.0.5)
>
> Detected a UPS: American Power Conversion/Back-UPS BR  800 FW:9.o2 .D USB
FW:o2
> Using subdriver: APC/CyberPower HID 0.9
> Unable to enter background: Cannot allocate memory
> Driver failed to start (exit status=1)
>
> slug is a nslu2, an arm machine. While it has only 32 mb ram, it has run
> nut recently with no problem, and has a reasonable amount of free memory
> and swap. I stopped many daemons, and the problem persisted.
>
> 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
>
> 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
>
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1,
'experimental')
> Architecture: arm
>
> Kernel: Linux slug 2.6.21-2-ixp4xx #1 Wed Jun 27 00:51:53 UTC 2007 armv5tel
GNU/Linux
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
cheers,
Arnaud
-- 
Free Software Developer - http://arnaud.quette.free.fr/
Debian Developer - http://people.debian.org/~aquette/
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Ubuntu Media Center (UMC) Project Leader - https://launchpad.net/~umc-team

Arnaud Quette wrote:
> interesting setup! Do you use it (the arm) to monitor the UPS and send
> notifications...
Yes.
> I've sadly not much time to investigate, but have you tested the latest
trunk?
No. Is it packaged?
> also, you mention that it was working before: which nut version? what
> has changed since?
I think I was using 2.0.4 sucessfully before.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20070907/b7250f7a/attachment.pgp

>> 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