Description of problem: libusb does not initialize its on-the-stack buffer in usb_get_string_simple() before it is passed to the appropriate ioctl. This causes valgrind to complain loudly. Version-Release number of selected component (if applicable): libusb 0.1.8 How reproducible: Perfectly reproducible. Steps to Reproduce: 1. valgrind --tool=memcheck <executable using libusb and usb_get_string_simple> Actual results: ... ==6942== Syscall param ioctl(generic) points to uninitialised byte(s) ==6942== at 0x41F9099: ioctl (in /lib/tls/libc-2.3.4.so) ==6942== by 0x404089A: usb_get_string (in /usr/lib/libusb-0.1.so.4.4.0) ==6942== by 0x404093B: usb_get_string_simple (in /usr/lib/libusb-0.1.so.4.4.0) ==6942== by 0x804AC81: USB::open_device(unsigned) (USB.cpp:43) ==6942== by 0x804AABF: USB::USB(unsigned) (USB.cpp:22) ==6942== by 0x8049DF9: Base_DMate::Base_DMate() (Base_DMate.cpp:25) ==6942== by 0x804956D: DMate::DMate() (DMate.cpp:14) ==6942== by 0x80491B2: main (main.cpp:64) ==6942== Address 0xBEE46004 is on thread 1's stack ==6942== ==6942== Conditional jump or move depends on uninitialised value(s) ==6942== at 0x4040949: usb_get_string_simple (in /usr/lib/libusb-0.1.so.4.4.0) ==6942== by 0x804AC81: USB::open_device(unsigned) (USB.cpp:43) ==6942== by 0x804AABF: USB::USB(unsigned) (USB.cpp:22) ==6942== by 0x8049DF9: Base_DMate::Base_DMate() (Base_DMate.cpp:25) ==6942== by 0x804956D: DMate::DMate() (DMate.cpp:14) ==6942== by 0x80491B2: main (main.cpp:64) ==6942== <second error message repeated 16 more times> ... Expected results: libusb should not cause valgrind errors. Additional info: This is probably innocuous, and it might make sense for a suppression to be added to valgrind. However, it is very easy to prevent this by making a change to libusb. Please see the attached patch.
Created attachment 160336 [details] libusb-initialize-simple-string-buffer.patch
Reassigning to Fedora-development, because the bug is still valid for the latest libusb. Note that you need to escalate this issue via the support channels if you expect this to be fixed in RHEL.