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.

Sign up for GitHub

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

Jump to bottom

This is a test commit #2

Closed
wants to merge 1 commit into from
Closed

This is a test commit #2

wants to merge 1 commit into from

Conversation

lpereira
Copy link
Collaborator

@lpereira lpereira commented Dec 8, 2016

Signed-off-by: Leandro Pereira leandro.pereira@intel.com

@lpereira
This is a test commit
6988cae 
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
@lpereira lpereira closed this Dec 8, 2016
zephyr-github pushed a commit that referenced this pull request Apr 20, 2017
@cvinayak
Bluetooth: controller: Channel Selection Algorithm #2
392b5de 
Add Bluetooth 5.0 LE Channel Selection Algorithm #2 feature

Jira: ZEP-2033

Change-id: Ic1155b4399882b89cab33cac78b08b7b39ff6f9d
Signed-off-by: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>
zephyr-github pushed a commit that referenced this pull request Apr 20, 2017
Merge bluetooth branch into master
c52fa3c 
 - newlib related fixes for the AT parser
 - Channel Selection Algorithm #2 support (Bluetooth 5.0 feature)
 - Better tracking of outgoing data (with callback support)
 - Various smaller cleanups & fixes

----------------------------------------------------------------
Carles Cufi (3):
      Bluetooth: HCI: Add Bluetooth 5.0 LE commands and events
      Bluetooth: HCI: Naming consistency tweaks
      Bluetooth: Use event masks instead of bits in controller and host

Johan Hedberg (8):
      Bluetooth: hci_raw: Fix ECC support
      Bluetooth: Add support for tracking transmitted packets
      Bluetooth: ATT: Enforce flow for incoming requests & indications
      Bluetooth: SMP: Track when last key distribution PDU has been sent
      Bluetooth: Introduce a timeout for synchronous HCI command sending
      Bluetooth: ATT: Fix bogus CONTAINER_OF() usage
      Bluetooth: Introduce flow control for outgoing ATT packets
      Bluetooth: ATT: Start response timer only after actual transmission

Kumar Gala (3):
      Bluetooth: AT: use explicit unsigned char to avoid array subscript error
      Bluetooth: AT: Fix building with newlib
      Bluetooth: AT: Unit: Fixup include search path

Luiz Augusto von Dentz (4):
      Bluetooth: ipsp: Add TX pools for TCP
      Bluetooth: L2CAP: Try to allocate segment from the original pool
      net: buf: Add net_buf_reset
      Bluetooth: L2CAP: Reuse request buffer to respond

Vinayak Chettimada (5):
      Bluetooth: controller: Rename channel/chnl to chan
      Bluetooth: HCI: Add Bluetooth 5.0 FeatureSet field's bit mapping
      Bluetooth: Fix missing LE conn param req bit in set LE evt mask
      Bluetooth: controller: Support BT 5.0 feature set bit fields
      Bluetooth: controller: Channel Selection Algorithm #2

 include/bluetooth/hci.h                           | 495 +++++++++++++++--
 include/bluetooth/l2cap.h                         |   2 +-
 include/net/buf.h                                 |   9 +
 samples/bluetooth/ipsp/src/main.c                 |  15 +
 subsys/bluetooth/controller/Kconfig               |   7 +
 subsys/bluetooth/controller/hal/nrf5/radio.c      |   4 +-
 subsys/bluetooth/controller/hal/radio.h           |   2 +-
 subsys/bluetooth/controller/hci/hci.c             |  95 ++--
 subsys/bluetooth/controller/ll_sw/ctrl.c          | 622 ++++++++++++++++------
 subsys/bluetooth/controller/ll_sw/ctrl.h          |  71 ++-
 subsys/bluetooth/controller/ll_sw/ctrl_internal.h |  25 +-
 subsys/bluetooth/controller/ll_sw/ll.c            |  24 +-
 subsys/bluetooth/controller/ll_sw/pdu.h           |  12 +-
 subsys/bluetooth/host/Kconfig                     |  31 ++
 subsys/bluetooth/host/at.c                        |   2 +-
 subsys/bluetooth/host/at.h                        |   2 +-
 subsys/bluetooth/host/att.c                       | 230 ++++++--
 subsys/bluetooth/host/conn.c                      | 111 +++-
 subsys/bluetooth/host/conn_internal.h             |  23 +-
 subsys/bluetooth/host/hci_core.c                  | 163 +++---
 subsys/bluetooth/host/hci_core.h                  |   3 +-
 subsys/bluetooth/host/hci_ecc.c                   |   2 +-
 subsys/bluetooth/host/hci_raw.c                   |   4 +
 subsys/bluetooth/host/hfp_hf.c                    |   2 +
 subsys/bluetooth/host/l2cap.c                     |  79 ++-
 subsys/bluetooth/host/l2cap_internal.h            |  12 +-
 subsys/bluetooth/host/sdp.c                       |   2 +
 subsys/bluetooth/host/smp.c                       | 117 +++-
 subsys/net/buf.c                                  |  12 +-
 tests/bluetooth/init/prj_controller_4_0.conf      |   1 +
 tests/unit/bluetooth/at/src/Makefile              |   2 +-
 tests/unit/bluetooth/at/src/main.c                |   2 +-
 32 files changed, 1695 insertions(+), 488 deletions(-)

