Possible bit/byte conversion mistake in xfrm_state.c

Possible bit/byte conversion mistake in xfrm_state.c

[Marksteiner, Stefan]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

Hi folks,

I might have found a little bit/byte mistake in xfrm_state.c of 
iproute2-3.11.0 (and also lower versions).

In line 169 the algorithm length is set correctly ("alg->alg_key_len = 
len * 8;") in bits (as it is supposed by /usr/include/linux/xfrm.h, line 
101), but later in line 496 the same value is read and added to a length 
value in bytes ("len += alg.u.alg.alg_key_len;").

I'm not completetly sure, but I'm wondering if this might lead to errors 
for algorithms with big key sizes (>2048 bits)  for the key buffer 
("char buf[RTA_BUF_SIZE]" in line 274)  reserves only 2048 bytes of 
memory (RTA_BUF_SIZE=2048). So taking bits for bytes, the following 
memcopy operation may overwrite adjacent memory areas.

Can somebody verify if this is in fact an issue? Maybe I'm reading this 
whole stuff wrong.

Cheers,

Stefan


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4282 bytes --]

Re: Possible bit/byte conversion mistake in xfrm_state.c

[Fan Du]

Please wrap the line in shorter length ;)

On 2013年11月22日 22:54, Marksteiner, Stefan wrote:
> Hi folks,
>
> I might have found a little bit/byte mistake in xfrm_state.c of iproute2-3.11.0 (and also lower versions).
>
> In line 169 the algorithm length is set correctly ("alg->alg_key_len = len * 8;") in bits (as it is supposed by /usr/include/linux/xfrm.h, line 101), but later in line 496 the same value is read and added to a length value in bytes ("len += alg.u.alg.alg_key_len;").
>
> I'm not completetly sure, but I'm wondering if this might lead to errors for algorithms with big key sizes (>2048 bits) for the key buffer ("char buf[RTA_BUF_SIZE]" in line 274) reserves only 2048 bytes of memory (RTA_BUF_SIZE=2048). So taking bits for bytes, the following memcopy operation may overwrite adjacent memory areas.
>
> Can somebody verify if this is in fact an issue? Maybe I'm reading this whole stuff wrong.

You are totally right about this bit/byte mistake here.

Normally the aes key len is 128bits, and 160bits for sha1, and
the key buf  defined here is XFRM_ALGO_KEY_BUF_SIZE 512 bytes,
so there are stale data append after each key content, although
is not used by key interface anyway, which means the IPsec
communication goes well after all.

-- 
浮沉随浪只记今朝笑

--fan fan