aboutsummaryrefslogtreecommitdiff
path: root/packages/Python/lldbsuite/test/functionalities/signal/(developers-only)
diff options
context:
space:
mode:
authorJessica Clarke <jrtc27@FreeBSD.org>2026-01-27 21:44:39 +0000
committerJessica Clarke <jrtc27@FreeBSD.org>2026-01-27 21:44:39 +0000
commit331316b073505e4794754af1cd0c5ccc578a2bde (patch)
tree6409da394a3ab9426576a7952f2691579665eaed /packages/Python/lldbsuite/test/functionalities/signal/(developers-only)
parent8a9508563542d709b1a42a065e6e99e004a8b3fe (diff)
libc: Don't use uninitialised string for getnetbyaddr[_r](0) DNS lookupHEADmain
If net is all-zero, the loop to extract all leading non-zero octets will iterate zero times and leave nn with the value 4, which the following switch statement to initialise qbuf does not handle. As a result, _dns_getnetbyaddr will look up the PTR record for this uninitialised string, which will leak the pre-existing contents of that stack memory to the DNS resolver and, if remote and not otherwise protected, network. Note that _dns_getnetbyaddr is only used if nsswitch.conf is configured to enable the "dns" source for the "networks" database, which is not the default configuration in FreeBSD. For glibc this same bug, in code also derived from BIND's, was issued CVE-2026-0915. This commit adopts the same behaviour as glibc's fix, which is to regard a net of 0 as being for 0.0.0.0. Apparently NetBSD will return NS_UNAVAIL instead, which may or may not make more sense, but in general glibc compatibility tends to cause less friction when there's not a good reason to avoid it. Reviewed by: markj (secteam) Fixes: 1363f04ce1b8 ("get* rework and new bind code") MFC after: 1 day Security: Same bug as glibc's CVE-2026-0915
Diffstat (limited to 'packages/Python/lldbsuite/test/functionalities/signal/(developers-only)')
0 files changed, 0 insertions, 0 deletions