Change-Id: I17f9e49e1347a38bc78be3bdcaa596e41d83da56
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
zephyr-github pushed a commit that referenced this pull request Apr 22, 2017
@nashif
arm: exception-assisted kernel panic/oops support
75caa2b 
Put the reason code in r0 and make a SVC #2 call, which will be
propagated to _fatal_error_handler as an exception.

The _is_in_isr() implementation had to be tweaked a bit.  User-generated
SVC exception no longer just used for irq_offload(); just because we are
in it does not mean we are in interrupt context.  Instead, have the
irq_offload code set and clear the offload_routine global; it will be
non-NULL only if it's in use. Upcoming changes to support memory
protection (which will require system calls) will need this too.

We free up some small amount of ROM deleting _default_esf struct as it's
no longer needed.

Issue: ZEP-843
Change-Id: Ie82bd708575934cffe41e64f5c128c8704ca4e48
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
@mike-scott mike-scott mentioned this pull request Jul 7, 2017
Merged
nashif referenced this pull request in nashif/zephyr Aug 25, 2017
@SebastianBoe
Merge pull request #2 from nashif/cmake_anas2
4d619d2 
WIP: improve sanitycheck and add more SoCs and samples
This was referenced Sep 11, 2017
Merged
Merged
This was referenced Sep 23, 2017
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
AbhinavMir added a commit to AbhinavMir/zephyr that referenced this pull request Jan 27, 2024
@AbhinavMir @cfriedt
# This is a combination of 6 commits.
318c70e 
# This is the 1st commit message:

posix: Tests for putmsg

Add in tests for putmsg impl and headers

Signed-off-by: Abhinav Srivastava <atg271@gmail.com>

# This is the commit message zephyrproject-rtos#2:

posix: Tests for putmsg

Add tests for implentation and header file.

Signed-off-by: Abhinav Srivastava <atg271@gmail.com>

# This is the commit message zephyrproject-rtos#3:

posix: fix stropts_h.c faulty imports and function usage

# This is the commit message zephyrproject-rtos#4:

posix: fix streams config symbol

Makes more sense to use CONFIG_POSIX_STROPTS

Signed-off-by: Abhinav Srivastava <atg271@gmail.com>

# This is the commit message zephyrproject-rtos#5:

Revert "posix: fix streams config symbol"

This reverts commit aa03b70.

Signed-off-by: Abhinav Srivastava <atg271@gmail.com>

# This is the commit message zephyrproject-rtos#6:

Update tests/posix/headers/src/stropts_h.c

Co-authored-by: Chris Friedt <chrisfriedt@gmail.com>
marc-hb added a commit to marc-hb/zephyr that referenced this pull request Feb 3, 2024
@marc-hb
arch/posix.h: implement ARCH_EXCEPT() with abort() for debug convenience
0014be9 
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is
hit in native_posix mode.

One of the main purposes of `native_posix` is to provide debug
convenience. When running in a debugger, `abort()` stops execution which
provides a backtrace and the ability to inspect all variables.

A practical use case is fuzzing failures in SOF, see an example in:
thesofproject/sof#8632

In such a case, this commit adds value even before using a
debugger. Without this commit, confusingly meaningless stack trace:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
Exiting due to fatal error
==314134== ERROR: libFuzzer: fuzz target exited
    #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637)
    #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b)
    zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+
    zephyrproject-rtos#4 0xf783dfe8  (/usr/lib32/libc.so.6+0x3dfe8)
    zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6)
    zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2

SUMMARY: libFuzzer: fuzz target exited
```

Thanks to this commit the `k_panic()` location is immediately available
in the logs without even running anything:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
==315176== ERROR: libFuzzer: deadly signal
LLVMSymbolizer: error reading file: No such file or directory
    #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647)
    #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b)
    zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback()
    zephyrproject-rtos#4 0xf7f3159f  (linux-gate.so.1+0x59f)
    zephyrproject-rtos#5 0xf7f31578  (linux-gate.so.1+0x578)
    zephyrproject-rtos#6 0xf788ea16  (/usr/lib32/libc.so.6+0x8ea16)
    zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316)
    zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120)
    zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better
    crash reports.
SUMMARY: libFuzzer: deadly signal
```

Full stack trace When running zephyr.exe in gdb:

```

./scripts/fuzz.sh  -- -DEXTRA_CFLAGS="-O0 -g3"

gdb ./zephyr.exe

backtrace

 zephyrproject-rtos#2  0xf783b317 in raise () from /usr/lib32/libc.so.6
 zephyrproject-rtos#3  0xf7822121 in abort () from /usr/lib32/libc.so.6
 zephyrproject-rtos#4  0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623
 zephyrproject-rtos#5  0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0)
                                    at src/platform/posix/ipc.c:162
 zephyrproject-rtos#6  0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>)
                                    at src/ipc/ipc-common.c:328
 zephyrproject-rtos#7  0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>)
                                    at zephyr/include/rtos/task.h:94
 zephyrproject-rtos#8  0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>)
                                    at zephyr/edf_schedule.c:32
 zephyrproject-rtos#9  0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...)
                                         at zephyr/kernel/work.c:688
 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,..
                                    at zephyr/lib/os/thread_entry.c:48
 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 ..
                                  at zephyr/arch/posix/core/thread.c:56
 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4)
                              at zephyr/arch/posix/core/posix_core.c:293
 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) ()
 zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6
```

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb added a commit to marc-hb/zephyr that referenced this pull request Feb 3, 2024
@marc-hb
arch/posix.h: implement ARCH_EXCEPT() with abort() for debug convenience
c4254ba 
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is
hit in native_posix mode.

One of the main purposes of `native_posix` is to provide debug
convenience. When running in a debugger, `abort()` stops execution which
provides a backtrace and the ability to inspect all variables.

A practical use case is fuzzing failures in SOF, see an example in:
thesofproject/sof#8632

In such a case, this commit adds value even before using a
debugger. Without this commit, confusingly meaningless stack trace:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
Exiting due to fatal error
==314134== ERROR: libFuzzer: fuzz target exited
    #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637)
    #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b)
    zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+
    zephyrproject-rtos#4 0xf783dfe8  (/usr/lib32/libc.so.6+0x3dfe8)
    zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6)
    zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2

SUMMARY: libFuzzer: fuzz target exited
```

Thanks to this commit the `k_panic()` location is immediately available
in the logs without even running anything:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
==315176== ERROR: libFuzzer: deadly signal
LLVMSymbolizer: error reading file: No such file or directory
    #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647)
    #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b)
    zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback()
    zephyrproject-rtos#4 0xf7f3159f  (linux-gate.so.1+0x59f)
    zephyrproject-rtos#5 0xf7f31578  (linux-gate.so.1+0x578)
    zephyrproject-rtos#6 0xf788ea16  (/usr/lib32/libc.so.6+0x8ea16)
    zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316)
    zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120)
    zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better
    crash reports.
SUMMARY: libFuzzer: deadly signal
```

