Skip to content

at86rf2xx: release framebuffer on recv with (len > 0) && (buf == NULL) [backport 2018.10]#10285

Merged
miri64 merged 3 commits intoRIOT-OS:2018.10-branchfrom
Josar:2018.10-branch
Feb 1, 2019
Merged

at86rf2xx: release framebuffer on recv with (len > 0) && (buf == NULL) [backport 2018.10]#10285
miri64 merged 3 commits intoRIOT-OS:2018.10-branchfrom
Josar:2018.10-branch

Conversation

@Josar
Copy link
Contributor

@Josar Josar commented Oct 29, 2018 •
edited
Loading

This PR sets the tranceiver in PLL_ON state to avoid corruption of the
data in the frame buffer and sets it back to the last state which the
transceiver had before changing into transmit mode after the data is
read out. This is done to avoid data corruption when _recv(...) is
called to retrieve the buffer size and frame buffer protection is released.

see
#9509
#9509 (comment)

@Josar
at86rf2xx: correct framebuffer release
428fc1c 
This PR sets the tranceiver in PLL_ON state to avoid corruption of the
data in the frame buffer and sets it back to the last state which the
 transceiver had before changing into transmit mode after the data is
read out. This is done to avoid data corruption when `_recv(...)` is
called to retrieve the buffer size and frame buffer protection is released.
@Josar Josar mentioned this pull request Oct 29, 2018
Merged
@bergzand bergzand mentioned this pull request Nov 16, 2018
Open
@Josar Josar changed the title at86rf2xx: correct framebuffer release [BACKPORT] at86rf2xx: correct framebuffer release Nov 16, 2018
@Josar Josar changed the title [BACKPORT] at86rf2xx: correct framebuffer release [BACKPORT] at86rf2xx: release framebuffer on recv with (len > 0) && (buf == NULL) Nov 16, 2018
@miri64 miri64 added the Process: release backport Integration Process: The PR is a release backport of a change previously provided to master label Nov 19, 2018
@miri64
Copy link
Member

miri64 commented Nov 19, 2018

@jia200x could this still go in? It somehow was missed during the release proceedures.

@miri64 miri64 added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: drivers Area: Device drivers CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Nov 19, 2018
@miri64
Copy link
Member

miri64 commented Nov 19, 2018

(best practice advice for future release managers: remove Process: needs backport ones backport is merged and have a look before a new RC, if there are still PRs that have the label).

@jia200x
Copy link
Member

jia200x commented Nov 20, 2018

oh yes, I missed this one :( I think we can still merge it though

@jia200x
Copy link
Member

jia200x commented Nov 20, 2018

(best practice advice for future release managers: remove Process: needs backport ones backport is merged and have a look before a new RC, if there are still PRs that have the label).

I will add this to the Release Manager draft

@aabadie
Copy link
Contributor

aabadie commented Dec 20, 2018

@jia200x, @miri64, this was finally not backported but is already available in the current master. Should we close ?

@jia200x
Copy link
Member

jia200x commented Jan 14, 2019

we can follow #10757 and backport this as well

@kaspar030
Copy link
Contributor

kaspar030 commented Jan 14, 2019

we can follow #10757 and backport this as well

This bug might lead to DoS, right?

@jia200x
Copy link
Member

jia200x commented Jan 14, 2019

This bug might lead to DoS, right?

Yes, I mean we should backport #10575 and merge this one as well, before tagging a sub release.

@jia200x
Copy link
Member

jia200x commented Jan 14, 2019

This bug might lead to DoS, right?

Ah, I see what you mean. Yes, if a layer on top is trying to drop a frame, it won't be released. Thus, there's potential DoS attacks.

@jia200x jia200x changed the title [BACKPORT] at86rf2xx: release framebuffer on recv with (len > 0) && (buf == NULL) at86rf2xx: release framebuffer on recv with (len > 0) && (buf == NULL) [backport 2018.10] Jan 29, 2019
@jia200x
Copy link
Member

jia200x commented Jan 29, 2019

The patch of this PR is the same as #9509. I couldn't test to release a packet here but did several ping tests with gnrc_networking and it works as expected.

jia200x
jia200x approved these changes Jan 29, 2019
View reviewed changes
Copy link
Member

@jia200x jia200x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. Travis is still with the same issue as in #10757 but all tests are run by Murdock anyway. So, Murdock green => GO

@miri64 miri64 added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Feb 1, 2019
@miri64 miri64 merged commit 8b99838 into RIOT-OS:2018.10-branch Feb 1, 2019
@jia200x jia200x mentioned this pull request Feb 1, 2019
Merged
@aabadie aabadie mentioned this pull request Feb 14, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jia200x jia200x jia200x approved these changes

Assignees

No one assigned

Labels

Area: drivers Area: Device drivers CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Process: release backport Integration Process: The PR is a release backport of a change previously provided to master Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@Josar @miri64 @jia200x @aabadie @kaspar030