-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Michael,
On 7/5/16 11:31 AM, Michael Diener wrote:
> Alright, I did my homework this time and worked with a self
> compiled version of mod_jk (1.2.41). Still the same error is
> happening. I traced the buffer overflow down to line 291 in
> jk_connect.c (nb_connect):
>
> 280> do { 281> rc = connect(sd, (const struct sockaddr
> *)&addr->sa.sin, addr->salen); 282> } while (rc == -1 && errno
> == EINTR); 283> 284> if ((rc == -1) && (errno == EINPROGRESS ||
> errno == EALREADY) 285> && (timeout > 0)) { 286>
> fd_set wfdset; 287> struct timeval tv; 288> socklen_t
> rclen = (socklen_t)sizeof(rc); 289> 290> FD_ZERO(&wfdset);
> *291> FD_SET(sd, &wfdset);* 292> tv.tv_sec = timeout
> / 1000; 293> tv.tv_usec = (timeout % 1000) * 1000; 294>
> rc = select(sd + 1, NULL, &wfdset, NULL, &tv);
>
>
> From what I understand a buffer overflow would only happen for
> FD_SET if the fd_set gets over 1024 descriptors. I made sure that
> my ulimit for open files is set and applied large enough, so that's
> not it.
There's nothing magic about the ulimit. An fd_set should size
appropriately for your OS. On my Linux system, FD_SETSIZE happens to
be set to 1024. Reading through the byzantine labyrinth of includes,
it appears that FD_SET has zero boundary-checking, so it's therefore
possible that overflow will occur.
> I tried to switch FD_SET to poll and it seems to work now also for
> sd > 1024:
>
> struct pollfd pfd_read; pfd_read.fd = sd; pfd_read.events =
> POLLOUT; rc = poll(&pfd_read, 1, timeout);
>
> As C/C++ is not my preferred language and I understand the
> internals for mod_jk not well enough for a change like this, I have
> a few questions:
>
> 1. Is it normal/expected for nb_connect() to evaluate the IF in
> line 284 to TRUE? I wonder if this might be the real cause for my
> problems in the first place.
>
> 2. In line 305 of the original jk_connect.c there is a FD_ISSET
> inside an IF. Is there an equivalent operation for poll or is the
> whole IF unnecessary then?
IMHO poll() is superior to select() but unfortunately somewhat less
portable (and also requires a bit more maintenance). It means being
able to handle more than some arbitrary limit of fds (1024 in my case).
I'm unsure if the goal for tcnative is to get away from more
dependencies on APR, but presumably APR has a portable-poll() function
of some kind?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXfDAwAAoJEBzwKT+lPKRYT7YQAIPsBTAx+zk2SYVJHzP/86v4
6p7mmUDCcb/EAuyMsWkIqueYlDEGJ5syox4JnoQ987wFBzmrTpuLAnn2x3HcrzE6
ruNjxKtqnDhWwBkLHd8ZzlfiTTP+xRAiWlxb1kA+EHJxSaMeimJSBHJvzjP3sTG6
jJg8XJqz4IeGc3oSf0VdxPEFLDlpA8ixPffnfq2yZry+ux8Y3NuW3S9k1mORNavm
gdJs7fhEj1hzSGtb788LQwmXFH5HXC1mprFvnDQQs47wY72ELe4nk03AT1LNEGeE
dNLvREPRqG+fDglcbJH9UctfyOZZAu67a1sdy71SW2Coa1Od8TlidXACO2L/0NXK
dJMmf1i19wumwZPmTvZP+MXk9qp1OYFN4mG1hWIOA6A/8KfUcYi221tIYqAc8L1w
rm8W0Rf/QlyyZdWOeu1FG4XWmJEg2rf79YlD1sDj5VO7K2Po92rFlaDxaESoiFmb
qa+mDRFQVAYxti25jGuawnHLMdRcaa/j86buwVn9xSwI9Ij4UVxNv5tqWSPG6K9V
rZ4SG8dcoR8roGWAXtm5oLPtDutXvvm4VxFC3sbxzDiwZHzix6k/lbaIT13GG5aJ
3VGpNAqCnwsOeTMjoN5amuWnJJo8Hrb3Qw/Jr6AhYlofKvwizukmjBT0qXuhggpw
IxOdAPzXMS0ppcc9Nsbb
=YviT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
