Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] bad coding patterns leading to security bugs/crashes #9563

Open
cujomalainey opened this issue Oct 9, 2024 · 2 comments
Open

[BUG] bad coding patterns leading to security bugs/crashes #9563

cujomalainey opened this issue Oct 9, 2024 · 2 comments
Labels
bug Something isn't working as expected
Milestone

Comments

@cujomalainey
Copy link
Contributor

Describe the bug
Lack of size checks on blobs or topology state.
E.g.

  • comp_dev_get_first_data_* missing nullity checks
  • comp_get_data_blob not checking the size params
  • Not checking both upper and lower bounds on init data

To Reproduce
fuzz

Reproduction Rate
high

Expected behavior
robust code

Impact
security

Possible long term fix
Algebraic typing (RUST!)

Short term fixes
Some sort of checks on special functions we know are misused using CI tooling

@cujomalainey cujomalainey added the bug Something isn't working as expected label Oct 9, 2024
@kv2019i
Copy link
Collaborator

kv2019i commented Oct 11, 2024

This warrants a wider discussion. Maybe start from these concrete examples and see if there is something systematic and then file for fine-grained items to address. Do you @cujomalainey a stack trace from fuzz to some example case for e.g. comp_dev_get_first_data()? There is a clear assumption at least one buffer is always connected, but if this check can be avoided, this is indeed a problem.

As comp_dev_get_first_data_() is quite recent addition, I'll loop in @marcinszkudlinski to comment on this. Did you consider how to handle NULL returns (it does look you just kept the semantics of the old list_first_item().

@cujomalainey
Copy link
Contributor Author

I don't have any examples of comp_get_data_blob yet but its not hard to see the relationship between the binary coming from the IPC (I.e. user space). The issue is not that there is a buffer, its that the buffer is the size we expect. If user space passed in a single byte and we were expecting 20, that is an issue if we don't check the size.

Regarding the buffer checks, here is an example where the fuzzer called trigger on an disconnected selector

AddressSanitizer:DEADLYSIGNAL

==20834==ERROR: AddressSanitizer: SEGV on unknown address 0x00000088 (pc 0x082409de bp 0xec2dfd78 sp 0xec2dfd60 T7)
==20834==The signal is caused by a READ memory access.
==20834==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x82409de in selector_trigger sof_workspace/sof/src/audio/selector/selector.c:354:32
#1 0x81fa636 in comp_trigger_local sof_workspace/sof/src/include/sof/audio/component_ext.h:154:8
#2 0x81fa4d8 in comp_trigger sof_workspace/sof/src/include/sof/audio/component_ext.h:184:9
#3 0x81f955f in pipeline_comp_trigger sof_workspace/sof/src/audio/pipeline/pipeline-stream.c:507:8
#4 0x81f7a64 in pipeline_trigger_run sof_workspace/sof/src/audio/pipeline/pipeline-stream.c:569:8
#5 0x81c9fa2 in ipc_stream_trigger sof_workspace/sof/src/ipc/ipc3/handler.c:522:9
#6 0x81c48d6 in ipc_cmd sof_workspace/sof/src/ipc/ipc3/handler.c:1664:9
#7 0x81dd8d9 in ipc_platform_do_cmd sof_workspace/sof/src/platform/posix/ipc.c:160:2
#8 0x81d6e0c in ipc_do_cmd sof_workspace/sof/src/ipc/ipc-common.c:350:9
#9 0x81fe70b in task_run sof_workspace/sof/zephyr/include/rtos/task.h:94:9
#10 0x81fe298 in edf_work_handler sof_workspace/sof/zephyr/edf_schedule.c:32:16
#11 0x8314571 in work_queue_main sof_workspace/zephyr/kernel/work.c:688:3
#12 0x81ac4b2 in z_thread_entry sof_workspace/zephyr/lib/os/thread_entry.c:48:2

@lgirdwood lgirdwood added this to the v2.12 milestone Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working as expected
Projects
None yet
Development

No branches or pull requests

3 participants