[vlc-devel] CVE-2019-13602 Heap Based Buffer Overflow Vulnerability
Rémi Denis-Courmont
remi at remlab.net
Tue Jul 16 19:46:19 CEST 2019
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/
More information about the vlc-devel
mailing list