The POSIX spec for sockaddr_in says that implementations are allowed to have implementation-dependent extensions controlled by extra fields in the struct, and that the way to ensure these are not accidentally activated is to zero out the whole data structure. We have several places in our codebase where we don't zero-init sockaddr_in structs and so (at least in theory) might run into this. Coverity spotted the ones in the net code (CID 1005338); the others in this series I found by looking at all uses of sockaddr_in. (The gdbstub patch changes also a sockaddr_un use, for symmetry.)
Thanks to Eric for the analysis of what the spec says and why Coverity is correct here. thanks -- PMM Peter Maydell (4): net: Zero sockaddr_in in parse_host_port() gdbstub: Zero-initialize sockaddr structs tests/qtest/ipmi-bt-test: Zero-initialize sockaddr struct tests/tcg/multiarch/linux-test: Zero-initialize sockaddr structs gdbstub.c | 4 ++-- net/net.c | 2 ++ tests/qtest/ipmi-bt-test.c | 2 +- tests/tcg/multiarch/linux-test.c | 4 ++-- 4 files changed, 7 insertions(+), 5 deletions(-) -- 2.20.1
