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.
Same MOC protocol family as the already-supported 27c6:6384/631C.
Verified against real hardware: open, enroll, verify, identify and
delete all succeed. Dell's own driver .inf for this PID (extracted
from Goodix-Fingerprint-Sensor-Driver_T2VK3_WIN64_40.10.1.100_A05_01.EXE)
confirms it uses the plain (non-SecureFingerprint) MOC protocol.
If the reader does not respond, currently the plugin segfaults.
The error should be handled gracefully.
With this change, an error is printed instead of crashing:
failed to claim device:
GDBus.Error:net.reactivated.Fprint.Error.Internal:
Open failed with error: Can't get response!!
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Add USB PID 0x2020 (NB-2020-U) to the nb1010 driver's id_table.
The NB-2020-U is an embedded variant of the NB-1010-U using an
identical sensor die (confirmed by independent teardown reports from
System Plus Consulting/Yole Group). USB endpoint layout, command
protocol and image format are identical between both devices.
Tested on a Fujitsu notebook with integrated NB-2020-U reader
(USB ID 298d:2020): device enumeration, finger detection polling
and image capture all work correctly with the existing nb1010
driver code.
Signed-off-by: Sebastian van de Meer <kernel-error@kernel-error.com>
