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.
Thanks,
Florian
More information about the Libc-help
mailing list