kernel/fs/seq_file.c, branch linux-5.10.y

seq_file: disallow extremely large seq buffer allocations

2021-07-20T14:05:59Z

commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream. There is no reasonable need for a buffer larger than this, and it avoids int overflow pitfalls. Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") Suggested-by: Al Viro Reported-by: Qualys Security Advisory Signed-off-by: Eric Sandeen Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fix return values of seq_read_iter()

2020-11-16T03:12:53Z

Unlike ->read(), ->read_iter() instances *must* return the amount of data they'd left in iterator. For ->read() returning less than it has actually copied is a QoI issue; read(fd, unmapped_page - 5, 8) is allowed to fill all 5 bytes of destination and return 4; it's not nice to caller, but POSIX allows pretty much anything in such situation, up to and including a SIGSEGV. generic_file_splice_read() uses pipe-backed iterator as destination; there a short copy comes from pipe being full, not from running into an un{mapped,writable} page in the middle of destination as we have for iovec-backed iterators read(2) uses. And there we rely upon the ->read_iter() reporting the actual amount it has left in destination. Conversion of a ->read() instance into ->read_iter() has to watch out for that. If you really need an "all or nothing" kind of behaviour somewhere, you need to do iov_iter_revert() to prune the partial copy. In case of seq_read_iter() we can handle short copy just fine; the data is in m->buf and next call will fetch it from there. Fixes: d4d50710a8b4 (seq_file: add seq_read_iter) Tested-by: Nathan Chancellor Signed-off-by: Al Viro

seq_file: add seq_read_iter

2020-11-06T18:05:18Z

iov_iter based variant for reading a seq_file. seq_read is reimplemented on top of the iter variant. Signed-off-by: Christoph Hellwig Tested-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59Z

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva

fs/seq_file.c: seq_read: Update pr_info_ratelimited

2020-06-05T02:06:25Z

Use a more common logging style. Add and use pr_fmt, coalesce the format string, align arguments, use better grammar. Signed-off-by: Joe Perches Signed-off-by: Andrew Morton Cc: Vasily Averin Link: http://lkml.kernel.org/r/96ff603230ca1bd60034c36519be3930c3a3a226.camel@perches.com Signed-off-by: Linus Torvalds

fs/seq_file.c: seq_read(): add info message about buggy .next functions

2020-04-10T22:36:22Z

Patch series "seq_file .next functions should increase position index". In Aug 2018 NeilBrown noticed commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") "Some ->next functions do not increment *pos when they return NULL... Note that such ->next functions are buggy and should be fixed. A simple demonstration is dd if=/proc/swaps bs=1000 skip=1 Choose any block size larger than the size of /proc/swaps. This will always show the whole last line of /proc/swaps" Described problem is still actual. If you make lseek into middle of last output line following read will output end of last line and whole last line once again. $ dd if=/proc/swaps bs=1 # usual output Filename Type Size Used Priority /dev/dm-0 partition 4194812 97536 -2 104+0 records in 104+0 records out 104 bytes copied $ dd if=/proc/swaps bs=40 skip=1 # last line was generated twice dd: /proc/swaps: cannot skip to specified offset v/dm-0 partition 4194812 97536 -2 /dev/dm-0 partition 4194812 97536 -2 3+1 records in 3+1 records out 131 bytes copied There are lot of other affected files, I've found 30+ including /proc/net/ip_tables_matches and /proc/sysvipc/* I've sent patches into maillists of affected subsystems already, this patch-set fixes the problem in files related to pstore, tracing, gcov, sysvipc and other subsystems processed via linux-kernel@ mailing list directly https://bugzilla.kernel.org/show_bug.cgi?id=206283 This patch (of 4): Add debug code to seq_read() to detect missed or out-of-tree incorrect .next seq_file functions. [akpm@linux-foundation.org: s/pr_info/pr_info_ratelimited/, per Qian Cai] https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin Signed-off-by: Andrew Morton Cc: NeilBrown Cc: Al Viro Cc: Steven Rostedt Cc: Davidlohr Bueso Cc: Ingo Molnar Cc: Manfred Spraul Cc: Peter Oberparleiter Cc: Waiman Long Link: http://lkml.kernel.org/r/244674e5-760c-86bd-d08a-047042881748@virtuozzo.com Link: http://lkml.kernel.org/r/7c24087c-e280-e580-5b0c-0cdaeb14cd18@virtuozzo.com Signed-off-by: Linus Torvalds

