linux-kernel - Re: [RFC] globmatch() helper function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Dec 2008 10:37:04 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, andi@...stfloor.org
Cc:	tj@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] globmatch() helper function

Andi Kleen <andi@...stfloor.org> wrote:

> I'm uneasy with the unbounded recursion. Sure currently all the users
> are controlled in kernel source code and expect to put in sane patterns.
> But if someone ever adds a user controlled glob in some way it will be 
> trivial to crash/overwrite memory with the limited kernel stack.
> And with such a generalized function it's likely to be used more
> in the future.

I was just trying to keep the code small and elegant, and adding a
recursion counter or explicit stack would complicate it.

Further, even ignoring the stack space issue, allowing uncontrolled
patterns exposes a second, more insidious bug: due to the naive
backtracking, the run time is (potentially) exponential in the number
of *s present.  That could itself crash a non-preemptive kernel with a
watchdog enabled.

The simple fix is a very low limit on non-trailing * patterns (like
maybe 2), but then it's not generalized any more...

I'm willing to be persuaded, but the cost of making it robust against
pathological patterns is significant.  Is it really worth it?
And if it's not actually robust, why include a half-assed solution?

Does anyone else have an opinion on the matter?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/