The device may report a number of enrolled fingers but this value is not
checked against the data, so let's do it to prevent an overflow
Reported by: Keith Linneman (LinnemanLabs)
The message parser trusted the device-supplied payload length without
checking it against the number of bytes actually received.
A malicious or malfunctioning reader could thus drive an out-of-bounds
read past the received buffer.
Reject a header whose declared payload would extend past the received
data (and a too-short header).
Reported by: Keith Linneman (LinnemanLabs)
The frame length and the offset (which depends on the device-supplied
frame type) are derived from device bytes, so validate both the source
read (against the response buffer) and the destination write (against
the image buffer) before copying.
A malicious or malfunctioning device could otherwise drive a negative
(huge once unsigned) or out-of-bounds length.
Note: the response is reassembled across several USB transfers, so the
bound here is the response buffer capacity rather than a single
transfer's actual_length.
Reported by: Keith Linneman (LinnemanLabs)
num_lines comes from the device for each block and is summed into
the source row index (r) and destination byte offset (to).
Neither the per-block value nor the running totals are otherwise bound,
so a malicious device could drive the copy past the source
(IMAGE_HEIGHT rows) or destination buffer.
Reported by: Keith Linneman (LinnemanLabs)
The SSM error is stolen and then we pass to the resume/suspend callback
potentially leading to a double-free.
So copy it before re-using it.
Reported by: Keith Linneman (LinnemanLabs)
fp_device_finalize calls g_slist_free_full() to destroy any still-pending
timeout sources.
Each g_source_destroy call triggers timeout_finalize, which tries to
remove the current source from the sources list.
This may lead to a double-free, as iterating over a list deleting items
is not supported.
Add a regression test that adds a timeout with a long delay and immediately
finalizes the device while the timeout is still pending.
The slack of 250ms wasn't enough on loaded CI systems, causing frequent
flaky failures (e.g. 2276ms actual vs 2250ms limit, or 2294ms vs 2250ms).
Double the slacks to 500ms for the 2s transitions and 1000ms for the
5s transition to absorb system load noise while still catching real
timing regressions.
We're still going into the device in this case because technically the
identify operation may still return a print, although never a match of
course.
Adding tests so that we are not tempted to modify the behavior of the
identify function to return an error on prints->len == 0 or to just not
call the driver on such case.
Devices can scan even without a match, but if they do match a print then
they must match.
Ensure this in code to prevent drivers to return inconsistent data.
As per recent changes, drivers can just avoid implementing verify vfunc
unless the driver has specific commands to do it.
So let's just drop the duplicated code in drivers that have the very
same code path for both identification and verification.
In case a device has not support for verification through an explicit
verify function, the verification can still be implemented using
identification with a gallery of a single print.
In fact that's what most of drivers these days do it, so let's just
avoid to them to handle this duplication unless a driver has really some
specific commands to do it.
In test mode, dynamically load libraries in well known locations that can
allow to override the libfprint behavior.
It would still be possible to potentially inject code by replicating the
distro build directory and adding a library there, but if one is able to
access there, they would already be able to access any path.
Plus the env variable check is still there, so again they would need to
be able to change the fprintd environment
Rather than just do it in production if set, make it more difficult to
potentially inject the test mode.
So rely on a weak definition of fpi_device_emulation_mode_enabled() that
can be only set externally
Drivers may do some adjustments in test mode, initially we wanted to
reduce this to the minimum but the usage of `FP_DEVICE_EMULATION`
exploded, so move this instead into a properly defined variable that:
- Uses GLib compiler optimizations
- Is read just once per process
- Cannot be misused
As per commit bad930503c the test data is way bigger than it used to
be, so the test duration is longer.
Thus increase the timeout not to have failures
DT_RUNPATH is intentionally searched after $LD_LIBRARY_PATH.
-Wl,--disable-new-dtags switches to the old DT_RPATH tag, which is searched
before $LD_LIBRARY_PATH. So the embedded paths in the build binary will now
win over whatever is in the environment.
Not breaking builds.
Use bounded uid strings for template-info handling.
- stop printing fixed-size device buffers with raw %s
- use g_strndup(..., TEMPLATE_UID_SIZE) before logging tpl_info.uid
- compare delete target uid against the bounded copy
- log handshake response as bytes instead of %s
This avoids over-read/invalid-UTF8 issues when unknown/corrupted entries
contain non-NUL or 0xff-filled uid data.
