Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Dec 2017 18:15:17 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-wireless@FreeBSD.org
Subject:   [Bug 224141] possible Off-by-one bug in the Base64 decoding in the wpa supplicant
Message-ID:  <bug-224141-21060-YIDXHHKDe3@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-224141-21060@https.bugs.freebsd.org/bugzilla/>
References:  <bug-224141-21060@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224141

Timothy Brown <tbrown@freeshell.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tbrown@freeshell.org

--- Comment #1 from Timothy Brown <tbrown@freeshell.org> ---
Hi Ivan,

I was wondering if you've got a test case that shows this "off-by-one"?

As when I read the code, I do not believe there is an "off-by-one" error.
The base64_table:

static const unsigned char base64_table[65] =3D
        "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";

Is defined as size 65, yet contains 64 elements and the last trailing NULL.

So sizeof(base64_table) will return 65, yet the for loop is creating the=20
reverse base64 lookup in dtable, so we only want to do this for elements=20
in base64_table. Which is sizeof(base64_table) -1, or strlen(base64_table).

This is my understanding of the code and I am unable to encode/decode an er=
ror.
I would be interested to hear your thoughts.

Regards
Tim

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224141-21060-YIDXHHKDe3>