svn commit: samba r23668 - in branches: SAMBA_3_0/source/lib
Volker.Lendecke at SerNet.DE
Sun Jul 1 06:14:30 GMT 2007
On Sat, Jun 30, 2007 at 05:39:49PM -0700, Jeremy Allison wrote:
> On Sun, Jul 01, 2007 at 02:04:36AM +0200, Michael Adam wrote:
> > I did not create a security hole (kept at the worst):
> > This block of code was just indented one additional level.
> > num_ucs2 = length/2, length being passed to the function.
> > So there is no danger of wrap here. - right?
> Where did length come from ? Please check length.
length is client-determined here, so definitely tainted (in
the perl sense). But still I don't see how this can wrap.
length and num_ucs2 are both unsigned, and right before the
malloc(num_ucs2+1) num_ucs2 was calculated as
num_ucs2=length/2. Maybe I'm not paranoid enough, but for
which values can this wrap?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20070701/b9ba82c2/attachment.bin
More information about the samba-technical