New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 779098 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

Null-dereference READ in device::U2fBleFrame::U2fBleFrame

Project Member Reported by ClusterFuzz, Oct 27 2017

Issue description

Detailed report: https://clusterfuzz.com/testcase?key=4505162046767104

Fuzzer: afl_u2f_ble_frames_fuzzer
Job Type: afl_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  device::U2fBleFrame::U2fBleFrame
  
Sanitizer: address (ASAN)

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4505162046767104

Issue filed automatically.

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.

Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
 
Cc: msrchandra@chromium.org pnangunoori@chromium.org
Components: IO>Bluetooth
Labels: Test-Predator-Wrong
Owner: h...@chromium.org
Status: Assigned (was: Untriaged)
As per the  Issue 772002  owner, assigning this issue to @hans.
@hans -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes.
Thanks.

Comment 2 by h...@chromium.org, Nov 1 2017

Owner: pkalinnikov@chromium.org
pkalinnikov knows this code better.
Cc: engedy@chromium.org
Owner: jdoerrie@chromium.org
Jan, Balazs, please take care of this. Thanks.
This crash is caused because the fuzzer passes in a payload that extends 65536 bytes (i.e. it seems to disregard https://codesearch.chromium.org/chromium/src/device/u2f/BUILD.gn?l=111&rcl=d301cfc6b7aaf6b88738e16040534b5e8358aca2). Furthermore, DCHECKs are disabled, so https://codesearch.chromium.org/chromium/src/device/u2f/u2f_ble_frames.cc?l=53&rcl=473a6c9eed022eabe5b8029a7acad95988554a11 is a no-op. I'm not quite sure what exactly we should do here, I suppose in reality we can encounter payloads larger than 0xFFFF, so we should be able to handle this better. Maybe we can add a check for this to U2fBleFrame::IsValid()?
Looking at the crash statistics this appears to be fixed, but I will wait a few more days before I close this bug, just in case.
Status: Fixed (was: Assigned)
As there have been no further crashes in the last seven days I will mark this as fixed now.

Sign in to add a comment