[BUG] Segmentation Fault in ipc_comp_free during IPC3 Fuzz Testing #9742
Comments
|
@dbaluta @bhiregoudar @andyross fyi as impact with your configs |
|
Is this a regression? Odd that it's suddenly popping up. |
|
Also: can you attach that corpus file as a binary (or at least something like a base64 string that I can programmatically convert instead of writing software to do the endianness flipping on all the shorts)? And how was the fuzzer built, and with what config? |
The issue might have been hidden due to the fuzzer used in CI having limited code coverage. I am not certain about the coverage achieved by SOF under OSS-Fuzz, but it is possible that the current fuzzer configuration in CI is not exercising all code paths effectively.
Here is the corpus file encoded as a base64 string: BAAAAAAAAAAAAAAAAAAAABcAAAD/2QADMAb2ACwIYAgAAAAtLTwAEDAAACmHAAABMP//AwAGAAAIAPwAAAAAAAAAFwAA//4AAAMwA/YIYAAAACMBAAAAYAD2AAABMP//AwBBAAQAAAAAAAAAAAAAAAAAAAAXAAAA/9kAAzAGAAABMGAIAAAALS06ABAwAAAphwAAATD//wMAAfYIAPwAAAAAAAAAFwAA//4AAAIwAy8IYAAAACMBAAAAYAD2AgAAAIcAAAEw//8DAEEAAAMAABEA
The fuzzer was built using the script provided in the SOF repository (sof/scripts/fuzz.sh). System and Tool Versions:
|
I am not sure how to prioritize this bug. However, I believe it is not a blocker for the v2.12 release. |
Will need to fix for v2.12 as this has not root cause and could also impact other use cases and IPC4. |
|
@kv2019i @andyross I have identified the same problem using a fuzzer with UndefinedBehaviorSanitizer: INFO: Running with entropic power schedule (0xFF, 100).
INFO: 29455 files found in ./ipc3_corpus
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: seed corpus: files: 29455 min: 1b max: 510b total: 2367995b rss: 32Mb
/home/tmleman/work/repos/thesofproject/sof/zephyr/include/rtos/string.h:43:50: runtime error: addition of unsigned offset to 0x088fbb24 overflowed to 0x088fbb23
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/tmleman/work/repos/thesofproject/sof/zephyr/include/rtos/string.h:43:50 in
/home/tmleman/work/repos/thesofproject/sof/src/ipc/ipc-helper.c:308:2: runtime error: member access within null pointer of type 'struct list_item'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/tmleman/work/repos/thesofproject/sof/src/ipc/ipc-helper.c:308:2 in
/home/tmleman/work/repos/thesofproject/sof/src/ipc/ipc-helper.c:308:2: runtime error: load of null pointer of type 'struct list_item *'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/tmleman/work/repos/thesofproject/sof/src/ipc/ipc-helper.c:308:2 in
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==432370==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x00000000 (pc 0x080e38a0 bp 0xeb9fcfd8 sp 0xeb9fcfb0 T432404)
==432370==The signal is caused by a READ memory access.
==432370==Hint: address points to the zero page.
#0 0x80e38a0 in ipc_comp_free /home/tmleman/work/repos/thesofproject/sof/src/ipc/ipc-helper.c
UndefinedBehaviorSanitizer can not provide additional info.
SUMMARY: UndefinedBehaviorSanitizer: SEGV /home/tmleman/work/repos/thesofproject/sof/src/ipc/ipc-helper.c in ipc_comp_free
==432370==ABORTING
MS: 2 InsertRepeatedBytes-InsertByte-; base unit: b4f43ebcf03f40281d674b9e826e0d9be4f3ed4f
0x0,0x0,0x0,0x26,0x0,0xff,0x60,0x87,0x0,0x0,0x2,0x30,0x0,0x53,0x53,0x0,0xff,0x0,0x53,0x0,0x0,0x20,0x30,0x53,0x53,0x5b,0x53,0x53,0x51,0x0,0x0,0x1,0x50,0x53,0x53,0x53,0x0,0x0,0x1,0x30,0x0,0x0,0x0,0x2,0xff,0xff,0xff,0xff,0x2,0xff,0x19,0xff,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x24,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
\000\000\000&\000\377`\207\000\000\0020\000SS\000\377\000S\000\000 0SS[SSQ\000\000\001PSSS\000\000\0010\000\000\000\002\377\377\377\377\002\377\031\377\000\000\000\000\000\000\000\000\000$\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000
artifact_prefix='./findings/ipc3_2025-01-08_undefined/'; Test unit written to ./findings/ipc3_2025-01-08_undefined/crash-6eb29353a782085538e848200ca661280437a13b
Base64: AAAAJgD/YIcAAAIwAFNTAP8AUwAAIDBTU1tTU1EAAAFQU1NTAAABMAAAAAL/////Av8Z/wAAAAAAAAAAACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=The root cause is likely an uninitialized list of sources and sinks inside the IPC component device. In case of an issue within |
|
Hmm, not sure how we end up here. I've been trying to repro this with the provided corpus but no luck so far. It would seem commit 403c33f should catch an uninitialized bsink/source list, but this was merged already last year, so can't be this. ipc_get_comp_by_id() should be safe as well as the comp_list is initialized in ipc_init() which is part of posix platform init. The newer log seems to point to &icd->cd->bsource_list ... but yeah, there's a NULL check just before this. |
|
My first thought is that Linux bug from a few years back where a previous UB in the same context allowed the compiler to assume that a pointer must be valid and elide a check. :) Would be hilarious if we got bitten by the same kind of thing, but maybe that's too much too hope for. @tmleman if you have a failing build, can you build with CONFIG_OUTPUT_DISASSEMBLY and post the resulting zephyr.lst file? |
|
We are hitting timelimits for 2.12. As a) this is not tagged as release blocking, b) I can't reproduce with the provide corpus (albeit on a newer 24.04 Ubuntu based dev machine but still), and c) a fresh manual review of the code does not reveal gaps in ipc_comp_free, so a+b+c together I'll moved this to v2.13 and unassign myself for now. |
Ack - if it cant be reproduced from corpus then we can move, I suspect FW updates have fixed. We can close if no further fuzzer reports for v2.13 |
Describe the bug
A segmentation fault occurs in the
ipc_comp_freefunction during IPC3 fuzz testing. The issue is caused by a read memory access to a null pointer. This was detected using AddressSanitizer.To Reproduce
Reproduction Rate
The issue occurs consistently during fuzz testing.
Expected behavior
The fuzz testing should complete without causing a segmentation fault.
Impact
This issue is a showstopper as it prevents the completion of fuzz testing and affects the stability of the IPC3 configuration.
Environment
Screenshots or console output
The text was updated successfully, but these errors were encountered: