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

zephyr-master_fork #1

Closed
wants to merge 2 commits into from
Closed

zephyr-master_fork #1

wants to merge 2 commits into from

Conversation

prasannakarthik
Copy link

No description provided.

Prasanna Karthik added 2 commits November 1, 2016 17:32
Signed-off-by: Prasanna Karthik <pkarthik@intrinsyc.com>
Signed-off-by: Prasanna Karthik <pkarthik@intrinsyc.com>
zephyr-github pushed a commit that referenced this pull request Mar 15, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data
register to change the state of individual GPIOs. The generated
assembler needs at least 3 instructions: load / modify / store.

This opens a small race window, for example if a thread and an
interrupt both try to change the state of the same GPIO bank.

Use the GPIO bit set/reset register to perform the atomic change without
locking.

This also has the benefit of a more optimised implementation, which can
be useful for GPIO-intensive work. Compare the new version:

08000c98 <stm32_gpio_set>:
 8000c98:       f001 010f       and.w   r1, r1, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #20]
 8000ca4:       b10a            cbz     r2, 8000caa <stm32_gpio_set+0x12>
 8000ca6:       4319            orrs    r1, r3
 8000ca8:       e001            b.n     8000cae <stm32_gpio_set+0x16>
 8000caa:       ea23 0101       bic.w   r1, r3, r1
 8000cae:       6141            str     r1, [r0, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github pushed a commit that referenced this pull request Mar 17, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data
register to change the state of individual GPIOs. The generated
assembler needs at least 3 instructions: load / modify / store.

This opens a small race window, for example if a thread and an
interrupt both try to change the state of the same GPIO bank.

Use the GPIO bit set/reset register to perform the atomic change without
locking.

This also has the benefit of a more optimised implementation, which can
be useful for GPIO-intensive work. Compare the new version:

08000c98 <stm32_gpio_set>:
 8000c98:       f001 010f       and.w   r1, r1, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #20]
 8000ca4:       b10a            cbz     r2, 8000caa <stm32_gpio_set+0x12>
 8000ca6:       4319            orrs    r1, r3
 8000ca8:       e001            b.n     8000cae <stm32_gpio_set+0x16>
 8000caa:       ea23 0101       bic.w   r1, r3, r1
 8000cae:       6141            str     r1, [r0, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github pushed a commit that referenced this pull request Mar 21, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data
register to change the state of individual GPIOs. The generated
assembler needs at least 3 instructions: load / modify / store.

This opens a small race window, for example if a thread and an
interrupt both try to change the state of the same GPIO bank.

Use the GPIO bit set/reset register to perform the atomic change without
locking.

This also has the benefit of a more optimised implementation, which can
be useful for GPIO-intensive work. Compare the new version:

08000c98 <stm32_gpio_set>:
 8000c98:       f001 010f       and.w   r1, r1, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #20]
 8000ca4:       b10a            cbz     r2, 8000caa <stm32_gpio_set+0x12>
 8000ca6:       4319            orrs    r1, r3
 8000ca8:       e001            b.n     8000cae <stm32_gpio_set+0x16>
 8000caa:       ea23 0101       bic.w   r1, r3, r1
 8000cae:       6141            str     r1, [r0, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
zephyr-github pushed a commit that referenced this pull request Mar 27, 2017
The current implementation of stm32_gpio_set() uses the GPIO output data
register to change the state of individual GPIOs. The generated
assembler needs at least 3 instructions: load / modify / store.

This opens a small race window, for example if a thread and an
interrupt both try to change the state of the same GPIO bank.

Use the GPIO bit set/reset register to perform the atomic change without
locking.

This also has the benefit of a more optimised implementation, which can
be useful for GPIO-intensive work. Compare the new version:

08000c98 <stm32_gpio_set>:
 8000c98:       f001 010f       and.w   r1, r1, #15
 8000c9c:       2301            movs    r3, #1
 8000c9e:       b902            cbnz    r2, 8000ca2 <stm32_gpio_set+0xa>
 8000ca0:       3110            adds    r1, #16
 8000ca2:       408b            lsls    r3, r1
 8000ca4:       6183            str     r3, [r0, #24]
 8000ca6:       2000            movs    r0, #0
 8000ca8:       4770            bx      lr

and the old one:

08000c98 <stm32_gpio_set>:
 8000c98:       2301            movs    r3, #1
 8000c9a:       f001 010f       and.w   r1, r1, #15
 8000c9e:       fa03 f101       lsl.w   r1, r3, r1
 8000ca2:       6943            ldr     r3, [r0, #20]
 8000ca4:       b10a            cbz     r2, 8000caa <stm32_gpio_set+0x12>
 8000ca6:       4319            orrs    r1, r3
 8000ca8:       e001            b.n     8000cae <stm32_gpio_set+0x16>
 8000caa:       ea23 0101       bic.w   r1, r3, r1
 8000cae:       6141            str     r1, [r0, #20]
 8000cb0:       2000            movs    r0, #0
 8000cb2:       4770            bx      lr

Change-Id: Ie5800d1c345016028d1b9a099f5d74cac35f592a
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
VitekST added a commit to VitekST/zephyr that referenced this pull request Jul 4, 2024
Instantiate Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA zephyrproject-rtos#1 and I3C - these are
peripherals responsible for audio playback and capture on the i.MX
RT685's HiFi 4 domain. Reconfigure IRQ allocation.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Jul 4, 2024
Add initialisation code for the HiFi 4 DSP domain of the mimxrt685_evk
board. Responsible for setting up signal sharing between Flexcomm zephyrproject-rtos#1 and
Flexcomm zephyrproject-rtos#3 peripherals both in the I2S mode (simultaneous audio
playback and capture).

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Jul 4, 2024
Instantiate, configure and enable Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA, I3C for
audio capture and playback on mimxrt685_evk's HiFi 4 DSP domain. Add
pinmux definitions for those.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Jul 26, 2024
Instantiate Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA zephyrproject-rtos#1 and I3C - these are
peripherals responsible for audio playback and capture on the i.MX
RT685's HiFi 4 domain. Reconfigure IRQ allocation.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Jul 26, 2024
Add initialisation code for the HiFi 4 DSP domain of the mimxrt685_evk
board. Responsible for setting up signal sharing between Flexcomm zephyrproject-rtos#1 and
Flexcomm zephyrproject-rtos#3 peripherals both in the I2S mode (simultaneous audio
playback and capture).

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Jul 26, 2024
Instantiate, configure and enable Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA, I3C for
audio capture and playback on mimxrt685_evk's HiFi 4 DSP domain. Add
pinmux definitions for those.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Aug 30, 2024
Instantiate Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA zephyrproject-rtos#1 and I3C - these are
peripherals responsible for audio playback and capture on the i.MX
RT685's HiFi 4 domain. Reconfigure IRQ allocation.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Aug 30, 2024
Add initialisation code for the HiFi 4 DSP domain of the mimxrt685_evk
board. Responsible for setting up signal sharing between Flexcomm zephyrproject-rtos#1 and
Flexcomm zephyrproject-rtos#3 peripherals both in the I2S mode (simultaneous audio
playback and capture).

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Aug 30, 2024
Instantiate, configure and enable Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA, I3C for
audio capture and playback on mimxrt685_evk's HiFi 4 DSP domain. Add
pinmux definitions for those.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Aug 30, 2024
Instantiate Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA zephyrproject-rtos#1 and I3C - these are
peripherals responsible for audio playback and capture on the i.MX
RT685's HiFi 4 domain. Reconfigure IRQ allocation.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Aug 30, 2024
Add initialisation code for the HiFi 4 DSP domain of the mimxrt685_evk
board. Responsible for setting up signal sharing between Flexcomm zephyrproject-rtos#1 and
Flexcomm zephyrproject-rtos#3 peripherals both in the I2S mode (simultaneous audio
playback and capture).

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
VitekST added a commit to VitekST/zephyr that referenced this pull request Aug 30, 2024
Instantiate, configure and enable Flexcomm zephyrproject-rtos#1, Flexcomm zephyrproject-rtos#3, DMA, I3C for
audio capture and playback on mimxrt685_evk's HiFi 4 DSP domain. Add
pinmux definitions for those.

Signed-off-by: Vit Stanicek <vit.stanicek@nxp.com>
swkim101 added a commit to swkim101/zephyr that referenced this pull request Oct 10, 2024
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>
swkim101 added a commit to swkim101/zephyr that referenced this pull request Oct 23, 2024
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
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
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
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>
dkalowsk pushed a commit that referenced this pull request Nov 6, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in #1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
andrewnyland referenced this pull request in onceLabs/zephyr Nov 6, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in #1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
mark-inderhees pushed a commit to mark-inderhees/zephyr that referenced this pull request Nov 7, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
ppryga-nordic pushed a commit to ppryga-nordic/zephyr that referenced this pull request Nov 20, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
stig-bjorlykke pushed a commit to stig-bjorlykke/zephyr that referenced this pull request Dec 11, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
(cherry picked from commit 3017425)
ilhanates pushed a commit to ilhanates/zephyr that referenced this pull request Dec 13, 2024
With introduction of Raw modes, nRF70 driver now advertises get_c
onfig OP, but doesn't implement all types.

This causes problems two-fold with checksum calculations:
  1. The "config" isn't uninitialized, so, every call returns differnet
     values. So, for UDP header checksum would be done and
     pkt->chksumdone would be set. But for IPv4 header checksum might be
     skipped.
  2. Even if we initialize to zero, then network stack gets all zeros
     and calculates checksum by itself rendering offload moot.

There is another problem in zephyrproject-rtos#1, as there is only single flag for pkt for
all checksum, nRF70 driver sees this and tells UMAC to skip checksum for
the entire packet. The design isn't coherent, and should be converted to
communicate per-type checksum status (some are filled by network stack
and some HW).

But as nRF70 support all checksum offloads, advertise all types for both
RX and TX.

Upstream PR #: 80882

Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
(cherry picked from commit 3017425)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants