[Webkit-unassigned] [Bug 210540] Fix an integer overflow in WebCrypto AES-CTR Mac implementation, which may detect a false loop

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=210540

--- Comment #4 from Tomoki Imai <tomoki.imai at sony.com> ---
(In reply to Jiewen Tan from comment #2)
> Comment on attachment 396514 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=396514&action=review
> 
> Good catch! Please address my comments below.

Thanks for your review!

> 
> > Source/WebCore/ChangeLog:6
> > +        (1 << counterLength) causes an integer overflow, and the undefined behavior.
> 
> Maybe you could reference here:
> https://en.cppreference.com/w/cpp/language/integer_literal.

Will do.

> 
> > Source/WebCore/crypto/mac/CryptoAlgorithmAES_CTRMac.cpp:48
> > +    if (counterLength < sizeof(size_t) * 8 && numberOfBlocks > ((size_t)1 << counterLength))
> 
> ((size_t)1 => 1ull

I used ((size_t) 1) rather than 1ull, because I thought using size_t type makes more sense than "unsigned long long".
- "counterLength < sizeof(size_t) * 8" checks whether size_t has enough size to store (1 << counterLength)
- In 32-bit environment, 1ull, which is 64-bit or larger, is a bit overkill, because counterLength < 31 in 32-bit environment.

How do you think about it?
Of course, 1ull should work fine both on 32-bit and 64-bit environment, so I'm fine to change it to 1ull.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200416/15593dbe/attachment.htm>