Page MenuHomeFreeBSD

netlink: Make room for the unfinished message when growing the buffer
ClosedPublic

Authored by rcm on Fri, Oct 9, 5:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 17, 2:49 AM
Unknown Object (File)
Fri, Oct 16, 2:49 PM
Unknown Object (File)
Fri, Oct 16, 9:12 AM
Unknown Object (File)
Fri, Oct 16, 1:13 AM
Unknown Object (File)
Thu, Oct 15, 3:08 PM
Unknown Object (File)
Thu, Oct 15, 1:16 PM
Unknown Object (File)
Thu, Oct 15, 7:55 AM
Unknown Object (File)
Wed, Oct 14, 1:07 PM
Subscribers

Details

Summary

When a message outgrows the writer's buffer, _nlmsg_refill_buffer()
allocates a larger one and moves the unfinished message there. The new
buffer was sized for the data about to be added alone, so with enough of
the message already written the caller wrote past its end and left it
with datalen > buflen. A 20-byte message plus an attribute of 8176
bytes got a buffer of 8192 bytes for 8200 bytes of data, and reading it
panicked an INVARIANTS kernel in nl_soreceive().

Size the new buffer for both, and add a ktest for it.

Fixes: 7e5bf68495cc ("netlink: add netlink support")
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

Test Plan

ktest included

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

rcm requested review of this revision.Fri, Oct 9, 5:58 PM

Thank for the fix! It is good as is. But feel free to rethink the buffer allocation in general. Netlink initially used mbufs(9), and then I changed that. However, when doing that I didn't invest enough time into thinking on how to properly do that. There could be some bits of logic left that were relevant to mbufs. I mean that if this code was written from scratch and not as a refactor of the very first implementation of netlink it could have been different (better).

I am not 100% sure on the Fixes: tag. The bug could have been added when I moved netlink to own buffers instead of mbufs(9).

This revision is now accepted and ready to land.Sat, Oct 10, 2:48 AM