Page MenuHomeFreeBSD

ifconfig: Use strlcpy() instead of strncpy() for interface name copy
ClosedPublic

Authored by amy.vargas_netapp.com on Jan 16 2026, 9:53 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 27, 10:09 PM
Unknown Object (File)
Thu, Apr 23, 1:38 PM
Unknown Object (File)
Thu, Apr 23, 11:36 AM
Unknown Object (File)
Wed, Apr 8, 9:48 PM
Unknown Object (File)
Mar 23 2026, 1:15 AM
Unknown Object (File)
Mar 17 2026, 2:58 PM
Unknown Object (File)
Mar 15 2026, 10:09 AM
Unknown Object (File)
Mar 12 2026, 7:48 PM
Subscribers

Details

Summary

Replace strncpy() with strlcpy() when copying the interface name into ifr.ifr_name in link_status(). This ensures proper NUL-termination and addresses a potential issue flagged by Coverity static analysis.

No functional change intended.

Test Plan

Build completed successfully

Diff Detail

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

Event Timeline

This revision is now accepted and ready to land.Jan 17 2026, 9:54 AM
sbin/ifconfig/af_link.c
137

OK. This is a good change since ifr_name is an array of IF_NAMESIZE bytes (currently 16) that's documented to be null terminated:

/*
 * Length of interface external name, including terminating '\0'.
 * Note: this is the same size as a generic device's external name.
 */

Though I'm not entirely sure what a 'generic device' might be, since newbus names can be longer than 16 characters... But I guess that part doesn't matter. 'including the terminating '\0'. While one could pass in a mal-formed ifa structure, pointing to a device that's longer than allowed and this would silently truncate it, the worst that could happen is that the kernel can't find the device for the SIOCGHWADDDR call and the error would be signalled there.

tl;dr: Looks great!

The commit message says “no functional change intended” but there is one: strncpy() zero-fills the unused portion of the buffer, strlcpy() does not, so this leaves ifr partly uninitialized. It probably doesn't matter in this direction, but I don't see this addressed anywhere in the review.

In D54752#1296854, @des wrote:

The commit message says “no functional change intended” but there is one: strncpy() zero-fills the unused portion of the buffer, strlcpy() does not, so this leaves ifr partly uninitialized. It probably doesn't matter in this direction, but I don't see this addressed anywhere in the review.

The kernel shall alway be robust against userland's input. A proper NUL-terminated string or not, zero-filled the unused portion of the buffer or not, shall not make any differences.

So I think No functional change intended is proper in this case.