aduggan / rmi4utils Goto Github PK

There are at least two places where ParseHierarchicalImg takes an offset to a buffer and does not validate that the resulting offset is valid. This means that malicious firmware can cause rmi4utils to crash, which is potentially a security issue as the user can dictate the memory address that gets overwritten. As firmware images are unsigned, it's almost trivial for a user to supply a modified image to cause the crash.

If you'd like me to attach some sample firmware which causes a crash using either (or both) offset checks just ask. There's also now an implementation of ParseHierarchicalImg in fwupd if you'd like to copy the fixes.

each Makefile has a slightly different linking rule. some utilize LDFLAGS, some don't. i'd make them all start like:

$(CXX) $(CXXFLAGS) $(LDFLAGS) ...

also, i'd just drop the LD indirection. you need to use the C++ driver everywhere anyways.

the standard env var name for preprocessor flags is CPPFLAGS, not INCLUDES. please rename that var in the build files, and then you don't have to manually add it to CXXFLAGS and such.

Hi,
I'm using ndk-r19 to build the rmi4utils but I got "scandir use of undeclared identifier 'versionsort'" during the compiling which is at "rmidevice/hiddevice.cpp" line 662. And I can complete the build after I changed it to "alphasort". Could you help to check it?

Thanks,
Aaron

in the Makefiles, rather than do things like:

CXXFLAGS = ...
CPPFLAGS = ...

it should append the value like so:

CXXFLAGS += ...
CPPFLAGS += ...

that way the settings the user has in the env will work automatically. like so:

CXXFLAGS='-O2 -pipe' CPPFLAGS=-D_FORTIFY_SOURCE=2 make

can you make the -static flag a build time knob ? since GNU make is already required, you could do something like:

STATIC_BUILD ?= y
ifeq ($(STATIC_BUILD),y)
LDFLAGS += -static
endif

Hi,

I'm using rmi4update to update the Synaptics touchscreen firmware on a Lenovo 300e 2nd Gen AMD Chromebook. The firmware versions and touchscreen properties are included in the logs below.

Using rmi4update v1.2.14, the update succeeds: update_logs_1-2-14.txt.

Using rmi4update v1.3.0 or higher, the update hangs during EnterFlashProgrammingV7(): update_logs_1-3-0.txt.

I've bisected the breakage to commit 8ade3e9.

The updater seems to hang at this call to ReadF34QueriesV7(). This call was added as part of commit 8ade3e9, and there are now two calls to ReadF34Queries*() in EnterFlashProgrammingV7(). It's not clear whether this is intentional.

If I build v1.3.0 (or later) with that call to ReadF34QueriesV7() removed, then the update succeeds update_logs_1-3-0_call_removed.txt.

Do you have any idea why this call is causing the updater to hang?

Thanks,
Reka

in a bunch of places, there's code like:
make -C dir target

that should be $(MAKE) instead so that the correct make is used, as well as the right flags passed down, and building in parallel is sane