This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/21499] Uninitialised pointer in svcudp_reply()


https://sourceware.org/bugzilla/show_bug.cgi?id=21499

--- Comment #2 from Peter Linich <plinich at cse dot unsw.edu.au> ---
** Discernible pattern

I have only been able to reproduce and capture the network in a couple of
particular circumstances and in each case I observeved the following:

It occurred when amd was sending a response to an NFSv3 LOOKUP request.

Instead of sending a UDP datagram of 132 bytes, glibc sent a databgram of 8800
bytes.

The datagram appeared to consist of a LOOKUP reply (but I wasn't sure it was
the correct one) followed by 8668 NULs (i.e., '\0').

** Does amd do anything strange in regards to the order it calls functions?

Sorry. I can't answer that. I don't know what's normal for this sort of thing.

** How I isolated the problem

I will note that I downloaded both the source code of amd and of the latest
version of glibc and peppered the relevant bits of source code with printf()
and dlog() statements to narrow down where the problem was occurring.

svc_sendreply() encodes that data to send into a buffer but doesn't ensure that
this buffer is what it sends. I could see that the encoded data length was 132
bytes but that __sendmsg() returned saying it had sent 8800.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]