Nginx security advisory (CVE-2013-2028)

Re:Nginx security advisory (CVE-2013-2028) by SoftwareMaven on Tuesday May 07, 2013 @10:21AM (#5668248)

Are these supposed to do different things on different architectures, or do they magically do the same thing without comparing C1 in the "else" case?

  #if (NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED)
  #define ngx_str3Ocmp(m, c0, c1, c2, c3).   \
       *(uint32_t *) m == ((c3 << 24) | (c2 << 16) | (c1 << 8) | c0)
  #else /* !(NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED) */
  #define ngx_str3Ocmp(m, c0, c1, c2, c3)    \
       m[0] == c0 && m[2] == c2 && m[3] == c3

[ Parent | on HN ]

Re:Nginx security advisory (CVE-2013-2028) by sltkr on Tuesday May 07, 2013 @10:37AM (#5668335)

If you look at where they are used, then it looks like these macros do not need to compare m[1] to c1 because whenever they are used it is already known that m[1] == 'O' (hence "str3O" in the name -- that's 3 and the letter O, not number zero).

I guess c1 is included in the first case because it's faster to compare the whole 32-bit word than mask out the known byte (and since c0, c1, c2 and c3 are compile time constants, the whole right-hand-side of the comparison will be optimized by constant folding anyway).

(It's ridiculous micro-optimization in my opinion, but at least it is correct, and it is limited to a single file.)

[ Parent | on HN ]

Re:Nginx security advisory (CVE-2013-2028) by paraboul on Tuesday May 07, 2013 @10:43AM (#5668366)

That's because c1 is always 'O' (in order to compare things like : 'POST', 'COPY', 'MOVE', etc.)

In the first case, comparing 2 integer (4x 8bit) is faster than omitting one byte.

That's is, using ngx_str3Ocmp with c1 != 'O' would be a usage error.

Edit: sltkr, sorry didn't see your reply.

[ Parent | on HN ]