> > Regardless, RTFS before making such statements.
> which one?
> i see you aren't disputing that the commit fixed security bugs for .26,
Correct, but irrelevant.
Bugs were added in 2.6.26-rc7.
kmalloc(0) is harmless.
Multiplication overflow on 64-bit can't happen (honestly, I'm not sure
about 32-bit, haven't checked personally).
Just, stating something, state full picture.
> you're only complaining about its applicability to .25.
Oh, wow! It's you who is complaining here, dammit!
> clearly, features not used on .25 are irrelevant,
PROC_PAGE_MONITOR is enabled in 2.6.25, so it's relevant. What feature
is irrelevant but relevant to thread?
> however the kmalloc(0) case is an interesting one as it ends up down a
> similar path to what the vmsplice exploit abused, save for the hardening
> of get_user_pages that was introduced due to the same. were cliph to
> withhold that bug for a little longer, you would be essentially arguing
> for not fixing an exploitable bug - not the right mindset i'm afraid.
Blame developers for bugs which could have happened. This is a solution!
> and let's not get started on the sillyness of using a userland address
> for ZERO_SIZE_PTR.
Given that a) kmalloc() will return ZERO_SIZE_PTR, b) get_user_pages()
will immediately return 0, let's not.
> another problem you haven't caught
When you've noticed this? Right after pagemap was added? After pagemap was
shipped in 2.6.25? After you've noticed pagemap fixes? After you realized
that some from all those pagemap fixes do not apply to 2.6.25 (crap!)?
> is that while get_user_pages brings in the userland buffer and even
> makes it writable, as soon as the mmap semaphore is dropped, the whole
> thing can disappear (munmap) or become read-only again (fork/mprotect)
> and thus whatever the whole exercise was supposed to prevent (sleeping
> on put_user?
Don't know what exact aspect of "sleeping on put_user" you mean.
> copy-on-write?) is still possible.
But, but, RTFS again.
Notice put_page() calls in pagemap_read(). Why they're there? Probably,
because get_user_pages() pins pages, so they won't dissapear from under
Regarding mprotect(): user will clear PROT_WRITE, and kernel will
put_user() to it. You know what will happen. Amazing hole.
> > > business as usual, i guess.
> > How old are you?
> judging from your post, probably at least 2-3 times your age. ;)
Yes, yes, but... How old are you?