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.