Full stack trace When running zephyr.exe in gdb:

```

./scripts/fuzz.sh  -- -DEXTRA_CFLAGS="-O0 -g3"

gdb ./zephyr.exe

backtrace

 zephyrproject-rtos#2  0xf783b317 in raise () from /usr/lib32/libc.so.6
 zephyrproject-rtos#3  0xf7822121 in abort () from /usr/lib32/libc.so.6
 zephyrproject-rtos#4  0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623
 zephyrproject-rtos#5  0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0)
                                    at src/platform/posix/ipc.c:162
 zephyrproject-rtos#6  0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>)
                                    at src/ipc/ipc-common.c:328
 zephyrproject-rtos#7  0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>)
                                    at zephyr/include/rtos/task.h:94
 zephyrproject-rtos#8  0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>)
                                    at zephyr/edf_schedule.c:32
 zephyrproject-rtos#9  0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...)
                                         at zephyr/kernel/work.c:688
 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,..
                                    at zephyr/lib/os/thread_entry.c:48
 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 ..
                                  at zephyr/arch/posix/core/thread.c:56
 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4)
                              at zephyr/arch/posix/core/posix_core.c:293
 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) ()
 zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6
```

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb added a commit to marc-hb/zephyr that referenced this pull request Feb 3, 2024
@marc-hb
arch/posix.h: implement ARCH_EXCEPT() with abort() for debug convenience
682b2fe 
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is
hit in native_posix mode.

One of the main purposes of `native_posix` is to provide debug
convenience. When running in a debugger, `abort()` stops execution which
provides a backtrace and the ability to inspect all variables.

A good, sample use case is fuzzing failures in SOF, see an example in:
thesofproject/sof#8632

In such a case, this commit adds value even before using a
debugger. Without this commit, confusingly meaningless stack trace:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
Exiting due to fatal error
==314134== ERROR: libFuzzer: fuzz target exited
    #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637)
    #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b)
    zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+
    zephyrproject-rtos#4 0xf783dfe8  (/usr/lib32/libc.so.6+0x3dfe8)
    zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6)
    zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2

SUMMARY: libFuzzer: fuzz target exited
```

Thanks to this commit the `k_panic()` location is now immediately
available in test logs without even running anything locally:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
@ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623
ZEPHYR FATAL ERROR: 3
==315176== ERROR: libFuzzer: deadly signal
LLVMSymbolizer: error reading file: No such file or directory
    #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647)
    #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b)
    zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback()
    zephyrproject-rtos#4 0xf7f3159f  (linux-gate.so.1+0x59f)
    zephyrproject-rtos#5 0xf7f31578  (linux-gate.so.1+0x578)
    zephyrproject-rtos#6 0xf788ea16  (/usr/lib32/libc.so.6+0x8ea16)
    zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316)
    zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120)
    zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better
    crash reports.
SUMMARY: libFuzzer: deadly signal
```

The full stack trace is now immediately available when running
zephyr.exe in gdb:

