Fix packetbuffer handling in UDPEndPointImplOpenThread. #18851
Merged
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
pullapprove
bot
requested review from
anush-apple,
arkq,
Byungjoo-Lee,
carol-apple,
chrisdecenzo,
chshu,
chulspro,
Damian-Nordic,
dhrishi,
electrocucaracha,
erjiaqing,
franck-apple,
gjc13,
hawk248,
harsha-rajendran,
isiu-apple,
jelderton,
jmartinez-silabs,
jtung-apple,
kghost,
kpschoedel,
lazarkov,
LuDuda,
mlepage-google,
msandstedt,
rgoliver,
robszewczyk and
sagar-apple
pullapprove
bot
requested review from
kpschoedel,
lazarkov,
LuDuda,
mlepage-google,
msandstedt,
rgoliver,
robszewczyk,
sagar-apple,
saurabhst,
selissia,
tecimovic,
tehampson,
turon,
vijs,
vivien-apple,
wbschiller,
woody-apple,
xylophone21,
yufengwangca and
yunhanw-google
What the code was doing was: 1. Allocate a buffer of size msgLen. 2. Copy sizeof(IPPacketInfo) + msgLen bytes into it. This is a buffer overrun if the packetbuffer was not over-allocated. 3. memmove the contents of the buffer over by sizeof(IPPacketInfo), point Start() at the location the data was moved to. This would fail if the buffer was not even more over-allocated. 4. Read the memory from ((Start() - sizeof(IPPacketInfo) & ~3) (which might _under-run_ the buffer depending on how its allocation is aligned in memory), and which anyway conceptually represents garbage data that the packetbuffer code is well withiin its rights to have overwritten and treat that memory as an IPPacketInfo. 5. Advance Start() by sizeof(IPPacketInfo) to point to the actual data. What the new code does is: 1. Allocate a buffer with msgLen data space and enough reserved space that we can place an aligned IPPacketInfo in the reserved space. 2. Copy the incoming data into the data space. 3. Fill in an IPPacketInfo in the reserved space. 4. Later read the IPPacketInfo from the reserved space.
bzbarsky-apple
force-pushed
the
fix-openthread-endpoint-buffers
branch
from
867e0dd
to
cefeefd
Compare
|
PR #18851: Size comparison from eb7628f to cefeefd Increases (3 builds for efr32)
Full report (37 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, telink)
|
jepenven-silabs
approved these changes
May 26, 2022
andy31415
approved these changes
May 26, 2022
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.
What the code was doing was:
if the packetbuffer was not over-allocated.
Start() at the location the data was moved to. This would fail if the buffer
was not even more over-allocated.
under-run the buffer depending on how its allocation is aligned in memory),
and which anyway conceptually represents garbage data that the packetbuffer
code is well withiin its rights to have overwritten and treat that memory as
an IPPacketInfo.
What the new code does is:
can place an aligned IPPacketInfo in the reserved space.
Problem
See above.
In particular, if allocating packetbuffers in RAM, things would fail here in various ways.
Change overview
See above.
Testing
@doru91 was going to test this.