Found by Oracle's Parfait 2.2 static analyzer:
Error: Buffer overrun
Read outside array bounds [read-outside-array-bounds] (CWE 125):
In array dereference of xkb_file_type_strings[type] with index type
Array size is 56 bytes, index <= 56
at line 734 of src/xkbcomp/ast-build.c in function 'xkb_file_type_to_string'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This test contains of two parts:
- a simple program to convert RMLVO commandline arguments into a keymap (and
print that keymap if requested).
- a python script that runs through rules/evdev.xml, and tries to compile a
keymap for sort-of every layout/variant/option combination. Sort-of, because
we can have multiple options and it really only does one per layout(variant)
combination.
Same thing can be done using xkbcomp, but right now it doesn't take that as
argument, it's hard-coded.
This takes quite a while, installing python-tqdm is recommended to see fancy
progress bars instead of just miles of dumps.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The benchmarks don't show any effect, so turn it off to have one less
thing to worry about. The parser does a lot of casting between AST
nodes.
Signed-off-by: Ran Benita <ran234@gmail.com>
Left shift of a negative integer. For some reason the protocol
representation here got really botched (in the spec it is just a nice
and simple INT16).
Signed-off-by: Ran Benita <ran234@gmail.com>
Don't try to divide through a signed char when indexing an array, lest
ye try to index off the start of it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The only time we could ever hit this was with count == 0, which seems
unnecessarily pedantic. But OK.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Every user of ExprReturnLhs goes on to unconditionally dereference the
field return, which can be NULL if xkb_intern_atom fails. Return false
if this is the case, so we fail safely.
testcase: splice geometry data into interp
Signed-off-by: Daniel Stone <daniels@collabora.com>
If we have an expression of the form 'l1' in an interp section, we
unconditionally try to dereference its args, even if it has none.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If the scanner indicates that we might have something which looks like a
map, but the parser in fact fails to create that map, we will try to
access the map regardless. Stop doing that.
testcase: 'xkb_keymap {' -> '#kb_keymap'
Signed-off-by: Daniel Stone <daniels@collabora.com>
Coverity complains that a 7-byte string may not be null-terminated when copied
into act->data (size 7). This is fine, make a note of it.
All the strings in xkeyboard-config only use 6 bytes + null terminator so this
won't be an issue. The server (the only user of these) uses an 8-byte array
and forcibly null-terminates the string, see XkbDDXPrivate().
Everything else treats it as byte-array size 7 anyway so whether it's
null-terminated doesn't matter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Move the aliases copy to within the (num_key_aliases > 0) block.
Passing info->aliases into this fuction with invalid aliases will
cause log messages but num_key_aliases stays on 0. The key_aliases array
is never allocated and remains NULL. We then loop through the aliases, causing
a null-pointer dereference.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's a (theoretical?) path where we might end up strcpy() buf without ever
writing to it. This happens if the mask is nonzero but specifies a modifier
larger than the one in the xkb_mod_set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The parser would enter an infinite loop if an unterminated keysym
literal occurs at EOF.
Found with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
xkb_geometry sections are ignored; previously the had done so by
returning NULL for the section's XkbFile, however some sections of the
code do not expect this. Instead, create an XkbFile for it, it will
never be processes and discarded later.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
In the XKB format, floats and various keywords can only be used in the
xkb_geometry section. xkbcommon removed support xkb_geometry, but still
parses it for backward compatibility. As part of ignoring it, the float
AST node and various keywords were removed, and instead NULL was
returned by their parsing actions. However, the rest of the code does
not handle NULLs, and so when they appear crashes usually ensue.
To fix this, restore the float AST node and the ignored keywords. None
of the evaluating code expects them, so nice error are displayed.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
The expression evaluator would go into an infinite recursion when
evaluating something like this as a boolean: `!True`. Instead of
recursing to just `True` and negating, it recursed to `!True` itself
again.
Bug inherited from xkbcomp.
Caught with the afl fuzzer.
Signed-off-by: Ran Benita <ran234@gmail.com>
Though text formats aren't exactly fuzzer's strong suit, fuzzers can
catch many surface-level bugs.
The fuzz/ directory contains target programs, testcases and dictionaries
to drive the afl fuzzer.
This commit adds a fuzzer for the XKB keymap text format and the Compose
text format. On my slow machine, using a single core, a full cycle of
the XKB fuzzer takes 5 hours. For Compose, it takes a few minutes.
Fuzzing for the other file formats (rules files mostly) will be added
later.
To do some fuzzing, run `./fuzz/fuzz.sh`.
Signed-off-by: Ran Benita <ran234@gmail.com>
Old meson expects an array with one dependency per element. Providing a
string containing multiple deps results in only the first dep getting
its whitespace properly applied. As a result, the output was:
Requires.private: xcb >= 1.10 xcb-xkb>=1.10
And downstream projects failed to find a package named 'xcb-xkb>=1.10'.
Specifying an array of versioned deps results in correct output:
Requires.private: xcb >= 1.10, xcb-xkb >= 1.10
Fixes#64.
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
The meson-generated pkgconfig file was missing Requires and
Requires.private.
[ran: adjust for older Meson versions.]
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Signed-off-by: Ran Benita <ran234@gmail.com>
Trim the API a bit.
Also, just always use gettimeofday(), which is portable. Hopefully the
system clock doesn't change while a benchmark is running.
Signed-off-by: Ran Benita <ran234@gmail.com>
The CI image only has Python 3.4. It's a bit of a hassle to change this,
so let's pin meson to the version before they bumped their requirement
instead.
I suppose it's not that bad in that it will guarantee compatibility with
older meson over time.
Signed-off-by: Ran Benita <ran234@gmail.com>
Will be deprecated in automake 2.0.
Replaced by AC_CONFIG_MACRO_DIR (already present) which is available
since autoconf 2.63.
Signed-off-by: Ran Benita <ran234@gmail.com>
The x11 tests/demos did not depend on xcb and xcb-xkb directly, only
indirectly through link_with: libxkbcommon_x11_internal. So linking
worked, but the xcb and xcb-xkb cflags were *not* included when
compiling them. So when using xcb installed in a non-standard location,
what would happen is:
- Library will link with custom xcb and compile with custom xcb headers.
- Test will link with custom xcb and compile with system xcb headers (if
exist, otherwise fail).
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/57
Reported-by: @remexre
Signed-off-by: Ran Benita <ran234@gmail.com>
We will never remove the deprecated functions and there is no real
reason to annoy users into stop using them.
If there *will* be a reason, *then* we will add the attribute.
Fixes: https://github.com/xkbcommon/libxkbcommon/issues/56
Signed-off-by: Ran Benita <ran234@gmail.com>
Alan Coopersmith
Ran Benita
Peter Hutterer
Daniel Stone
Jan Alexander Steffens (heftig)