Null-dereference READ in task_start |
||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5029958945341440 Fuzzer: libFuzzer_chromeos_ec_cr50_fuzzer Job Type: libfuzzer_ubsan_chromeos Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x000000000000 Crash State: task_start test_main _main_thread Sanitizer: undefined (UBSAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5029958945341440 Issue filed automatically. See https://chromium.googlesource.com/chromiumos/docs/+/master/fuzzing.md#Reproducing-crashes-from-ClusterFuzz 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.
,
Oct 14
,
Oct 15
,
Oct 15
,
Oct 15
,
Oct 15
This looks like a bug in the fuzzing target rather than a true security bug.
,
Oct 30
allenwebb: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31
+metzman I am not sure why host_command_fuzz doesn't run into this.
,
Oct 31
,
Nov 6
Looks like this dies in the TSAN pthread_create interceptor code. That function call doesn't consume any fuzzer input, so I think it's safe to downgrade this to a regular bug. Who's the right owner for this? metzman@ perhaps?
,
Nov 6
TSan? How could TSan get enabled in UBSan build?
,
Nov 6
I'd suspect that there is a jump to 0 address happening in the following function:
void *_task_start_impl(void *a)
{
long tid = (long)a;
struct task_args *arg = task_info + tid;
my_task_id = tid;
pthread_mutex_lock(&run_lock);
/* Wait for scheduler */
task_wait_event(1);
tasks[tid].event = 0;
/* Start the task routine */
(arg->routine)(arg->d); // <------ HERE
/* Catch exited routine */
while (1)
task_wait_event(-1);
}
Are you sure it's not the case?
,
Nov 6
I will look into it.
,
Dec 4
Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This was caused by a bug in ClusterFuzz that has been fixed. Sorry again for the inconvenience.
,
Dec 4
ClusterFuzz testcase 5029958945341440 appears to be flaky, updating reproducibility label.
,
Dec 4
,
Dec 4
I think I accidentally left the message about reproducibility when bulk editing, but ClusterFuzz is correct that it is unreproducible. Let's see if it contradicts us again :-)
,
Dec 18
ClusterFuzz testcase 5029958945341440 is flaky and no longer crashes, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by xzhou@chromium.org
, Oct 14Components: OS>Firmware>EC