[vlc-devel] CVE-2019-13602 Heap Based Buffer Overflow Vulnerability

[Rémi Denis-Courmont]

Le tiistaina 16. heinäkuuta 2019, 20.26.57 EEST Francois Cartegnie a écrit :
> Le 16/07/2019 à 19:04, Rémi Denis-Courmont a écrit :
> > Le tiistaina 16. heinäkuuta 2019, 19.58.57 EEST Francois Cartegnie a écrit 
:
> >> Le 16/07/2019 à 18:37, Rémi Denis-Courmont a écrit :
> >>> Also smart asses will note that block_Alloc() always adds a margin of
> >>> 32-bytes at the end of the block buffer. So, in general, the worse
> >>> outcome of a read "overflow" of 4 bytes is leakage of memory content.
> >>> And
> >>> in this specific case, literally nothing will happen other than the code
> >>> being ugly.
> >> 
> >> So you're not the one to disagree to use block_t here ?
> > 
> > Your obvious trolling has been reported.
> > 
> > Also plonk.
> 
> You obviously know that block_t w/padding (for frames) will not stay there.

I have no clue what you are on about. I have no insights into the frame work, 
since somebody is doing it, and I do not see why the padding would be any more 
or less needed with frames than blocks.

> And really want to see a troll here ?

> Using "Also smart asses" means the "other" isn't because otherwise if he
> knew he wouldn't have pointed the issue.

AFAIK, the only smart ass that remembered block padding is me.

> I see disrespect (you would call it other way) to another dev.

Eh, remind me who wrote the original bug that led to a CVE, and then claimed 
that somebody else introduced a CVE-worthy bug?

And you call me disrespectful?

-- 
Rémi Denis-Courmont
http://www.remlab.net/