[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 #8 from Jiewen Tan <jiewen_tan at apple.com> ---
(In reply to Tomoki Imai from comment #7)
> (In reply to Jiewen Tan from comment #5)
> > Comment on attachment 396514 [details]
> > patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=396514&action=review
> > 
> > >>> 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.
> > 
> > I was not aware we are still supporting 32 bit machines. Doing a C style
> > cast is not appropriate in WebKit, please change it to
> > static_cast<size_t>(1).
> 
> I changed it to static_cast<size_t>(1).
> I don't know about Mac implementation, but the other code seems to try to
> support 32-bit by using size_t.
> 

That was true 4 years ago for Apple ports but not now. Anyway, I think it is better to keep the consistency.

-- 
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/20200417/ecc9c57a/attachment.htm>