Unexpected netlink response of size <number> on descriptor <number>

Florian Weimer fweimer@redhat.com
Fri Dec 20 09:32:00 GMT 2019

* Abhi Arora:

> Thank you for your answer. However, I want to understand this
> "descriptor race". You mean if any application is also using the
> netlink descriptor along with getaddrinfo() ?.
> I think what you mean is "If my application opens and closes a netlink
> socket descriptor (say it is 5) and even after closing it, it reuses
> that file descriptor for further operations. However, in the meantime,
> getaddrinfo() was called and it opens a netlink descriptor. Since,
> kernel returns lowest free file descriptor number, it may return 5.
> Now, two parts of an application are using the same file descriptor
> and hence, data send by application could be received by netlink
> descriptor opened by getaddrinfo() or vice-verse. Hence, I have
> received that error message  "Uxpected error 9 on netlink descriptor
> 6" ".

I think you got it pretty much correct.

The race looks typically like this:

  application closes descriptor 5
  glibc opens netlink descriptor 5
  application closes descriptor 5 (again)
  application opens some other file or socket, receives descriptor 5
  glibc tries to use descriptor 5

And at the last step, glibc detects that the descriptor is no longer a
netlink descriptor, and aborts the process.


More information about the Libc-help mailing list