```
./scripts/fuzz.sh  -- -DEXTRA_CFLAGS="-O0 -g3"

gdb build-fuzz/zephyr/zephyr.exe

run
backtrace

 zephyrproject-rtos#2  0xf783b317 in raise () from /usr/lib32/libc.so.6
 zephyrproject-rtos#3  0xf7822121 in abort () from /usr/lib32/libc.so.6
 zephyrproject-rtos#4  0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623
 zephyrproject-rtos#5  0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0)
                                    at src/platform/posix/ipc.c:162
 zephyrproject-rtos#6  0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>)
                                    at src/ipc/ipc-common.c:328
 zephyrproject-rtos#7  0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>)
                                    at zephyr/include/rtos/task.h:94
 zephyrproject-rtos#8  0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>)
                                    at zephyr/edf_schedule.c:32
 zephyrproject-rtos#9  0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...)
                                         at zephyr/kernel/work.c:688
 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,..
                                    at zephyr/lib/os/thread_entry.c:48
 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 ..
                                  at zephyr/arch/posix/core/thread.c:56
 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4)
                              at zephyr/arch/posix/core/posix_core.c:293
 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) ()
 zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6
```

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb added a commit to marc-hb/zephyr that referenced this pull request Feb 5, 2024
@marc-hb
arch/posix.h: implement ARCH_EXCEPT() with abort() for debug convenience
baa99ea 
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is
hit in native_posix mode.

One of the main purposes of `native_posix` is to provide debug
convenience. When running in a debugger, `abort()` stops execution which
provides a backtrace and the ability to inspect all variables.

A good, sample use case is fuzzing failures in SOF, see an example in:
thesofproject/sof#8632

In such a case, this commit adds value even before using a
debugger. Without this commit, confusingly meaningless stack trace:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
Exiting due to fatal error
==314134== ERROR: libFuzzer: fuzz target exited
    #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637)
    #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b)
    zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+
    zephyrproject-rtos#4 0xf783dfe8  (/usr/lib32/libc.so.6+0x3dfe8)
    zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6)
    zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2

SUMMARY: libFuzzer: fuzz target exited
```

Thanks to this commit the `k_panic()` location is now immediately
available in test logs without even running anything locally:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
@ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623
ZEPHYR FATAL ERROR: 3
==315176== ERROR: libFuzzer: deadly signal
LLVMSymbolizer: error reading file: No such file or directory
    #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647)
    #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b)
    zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback()
    zephyrproject-rtos#4 0xf7f3159f  (linux-gate.so.1+0x59f)
    zephyrproject-rtos#5 0xf7f31578  (linux-gate.so.1+0x578)
    zephyrproject-rtos#6 0xf788ea16  (/usr/lib32/libc.so.6+0x8ea16)
    zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316)
    zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120)
    zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better
    crash reports.
SUMMARY: libFuzzer: deadly signal
```

The full stack trace is now immediately available when running
zephyr.exe in gdb:

```
./scripts/fuzz.sh  -- -DEXTRA_CFLAGS="-O0 -g3"

gdb build-fuzz/zephyr/zephyr.exe

run
backtrace

 zephyrproject-rtos#2  0xf783b317 in raise () from /usr/lib32/libc.so.6
 zephyrproject-rtos#3  0xf7822121 in abort () from /usr/lib32/libc.so.6
 zephyrproject-rtos#4  0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623
 zephyrproject-rtos#5  0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0)
                                    at src/platform/posix/ipc.c:162
 zephyrproject-rtos#6  0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>)
                                    at src/ipc/ipc-common.c:328
 zephyrproject-rtos#7  0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>)
                                    at zephyr/include/rtos/task.h:94
 zephyrproject-rtos#8  0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>)
                                    at zephyr/edf_schedule.c:32
 zephyrproject-rtos#9  0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...)
                                         at zephyr/kernel/work.c:688
 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,..
                                    at zephyr/lib/os/thread_entry.c:48
 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 ..
                                  at zephyr/arch/posix/core/thread.c:56
 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4)
                              at zephyr/arch/posix/core/posix_core.c:293
 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) ()
 zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6
```

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb added a commit to marc-hb/zephyr that referenced this pull request Feb 5, 2024
@marc-hb
arch/posix.h: implement ARCH_EXCEPT() with abort() for debug convenience
0eac9e2 
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is
hit in native_posix mode.

One of the main purposes of `native_posix` is to provide debug
convenience. When running in a debugger, `abort()` stops execution which
provides a backtrace and the ability to inspect all variables.

A good, sample use case is fuzzing failures in SOF, see an example in:
thesofproject/sof#8632

