The sysfs interface to seq_file continues to be rather fragile, as seen with some recent exploits[1]. Move the seq_file buffer to the vmap area (while retaining the accounting flag), since it has guard pages that will catch and stop linear overflows. This seems justified given that seq_file already uses kvmalloc(), that allocations are normally short lived, and that they are not normally performance critical.
[1] https://blog.grimm-co.com/2021/03/new-old-bugs-in-linux-kernel.html Signed-off-by: Kees Cook <keesc...@chromium.org> --- fs/seq_file.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/seq_file.c b/fs/seq_file.c index cb11a34fb871..ad78577d4c2c 100644 --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -32,7 +32,7 @@ static void seq_set_overflow(struct seq_file *m) static void *seq_buf_alloc(unsigned long size) { - return kvmalloc(size, GFP_KERNEL_ACCOUNT); + return __vmalloc(size, GFP_KERNEL_ACCOUNT); } /** @@ -130,7 +130,7 @@ static int traverse(struct seq_file *m, loff_t offset) Eoverflow: m->op->stop(m, p); - kvfree(m->buf); + vfree(m->buf); m->count = 0; m->buf = seq_buf_alloc(m->size <<= 1); return !m->buf ? -ENOMEM : -EAGAIN; @@ -237,7 +237,7 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter) goto Fill; // need a bigger buffer m->op->stop(m, p); - kvfree(m->buf); + vfree(m->buf); m->count = 0; m->buf = seq_buf_alloc(m->size <<= 1); if (!m->buf) @@ -349,7 +349,7 @@ EXPORT_SYMBOL(seq_lseek); int seq_release(struct inode *inode, struct file *file) { struct seq_file *m = file->private_data; - kvfree(m->buf); + vfree(m->buf); kmem_cache_free(seq_file_cache, m); return 0; } @@ -585,7 +585,7 @@ int single_open_size(struct file *file, int (*show)(struct seq_file *, void *), return -ENOMEM; ret = single_open(file, show, data); if (ret) { - kvfree(buf); + vfree(buf); return ret; } ((struct seq_file *)file->private_data)->buf = buf; -- 2.25.1
