Thanks, Claude.

That workaround macro also works.

diff -ruN dropbear-2019.78.orig/svr-main.c dropbear-2019.78/svr-main.c
--- dropbear-2019.78.orig/svr-main.c    2019-03-27 17:15:23.000000000 +0300
+++ dropbear-2019.78/svr-main.c 2019-11-13 19:40:36.688398257 +0300
@@ -143,7 +143,9 @@
        {
                dropbear_exit("No listening ports available.");
        }

+       /* fds bits shoud be initialized by zeroes before use */
+       DROPBEAR_FD_ZERO(&fds);
        for (i = 0; i < listensockcount; i++) {
                FD_SET(listensocks[i], &fds);
        }

On 29.11.2019 22:44, Claude Bing wrote:
You may want to see if DROPBEAR_FD_ZERO() is a more appropriate macro to
use in this instance (see dbutil.h::93).

Regards,

Claude Bing

On 11/29/19 2:02 PM, Timur R. Mustafin wrote:
Hi.

I started dropbear application on our e2k platform in specific
"protected mode". Particulary it cheks in runtime for use of
uninitialized variables. So it finds such case in file svr-main.c with
variable fds in main_noinetd(). Patch is very small:

diff -ruN dropbear-2019.78.orig/svr-main.c dropbear-2019.78/svr-main.c
--- dropbear-2019.78.orig/svr-main.c    2019-03-27 17:15:23.000000000 +0300
+++ dropbear-2019.78/svr-main.c 2019-11-13 19:40:36.688398257 +0300
@@ -143,7 +143,9 @@
        {
                dropbear_exit("No listening ports available.");
        }

+       /* Initialize fds by zeroes before use */
+       FD_ZERO(&fds);
        for (i = 0; i < listensockcount; i++) {
                FD_SET(listensocks[i], &fds);
        }


Reply via email to