In such a case, this commit adds value even before using a
debugger. Without this commit, confusingly meaningless stack trace:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
Exiting due to fatal error
==314134== ERROR: libFuzzer: fuzz target exited
    #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637)
    #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b)
    zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+
    zephyrproject-rtos#4 0xf783dfe8  (/usr/lib32/libc.so.6+0x3dfe8)
    zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6)
    zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2

SUMMARY: libFuzzer: fuzz target exited
```

Thanks to this commit the `k_panic()` location is now immediately
available in test logs without even running anything locally:

```
INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb
@ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623
ZEPHYR FATAL ERROR: 3
==315176== ERROR: libFuzzer: deadly signal
LLVMSymbolizer: error reading file: No such file or directory
    #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647)
    #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b)
    zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o
    zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback()
    zephyrproject-rtos#4 0xf7f3159f  (linux-gate.so.1+0x59f)
    zephyrproject-rtos#5 0xf7f31578  (linux-gate.so.1+0x578)
    zephyrproject-rtos#6 0xf788ea16  (/usr/lib32/libc.so.6+0x8ea16)
    zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316)
    zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120)
    zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better
    crash reports.
SUMMARY: libFuzzer: deadly signal
```

The full stack trace is now immediately available when running
zephyr.exe in gdb:

```
./scripts/fuzz.sh  -- -DEXTRA_CFLAGS="-O0 -g3"

gdb build-fuzz/zephyr/zephyr.exe

run
backtrace

 zephyrproject-rtos#2  0xf783b317 in raise () from /usr/lib32/libc.so.6
 zephyrproject-rtos#3  0xf7822121 in abort () from /usr/lib32/libc.so.6
 zephyrproject-rtos#4  0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623
 zephyrproject-rtos#5  0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0)
                                    at src/platform/posix/ipc.c:162
 zephyrproject-rtos#6  0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>)
                                    at src/ipc/ipc-common.c:328
 zephyrproject-rtos#7  0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>)
                                    at zephyr/include/rtos/task.h:94
 zephyrproject-rtos#8  0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>)
                                    at zephyr/edf_schedule.c:32
 zephyrproject-rtos#9  0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...)
                                         at zephyr/kernel/work.c:688
 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,..
                                    at zephyr/lib/os/thread_entry.c:48
 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 ..
                                  at zephyr/arch/posix/core/thread.c:56
 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4)
                              at zephyr/arch/posix/core/posix_core.c:293
 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) ()
 zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6
