-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Closed
+2,094
−8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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>
This was referenced Sep 23, 2017
Closed
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.