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

networkd doesn't appear to handle netlink incoming buffer overruns properly #5398

Open
poettering opened this issue Feb 20, 2017 · 3 comments
Open

networkd doesn't appear to handle netlink incoming buffer overruns properly #5398

poettering opened this issue Feb 20, 2017 · 3 comments
Labels
bug 🐛 Programming errors, that need preferential fixing network sd-netlink

Comments

@poettering
Copy link
Member

see:

https://lists.freedesktop.org/archives/systemd-devel/2017-February/038313.html
@poettering poettering added this to the v233 milestone Feb 20, 2017
poettering added a commit to poettering/systemd that referenced this issue Feb 21, 2017
@poettering
sd-netlink: don't give up on netlink on ENOBUFS
7b0f473 
If our netlink input buffer overruns the kernel will send us ENOBUFS on
the next recvmsg(). Don't consider this a complete failure resulting in
closing of the netlink socket. Instead, simply continue (after debug
logging).

Of course, ideally we'd have a better strategy for this, and would have
a way to resync if this happens (as well as a scheme for cancelling all
ongoing asynchronous transactions), but for now let's at least not choke
fatally, and simply accept that we lost some messages and continue.

Note that if we lose messages when synchronously waiting for an
operation to complete, we'll still propagate the ENOBUFS up, to make the
individual transaction fail.

See: systemd#5398

(This bug does not properly fix the issue, hence we should leave the bug
open.)
@poettering
Copy link
Member Author

a partial fix is waiting in #5411.

@poettering poettering removed this from the v233 milestone Feb 21, 2017
poettering added a commit to poettering/systemd that referenced this issue Feb 21, 2017
@poettering
sd-netlink: don't give up on netlink on ENOBUFS
71994cf 
If our netlink input buffer overruns the kernel will send us ENOBUFS on
the next recvmsg(). Don't consider this a complete failure resulting in
closing of the netlink socket. Instead, simply continue (after debug
logging).

Of course, ideally we'd have a better strategy for this, and would have
a way to resync if this happens (as well as a scheme for cancelling all
ongoing asynchronous transactions), but for now let's at least not choke
fatally, and simply accept that we lost some messages and continue.

Note that if we lose messages when synchronously waiting for an
operation to complete, we'll still propagate the ENOBUFS up, to make the
individual transaction fail.

See: systemd#5398

(This bug does not properly fix the issue, hence we should leave the bug
open.)
@dvdhrm
Copy link
Contributor

dvdhrm commented Feb 22, 2017

The partial fix looks good.

Not sure anyone wants to implement netlink-resync in networkd, though.

@DemiMarie
Copy link

Not sure anyone wants to implement netlink-resync in networkd, though.

Is this really tricky?

@yuwata yuwata added the bug 🐛 Programming errors, that need preferential fixing label Jan 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug 🐛 Programming errors, that need preferential fixing network sd-netlink
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dvdhrm @poettering @DemiMarie @yuwata