Warning: noted but unhandled ioctl 0x641e with no size/direction hints
Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s)
at 0x6A30BAA: setsockopt (syscall-template.S:82)
by 0x4E36E1C: udev_monitor_filter_update (libudev-monitor.c:347)
by 0x4E36ED8: udev_monitor_enable_receiving (libudev-monitor.c:373)
by 0x8A9E68E: I830ScreenInit (intel_driver.c:838)
by 0x42EE9E: AddScreen (dispatch.c:3890)
by 0x471561: InitOutput (xf86Init.c:738)
by 0x422C18: main (main.c:205)
Location 0x7ff0000c2 is 2 bytes inside local var "filter"
declared at libudev-monitor.c:256, in frame #1 of thread 1
Uninitialised value was created by a stack allocation
at 0x4E30860: ??? (in /lib64/libudev.so.0.10.0)
Thanks to Zdenek Kabelac.
Reading of keymaps is aborted when EINVAL is returned from EVIOCGETKEYCODE.
Scan codes are not always continuous ranges of values starting at 0, so this
can result in not getting the full keymap for a device. Instead, continue
processing if EINVAL is returned.
We should bind the udev socket from systemd, so we are sure
that the abstract namespace socket is always bound by a root
process and there is never a window during an update where
an untrusted process can steal our socket.
Also split the udev.service file, so that the daemon can be
updated/restarted without triggering any coldplug events.
Syslog wants to distinguish the sorce of messages. We should
indicate that this is a userspace message (LOG_DAEMON) and not
a kernel message (LOG_KERNEL).
We previously only tested the "key" capabilities for keys between 0 and 255 to
determine ID_INPUT_KEY. If there are none, also check for keys in the upper
block (KEY_OK/0x160 to KEY_TOUCHPAD_OFF/0x214).
Joey Lee <jlee@novell.com> reported a problem on an MSI laptop which reports a
too long capabilities/key:
E: EV==3
E: KEY==180000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
This is longer than KEY_MAX and thus caused a memory overflow. Guard against
this now and just ignore the excess blocks.