Page MenuHomeFreeBSD

netlink: Zero-initialize mbuf messages
ClosedPublic

Authored by markj on Jan 17 2023, 2:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 22, 5:30 PM
Unknown Object (File)
Thu, Nov 14, 12:20 PM
Unknown Object (File)
Fri, Nov 8, 6:06 PM
Unknown Object (File)
Wed, Oct 30, 12:58 AM
Unknown Object (File)
Oct 25 2024, 10:00 PM
Unknown Object (File)
Oct 24 2024, 10:41 PM
Unknown Object (File)
Oct 24 2024, 4:30 PM
Unknown Object (File)
Sep 29 2024, 2:27 AM
Subscribers

Details

Summary

Some users of nlmsg_reserve_object() and nlmsg_reserve_data() are not
careful to fully initialize pad and reserved fields, allowing
uninitialized bytes to leak to userspace. For example, dump_nhgrp()
doesn't set nhm->resvd = 0.

Meanwhile, nlmsg_get_ns_buf() and nlmsg_get_ns_lbuf() zero-initialize
the buffer, so nlmsg_get_ns_mbuf() is inconsistent. Let's just make
them all behave the same here.

Reported by: KMSAN

Test Plan

netlink regression tests

Diff Detail

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

Event Timeline

markj requested review of this revision.Jan 17 2023, 2:08 PM
markj edited the test plan for this revision. (Show Details)

Thank you for working on that! It was on my list for quite some time. I was concerned a bit about performance & was thinking of measuring the different approaches. Anyway, let's make it safe first and work on improvements later.
Thank you again for addressing the security issue.

This revision is now accepted and ready to land.Jan 17 2023, 2:20 PM

Thank you for working on that! It was on my list for quite some time. I was concerned a bit about performance & was thinking of measuring the different approaches. Anyway, let's make it safe first and work on improvements later.

One other approach might be to instead make nlmsg_reserve_object() and nlmsg_reserve_data() zero the buffer area. I suspect the overhead of zeroing is pretty close to negligible in either case though?

This revision was automatically updated to reflect the committed changes.

Thank you for working on that! It was on my list for quite some time. I was concerned a bit about performance & was thinking of measuring the different approaches. Anyway, let's make it safe first and work on improvements later.

One other approach might be to instead make nlmsg_reserve_object() and nlmsg_reserve_data() zero the buffer area. I suspect the overhead of zeroing is pretty close to negligible in either case though?

Yep. Re overhead - it depends. Full-view dump is hundreds of megabytes, mainly consisting of the attributes (which don't require zeroing). Anyway, it shouldn't be a _huge_ difference and can be addressed later.