```

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
@andyross andyross mentioned this pull request Feb 20, 2024
Closed
@lgl88911 lgl88911 mentioned this pull request Mar 2, 2024
Closed
@dberlin dberlin mentioned this pull request Mar 8, 2024
Closed
@mdubielx mdubielx mentioned this pull request Mar 13, 2024
Merged
@teburd teburd mentioned this pull request Apr 24, 2024
Merged
@anangl anangl mentioned this pull request Apr 25, 2024
Merged
@mellila-abd mellila-abd mentioned this pull request May 23, 2024
Closed
@AfflatusX AfflatusX mentioned this pull request May 30, 2024
Open
ldenefle pushed a commit to ldenefle/zephyr that referenced this pull request Jun 20, 2024
@davidbascelli
Merge pull request zephyrproject-rtos#2 from converge-io/david/eg25_l…
1eb9d67 
…ow_power_mode

drivers: modem: this commit adds a low power sleep modem script to mo…
RICCIARDI-Adrien added a commit to RICCIARDI-Adrien/zephyr that referenced this pull request Jun 24, 2024
@RICCIARDI-Adrien
tests: fs: nvs: Add undetected bad ATE length + offset test
4fe6002 
Tamper an ATE to simulate an ATE CRC-8 undetected error.
Write 4 items of various data size, with the item zephyrproject-rtos#1 simulating a CRC-8
undetected error on the item offset and size.
The offset is decreased to overflow on the preceding item #0.
The data size is increased to overflow on item 2 and part of item 3.

Thanks to the data CRC-32, reading item zephyrproject-rtos#1 returns an error.
After running the garbage collector, the faulty item 1 has been copied
with parts of items #0, zephyrproject-rtos#2 and zephyrproject-rtos#3 data.
The other items are healthy and the NVS is still working.

Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
RICCIARDI-Adrien added a commit to RICCIARDI-Adrien/zephyr that referenced this pull request Jun 24, 2024
@RICCIARDI-Adrien
tests: fs: nvs: Add undetected bad ATE length + offset test
4cd00d8 
Tamper an ATE to simulate an ATE CRC-8 undetected error.
Write 4 items of various data size, with the item zephyrproject-rtos#1 simulating a CRC-8
undetected error on the item offset and size.
The offset is decreased to overflow on the preceding item #0.
The data size is increased to overflow on item 2 and part of item 3.

Thanks to the data CRC-32, reading item zephyrproject-rtos#1 returns an error.
After running the garbage collector, the faulty item 1 has been copied
with parts of items #0, zephyrproject-rtos#2 and zephyrproject-rtos#3 data.
The other items are healthy and the NVS is still working.

Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
RICCIARDI-Adrien added a commit to RICCIARDI-Adrien/zephyr that referenced this pull request Jun 24, 2024
@RICCIARDI-Adrien
tests: fs: nvs: Add undetected bad ATE length + offset test
bd026a3 
Tamper an ATE to simulate an ATE CRC-8 undetected error.
Write 4 items of various data size, with the item zephyrproject-rtos#1 simulating a CRC-8
undetected error on the item offset and size.
The offset is decreased to overflow on the preceding item #0.
The data size is increased to overflow on item 2 and part of item 3.

Thanks to the data CRC-32, reading item zephyrproject-rtos#1 returns an error.
After running the garbage collector, the faulty item 1 has been copied
with parts of items #0, zephyrproject-rtos#2 and zephyrproject-rtos#3 data.
The other items are healthy and the NVS is still working.

Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
RICCIARDI-Adrien added a commit to RICCIARDI-Adrien/zephyr that referenced this pull request Jun 24, 2024
@RICCIARDI-Adrien
tests: fs: nvs: Add undetected bad ATE length + offset test
ca55765 
Tamper an ATE to simulate an ATE CRC-8 undetected error.
Write 4 items of various data size, with the item zephyrproject-rtos#1 simulating a CRC-8
undetected error on the item offset and size.
The offset is decreased to overflow on the preceding item #0.
The data size is increased to overflow on item 2 and part of item 3.

Thanks to the data CRC-32, reading item zephyrproject-rtos#1 returns an error.
After running the garbage collector, the faulty item 1 has been copied
with parts of items #0, zephyrproject-rtos#2 and zephyrproject-rtos#3 data.
The other items are healthy and the NVS is still working.

Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
LukaszMrugala pushed a commit to LukaszMrugala/zephyr that referenced this pull request Jul 3, 2024
@chrisvintc
ci.git revamp (zephyrproject-rtos#2)
6099f37 
* updating readme, adding ci.wiki from gitlab

* Adding git secret protected hidden/ directory with teamforge zdevops-keys, cvondra@zephyr-ci.jf.intel.com access only, currently.

* Adding ci.git wiki files

* move functional directories into /src, removed skiplist + overdue README.md update

* Update README.md

* hide-hidden: clarify script operation comments

* Adding zabbix server install script to /src/zabbix

* Adding gpg key for connor.graydon@intel.com to hidden/ keyring
@krish2718 krish2718 mentioned this pull request Aug 14, 2024
Open
@kartben kartben mentioned this pull request Sep 11, 2024
Merged
swkim101 added a commit to swkim101/zephyr that referenced this pull request Oct 10, 2024
@swkim101
Bluetooth: userchan: fix buffer overflow hci_packet_complete()
1807c99 
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in over 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    zephyrproject-rtos#1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    zephyrproject-rtos#2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in '/mnt/hdd1/sungwoo/zephyr-afl/zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    zephyrproject-rtos#2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    zephyrproject-rtos#3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    zephyrproject-rtos#4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    zephyrproject-rtos#5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    zephyrproject-rtos#6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
@FRASTM FRASTM mentioned this pull request Oct 21, 2024
Open
swkim101 added a commit to swkim101/zephyr that referenced this pull request Oct 23, 2024
@swkim101
Bluetooth: userchan: fix buffer overflow in hci_packet_complete()
dc6d054 
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in over 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    zephyrproject-rtos#1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    zephyrproject-rtos#2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    zephyrproject-rtos#2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    zephyrproject-rtos#3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    zephyrproject-rtos#4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    zephyrproject-rtos#5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    zephyrproject-rtos#6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
swkim101 added a commit to swkim101/zephyr that referenced this pull request Oct 24, 2024
@swkim101
Bluetooth: userchan: fix buffer overflow in hci_packet_complete()
7458a3c 
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    zephyrproject-rtos#1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    zephyrproject-rtos#2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    zephyrproject-rtos#2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    zephyrproject-rtos#3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    zephyrproject-rtos#4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    zephyrproject-rtos#5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    zephyrproject-rtos#6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
aescolar pushed a commit that referenced this pull request Oct 25, 2024
@swkim101 @aescolar
Bluetooth: userchan: fix buffer overflow in hci_packet_complete()
88de271 
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    #1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    #2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x530192  (/root/zephyr.exe+0x530192)
    #2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x530192  (/root/zephyr.exe+0x530192)
    #2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    #1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    #2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    #3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    #4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    #5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    #6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
anhuba pushed a commit to anhuba/zephyr that referenced this pull request Oct 28, 2024
@swkim101 @anhuba
Bluetooth: userchan: fix buffer overflow in hci_packet_complete()
7ba60a6 
hci_packet_complete(buf, buf_size) should check whether buf_size is
enough.
For instance, hci_packet_complete can receive buf with buf_size 1,
leading to the buffer overflow in cmd->param_len, which is buf[3].
This can happen when rx_thread() receives two frames in 512 bytes
and the first frame size is 511. Then, rx_thread() will call
hci_packet_complete() with 1.

==5==ERROR: AddressSanitizer: global-buffer-overflow on address
0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68

READ of size 2 at 0x000000ad81c2 thread T6
    #0 0x5279b2  (/root/zephyr.exe+0x5279b2)
    zephyrproject-rtos#1 0x4d697d  (/root/zephyr.exe+0x4d697d)
    zephyrproject-rtos#2 0x7ffff60e5daa  (/lib/x86_64-linux-gnu/libc.so.6+0x89daa)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

0x000000ad81c2 is located 2 bytes to the right of global variable
'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c'
(0xad7fc0) of size 512
SUMMARY: AddressSanitizer: global-buffer-overflow
(/root/zephyr.exe+0x5279b2)
Thread T6 created by T2 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T2 created by T1 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x530192  (/root/zephyr.exe+0x530192)
    zephyrproject-rtos#2 0x4dcc22  (/root/zephyr.exe+0x4dcc22)

Thread T1 created by T0 here:
    #0 0x48c17c  (/root/zephyr.exe+0x48c17c)
    zephyrproject-rtos#1 0x52f36c  (/root/zephyr.exe+0x52f36c)
    zephyrproject-rtos#2 0x5371dc  (/root/zephyr.exe+0x5371dc)
    zephyrproject-rtos#3 0x5312a6  (/root/zephyr.exe+0x5312a6)
    zephyrproject-rtos#4 0x52ed7b  (/root/zephyr.exe+0x52ed7b)
    zephyrproject-rtos#5 0x52eddd  (/root/zephyr.exe+0x52eddd)
    zephyrproject-rtos#6 0x7ffff6083c89  (/lib/x86_64-linux-gnu/libc.so.6+0x27c89)
(BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c)

==5==ABORTING

Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
@bayannagetteboina-eaton bayannagetteboina-eaton mentioned this pull request Nov 12, 2024
Open
@SureshotM6 SureshotM6 mentioned this pull request Nov 27, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@lpereira