| Age | Commit message (Collapse) | Author |
|---|
|
The /dev/hidrawX device may not exist immediately after writing to
the bind file. This change checks to see if it exists before attempting
to reopen the device.
(cherry picked from commit 8336b9c19bbf2adad93a4e193cd9258cf3fc7d0d)
Signed-off-by: Benson Leung <bleung@google.com>
Bug: 24809436
Change-Id: I02a662a2fc38e93df32190c03f35a1db3640f451
|
|
(cherry picked from commit 8fa2d839a428deb97762b7afcfef9666fd5e1640)
Signed-off-by: Benson Leung <bleung@google.com>
Bug: 24809436
Change-Id: Ibd2d363792d29876237ca1f4cf9604d7a0c20296
|
|
(cherry picked from commit cf807718a2a6802475be33bff400835d447e5bff)
Signed-off-by: Benson Leung <bleung@google.com>
Bug: 24809436
Change-Id: I3bdd5c1b4aca08c9ed8fa524472bdb52285be125
|
|
Signed-off-by: Benson Leung <bleung@google.com>
Bug: 24809436
(cherry picked from commit 757b6f6c072b023dd42d71dfb65417987a611234)
Change-Id: I57d6cd10f0d775fc4dfdbe51fd8b76ba4038eef6
|
|
Most HID devices allow appending the reflash command to the end of the firmware
block. This avoids sending a second report with the just the command. Also, after
the block is written HID devices send an attention report. Only read the F34 control
registers if waiting for that attention report times out.
Signed-off-by: Benson Leung <bleung@google.com>
Bug: 24809436
(cherry picked from commit 76743e425429076626df483691ce7abe563abd81)
Change-Id: I0a3276d77605843cbb6ddec221320a6048d7b925
|
|
Signed-off-by: Benson Leung <bleung@google.com>
Bug: 24809436
(cherry picked from commit d8b02a8fd18ca9d748908e297bf8902af019bcfd)
Change-Id: I7b80317ad0834fe580414800cad280ad006cc567
|
|
|
|
Write was returning the size of an output report since that is
what the the lower level write is returning. On success HIDDevice::Write
should return the number of bytes actual data which is what the caller
cares about.
|
|
|
|
expect
Make sure that the bytes in the report do no exceed the bytes which were
requested or that the bytes exceed the bytes remaining in the buffer.
|
|
|
|
|
|
Addresses security concern:
find_token does not check size of result buffer when writing, just
depends on caller to make sure input and output buffers are the same
length. This can lead to a stack buffer overflow if run with malicious
arguments (e.g. "-w AAAA...more.than.255...AAAA").
|
|
Addresses security concern:
All users of Read and Write fail to check for return value being equal
to desired write size (only look for <0, not a size >= 0 but less than
expected). This can lead to all kinds of corruption or overflows.
|
|
Addresses security concern:
All users of Read and Write fail to check for return value being equal
to desired write size (only look for <0, not a size >= 0 but less than
expected). This can lead to all kinds of corruption or overflows.
|
|
Addresses security concern:
WriteDeviceNameToFile does not check buffer lengths, and uses a fixed
size of 19, though this is likely safe due to how the kernel builds the
/sys tree entries. Also fails to check return code of "close".
|
|
Haven't tested split reads.
Addresses security concern:
HIDDevice::GetReport does not correctly handle split reads (count is
used at the end as if it were the total size of bytes read, which it
isn't), which could lead to communication corruption and data content
confusion (m_attnData and m_readData could have partially updated
contents). It's unlikely the hidraw interface could be tricked into
doing split reads, but I haven't tested it.
|
|
Addresses security concern:
HIDDevice::Read contains potential past-end-of-buffer write (and
read) when presented with a malicious/corrupt device report
(m_readData[HID_RMI4_READ_INPUT_COUNT] is not compared against the
remaining buf size. It asks nicely for no more than what would fit, but
the value in m_readData is HID device controlled, but isn't checked
against the actual size of the incoming buffer)
|
|
Addresses security concern:
HIDDevice::ParseReportSizes contains potential past-end-of-buffer reads
when presented with a malicious/corrupt device descriptor (++i and i +
1, i + 2 array indexes don't validate they're less than m_rptDesc.size).
|
|
Addresses Security concerns:
HIDDevice::Open does not validate minimum sizes for m_*ReportSize, which
could lead to past-end-of-buffer writes when using m_*Report arrays.
HIDDevice::GetAttentionReport does not correctly validate the size of
the m_attnData buffer vs the buf len. This is a past-end-of-buffer read
condition. I don't understand the point of reading bytes-many bytes but
returning *len set to the valid size of bytes in the buffer.
|
|
To avoid compilation warning
|
|
|
|
|
|
|
|
Add a noReset flag to f54test
|
|
|
|
|
|
|
|
of input reports changed
If the firmware configuration has changed then the size of input reports between the
bootloader and the UI may be different. Forcing a rebind of the driver when switching modes
will update the transport drivers of the new input report size.
|
|
|
|
|
|
In some cases during firmware update the size of the input reports can change
this commit allows for the unbinding and rebinding of the transport HID device to force
a reload of the HID descriptors so that the new size if read by the HID transport
drivers.
|
|
|
|
|
|
image is not newer then the firmware on the device
|
|
tellg returns -1 when there is an error. Also, check the result of tellg.
|
|
flash programming
|
|
|
|
|
|
|
|
|
|
attention report queue
Simplify GetReport and only have it read a single report and let the functions which call it decide
if they have gotten the data which they are looking for. Also, remove in the HIDDevice attention
report queue since reports are queued in the kernel so queueing in userspace is unnecessary.
|
|
|
|
|
|
This reverts commit a15fa80ba498286ef78a89410903c43801b95699.
|
|
|
|
Add f54 test
|
|
|
|
|
|
|