seq_file: remove m->version

2020-04-07T17:43:42Z

The process maps file was the only user of version (introduced back in 2005). Now that it uses ppos instead, we can remove it. Signed-off-by: Matthew Wilcox (Oracle) Signed-off-by: Alexey Dobriyan Signed-off-by: Andrew Morton Link: http://lkml.kernel.org/r/20200317193201.9924-4-adobriyan@gmail.com Signed-off-by: Linus Torvalds

seq_file: fix problem when seeking mid-record

2019-08-13T23:06:52Z

If you use lseek or similar (e.g. pread) to access a location in a seq_file file that is within a record, rather than at a record boundary, then the first read will return the remainder of the record, and the second read will return the whole of that same record (instead of the next record). When seeking to a record boundary, the next record is correctly returned. This bug was introduced by a recent patch (identified below). Before that patch, seq_read() would increment m->index when the last of the buffer was returned (m->count == 0). After that patch, we rely on ->next to increment m->index after filling the buffer - but there was one place where that didn't happen. Link: https://lkml.kernel.org/lkml/877e7xl029.fsf@notabene.neil.brown.name/ Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: NeilBrown Reported-by: Sergei Turchanov Tested-by: Sergei Turchanov Cc: Alexander Viro Cc: Markus Elfring Cc: [4.19+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

nfsd: escape high characters in binary data

2019-07-03T21:52:50Z

I'm exposing some information about NFS clients in pseudofiles. I expect to eventually have simple tools to help read those pseudofiles. But it's also helpful if the raw files are human-readable to the extent possible. It aids debugging and makes them usable on systems that don't have the latest nfs-utils. A minor challenge there is opaque client-generated protocol objects like state owners and client identifiers. Some clients generate those to include handy information in plain ascii. But they may also include arbitrary byte sequences. I think the simplest approach is to limit to isprint(c) && isascii(c) and escape everything else. That means you can just cat the file and get something that looks OK. Also, I'm trying to keep these files legal YAML, which requires them to UTF-8, and this is a simple way to guarantee that. Acked-by: Kees Cook Signed-off-by: J. Bruce Fields

fs: mark expected switch fall-throughs

2019-04-08T23:21:02Z

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: fs/affs/affs.h:124:38: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/configfs/dir.c:1692:11: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/configfs/dir.c:1694:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ceph/file.c:249:3: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext4/hash.c:233:15: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext4/hash.c:246:15: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext2/inode.c:1237:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext2/inode.c:1244:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext4/indirect.c:1182:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext4/indirect.c:1188:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext4/indirect.c:1432:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ext4/indirect.c:1440:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/f2fs/node.c:618:8: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/f2fs/node.c:620:8: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/btrfs/ref-verify.c:522:15: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/gfs2/bmap.c:711:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/gfs2/bmap.c:722:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/jffs2/fs.c:339:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/nfsd/nfs4proc.c:429:12: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ufs/util.h:62:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/ufs/util.h:43:6: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/fcntl.c:770:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/seq_file.c:319:10: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/libfs.c:148:11: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/libfs.c:150:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/signalfd.c:178:7: warning: this statement may fall through [-Wimplicit-fallthrough=] fs/locks.c:1473:16: warning: this statement may fall through [-Wimplicit-fallthrough=] Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Reviewed-by: Kees Cook Signed-off-by: Gustavo A. R. Silva