linux-kernel - potential regression in ext[34] call to __page

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-next>] [day] [month] [year] [list]

Date:	Tue, 28 Oct 2008 20:11:48 -0400
From:	"Mike Snitzer" <snitzer@...il.com>
To:	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc:	"Nick Piggin" <npiggin@...e.de>, "Kirill Korotaev" <dev@...nvz.org>
Subject: potential regression in ext[34] call to __page_symlink()?

The gfp_mask that is passed to __page_symlink() is being completely
dropped on the floor.  Historically this mask was at least used by
ext3 and ext4 to avoid recursing back into the FS from within a
journal transaction; Kirill fixed that issue with this commit:
0adb25d2e71ab047423d6fc63d5d184590d0a66f

I'm quite naive when it comes to Nick's relatively new (>= 2.6.24) AOP
pagecache_write_{begin,end} code that motivated __page_symlink to
change with this commit:
afddba49d18f346e5cc2938b6ed7c512db18ca68

Nick's change clearly did away with using the explicitly passed
gfp_mask in __page_symlink().
So at a minimum it would seem __page_symlink() now has an unused
parameter that should be removed.

But a more serious concern would be: have ext[34]_symlink() regressed
to being susceptible to the bug that Kirill fixed some time ago?

Please advise, thanks.
Mike
--
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/