On Fri, Oct 23, 2015 at 09:19:34PM +0200, Stefan Sperling wrote:
> Now that this is committed, do you intend to audit the runes code as
> well? :-)
Hah, yeah that's the next logical step to do. Except you are faster
than me, then I would probably okay it. ;)
On Tue, Oct 06, 2015 at 12:08:42PM +0200, Tobias Stöckmann wrote:
> > On October 6, 2015 at 11:40 AM Stefan Sperling wrote:
> > What do you think about a similar treatment for locale/rune.c?
>
> I think you refer to _Read_RuneMagi function,
> which lacks the same input
On Tue, Oct 06, 2015 at 11:57:40PM +0200, Tobias Stoeckmann wrote:
> By the way, this is the second version with miod's feedback. Time to
> send it to tech@ now, too.
>
> Fixed one issue due to missing braces and less ntohl() calls, which
> makes the code easier to read.
ok with me
> Index:
By the way, this is the second version with miod's feedback. Time to
send it to tech@ now, too.
Fixed one issue due to missing braces and less ntohl() calls, which
makes the code easier to read.
Index: catopen.c
===
RCS file:
On Thu, Sep 03, 2015 at 11:01:59PM +0200, Tobias Stoeckmann wrote:
> Hi,
>
> our catopen implementation does not check the parsed message catalog,
> making it vulnerable to all sorts of out of boundary accesses.
This is interesting stuff, but I haven't found time to read through it yet.
What do
> On October 6, 2015 at 11:40 AM Stefan Sperling wrote:
> What do you think about a similar treatment for locale/rune.c?
I think you refer to _Read_RuneMagi function,
which lacks the same input validation.
Before supplying a patch for that one, I wanted to get some feedback
for
Hi,
our catopen implementation does not check the parsed message catalog,
making it vulnerable to all sorts of out of boundary accesses.
Take this minimalistic proof of concept file:
$ printf '\xff\x88\xff\x89\x01\x00\x00\x00' > poc.cat
If you are too lazy to write code to open it yourself,