- 12 Dec, 2022 4 commits
-
-
Iskren Chernev authored
I'm sunsetting my gmail account and moving to personal domain. Link: https://lkml.kernel.org/r/20221124114356.2187901-1-me@iskren.infoSigned-off-by:
Iskren Chernev <me@iskren.info> Acked-by:
Iskren Chernev <iskren.chernev@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Zhang Qilong authored
Commit ee62c6b2 ("eventfd: change int to __u64 in eventfd_signal()") forgot to change int to __u64 in the CONFIG_EVENTFD=n stub function. Link: https://lkml.kernel.org/r/20221124140154.104680-1-zhangqilong3@huawei.com Fixes: ee62c6b2 ("eventfd: change int to __u64 in eventfd_signal()") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Cc: Dylan Yudaken <dylany@fb.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Sha Zhengju <handai.szj@taobao.com> Signed-off-by:
-
Wang Weiyang authored
If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free priv. But priv is still in the chdev->file_list, then list traversal may cause UAF. This fixes the following smatch warning: drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list Link: https://lkml.kernel.org/r/20221123095147.52408-1-wangweiyang2@huawei.com Fixes: e8de3701 ("rapidio: add mport char device driver") Signed-off-by:
Wang Weiyang <wangweiyang2@huawei.com> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Dan Carpenter <error27@gmail.com> Cc: Jakob Koschel <jakobkoschel@gmail.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Xu Panda authored
The implementation of strscpy() is more robust and safer. That's now the recommended way to copy NUL terminated strings. Link: https://lkml.kernel.org/r/202211220853259244666@zte.com.cnSigned-off-by:
Xu Panda <xu.panda@zte.com.cn> Signed-off-by:
Yang Yang <yang.yang29@zte.com> Cc: Colin Ian King <colin.i.king@gmail.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: wuchi <wuchi.zero@gmail.com> Signed-off-by:
-
- 01 Dec, 2022 15 commits
-
-
Yury Norov authored
In current form, FORCE_NR_CPUS is visible to all users building their kernels, even not experts. It is also set in allmodconfig or allyesconfig, which is not a correct behavior. This patch fixes it. It also changes the parameter short description: removes implementation details and highlights the effect of the change. Link: https://lkml.kernel.org/r/20221116172451.274938-1-yury.norov@gmail.comSigned-off-by:
Yury Norov <yury.norov@gmail.com> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by:
Valentin Schneider <vschneid@redhat.com> Cc: Alexey Klimov <klimov.linux@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Eric Biggers <ebiggers@google.com> Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Sander Vanheule <sander@svanheule.net> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
-
Zheng Yejian authored
The integer overflow is descripted with following codes: > 317 static comp_t encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 } Currently comp_t is defined as type of '__u16', but the variable 'exp' is type of 'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535. Link: https://lkml.kernel.org/r/20210515140631.369106-3-zhengyejian1@huawei.comSigned-off-by:Zheng Yejian <zhengyejian1@huawei.com> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Zhang Jinhao <zhangjinhao2@huawei.com> Signed-off-by:
-
Zheng Yejian authored
Patch series "Fix encode_comp_t()". Type conversion in encode_comp_t() may look a bit problematic. This patch (of 2): See calculation of ac_{u,s}time in fill_ac(): > ac->ac_utime = encode_comp_t(nsec_to_AHZ(pacct->ac_utime)); > ac->ac_stime = encode_comp_t(nsec_to_AHZ(pacct->ac_stime)); Return value of nsec_to_AHZ() is always type of 'u64', but it is handled as type of 'unsigned long' in encode_comp_t, and accuracy loss would happen on 32-bit platform when 'unsigned long' value is 32-bit-width. So 'u64' value of encode_comp_t() may look better. Link: https://lkml.kernel.org/r/20210515140631.369106-1-zhengyejian1@huawei.com Link: https://lkml.kernel.org/r/20210515140631.369106-2-zhengyejian1@huawei.comSigned-off-by: -
Masahiro Yamada authored
With CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y, the following code fails to build: ---------------->8---------------- #include <linux/init.h> int foo(void) { return 0; } core_initcall(foo); ---------------->8---------------- Include <linux/build_bug.h> for static_assert() and <linux/stringify.h> for __stringify(). Link: https://lkml.kernel.org/r/20221113110802.3760705-1-masahiroy@kernel.orgSigned-off-by:Masahiro Yamada <masahiroy@kernel.org> Cc: Jiangshan Yi <yijiangshan@kylinos.cn> Cc: Kees Cook <keescook@chromium.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
-
Yang Yingliang authored
If device_register() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and list_del() is called to delete the port from rio_mports. Link: https://lkml.kernel.org/r/20221114152636.2939035-3-yangyingliang@huawei.com Fixes: 2aaf308b ("rapidio: rework device hierarchy and introduce mport class of devices") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Yang Yingliang authored
Patch series "rapidio: fix three possible memory leaks". This patchset fixes three name leaks in error handling. - patch #1 fixes two name leaks while rio_add_device() fails. - patch #2 fixes a name leak while rio_register_mport() fails. This patch (of 2): If rio_add_device() returns error, the name allocated by dev_set_name() need be freed. It should use put_device() to give up the reference in the error path, so that the name can be freed in kobject_cleanup(), and the 'rdev' can be freed in rio_release_dev(). Link: https://lkml.kernel.org/r/20221114152636.2939035-1-yangyingliang@huawei.com Link: https://lkml.kernel.org/r/20221114152636.2939035-2-yangyingliang@huawei.com Fixes: e8de3701 ("rapidio: add mport char device driver") Fixes: 1fa5ae85 ("driver core: get rid of struct device's bus_id string array") Signed-off-by:
-
Bo Liu authored
Fix the following W=1 kernel build warning(s): fs/fat/nfs.c:21: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst fs/fat/nfs.c:139: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Link: https://lkml.kernel.org/r/20221111075648.4005-1-liubo03@inspur.comSigned-off-by:
Bo Liu <liubo03@inspur.com> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Li Zetao authored
There is a memory leak reported by kmemleak: unreferenced object 0xffff88810cc65e60 (size 32): comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s) hex dump (first 32 bytes): 10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................ 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8170f73d>] __kmalloc+0x4d/0x150 [<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2] [<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2] [<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2] [<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2] [<ffffffff818e1fe2>] mount_bdev+0x312/0x400 [<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0 [<ffffffff818de82d>] vfs_get_tree+0x7d/0x230 [<ffffffff81957f92>] path_mount+0xd62/0x1760 [<ffffffff81958a5a>] do_mount+0xca/0xe0 [<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0 [<ffffffff82f26f15>] do_syscall_64+0x35/0x80 [<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 This call stack is related to two problems. Firstly, the ocfs2 super uses "replay_map" to trace online/offline slots, in order to recover offline slots during recovery and mount. But when ocfs2_truncate_log_init() returns an error in ocfs2_mount_volume(), the memory of "replay_map" will not be freed in error handling path. Secondly, the memory of "replay_map" will not be freed if d_make_root() returns an error in ocfs2_fill_super(). But the memory of "replay_map" will be freed normally when completing recovery and mount in ocfs2_complete_mount_recovery(). Fix the first problem by adding error handling path to free "replay_map" when ocfs2_truncate_log_init() fails. And fix the second problem by calling ocfs2_free_replay_slots(osb) in the error handling path "out_dismount". In addition, since ocfs2_free_replay_slots() is static, it is necessary to remove its static attribute and declare it in header file. Link: https://lkml.kernel.org/r/20221109074627.2303950-1-lizetao1@huawei.com Fixes: 9140db04 ("ocfs2: recover orphans in offline slots during recovery and mount") Signed-off-by:Li Zetao <lizetao1@huawei.com> Reviewed-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by:
-
Rong Tao authored
We need to set an initial value for offset to eliminate compilation warning. How to reproduce warning: $ make -C tools/testing/radix-tree radix-tree.c: In function `radix_tree_tag_clear': radix-tree.c:1046:17: warning: `offset' may be used uninitialized in this function [-Wmaybe-uninitialized] 1046 | node_tag_clear(root, parent, tag, offset); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Link: https://lkml.kernel.org/r/tencent_DF74099967595DCEA93CBDC28D062026180A@qq.comSigned-off-by:Rong Tao <rongtao@cestc.cn> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by:
-
Stephen Brennan authored
Though vmcoreinfo is intended to be small, at just one page, useful information is still added to it, so we risk running out of space. Currently there is no runtime check to see whether the vmcoreinfo buffer has been exhausted. Add a warning for this case. Currently, my static checking tool[1] indicates that a good upper bound for vmcoreinfo size is currently 3415 bytes, but the best time to add warnings is before the risk becomes too high. [1] https://github.com/brenns10/kernel_stuff/blob/master/vmcoreinfosize/vmcoreinfosize.py Link: https://lkml.kernel.org/r/20221027205008.312534-1-stephen.s.brennan@oracle.comSigned-off-by:
Stephen Brennan <stephen.s.brennan@oracle.com> Acked-by:
Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Liao Chang authored
These array allocator family are sometimes misused with the first and second arguments switched. Same issue with calloc, kvcalloc, kvmalloc_array etc. Bleat if sizeof is the first argument. Link: https://lore.kernel.org/lkml/5374345c-7973-6a3c-d559-73bf4ac15079@redhat.com/ Link: https://lkml.kernel.org/r/20221104070523.60296-1-liaochang1@huawei.comSigned-off-by:
Liao Chang <liaochang1@huawei.com> Acked-by:
Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Andy Whitcroft <apw@canonical.com> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Jason A. Donenfeld authored
On some platforms, `char` is unsigned, but this driver, for the most part, assumed it was signed. In other places, it uses `char` to mean an unsigned number, but only in cases when the values are small. And in still other places, `char` is used as a boolean. Put an end to this confusion by declaring explicit types, depending on the context. Link: https://lkml.kernel.org/r/20221019155541.3410813-1-Jason@zx2c4.comSigned-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Akinobu Mita authored
The simple attribute files do not accept a negative value since the commit 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()"), so we have to use a 64-bit value to write a negative value for a debugfs file created by debugfs_create_atomic_t(). This restores the previous behaviour by introducing DEFINE_DEBUGFS_ATTRIBUTE_SIGNED for a signed value. Link: https://lkml.kernel.org/r/20220919172418.45257-4-akinobu.mita@gmail.com Fixes: 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Reported-by:
Zhao Gongyi <zhaogongyi@huawei.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Oscar Salvador <osalvador@suse.de> Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Wei Yongjun <weiyongjun1@huawei.com> Cc: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by:
-
Akinobu Mita authored
The simple attribute files do not accept a negative value since the commit 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()"). This restores the previous behaviour by using newly introduced DEFINE_SIMPLE_ATTRIBUTE_SIGNED instead of DEFINE_SIMPLE_ATTRIBUTE. Link: https://lkml.kernel.org/r/20220919172418.45257-3-akinobu.mita@gmail.com Fixes: 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by:
-
Akinobu Mita authored
Patch series "fix error when writing negative value to simple attribute files". The simple attribute files do not accept a negative value since the commit 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()"), but some attribute files want to accept a negative value. This patch (of 3): The simple attribute files do not accept a negative value since the commit 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()"), so we have to use a 64-bit value to write a negative value. This adds DEFINE_SIMPLE_ATTRIBUTE_SIGNED for a signed value. Link: https://lkml.kernel.org/r/20220919172418.45257-1-akinobu.mita@gmail.com Link: https://lkml.kernel.org/r/20220919172418.45257-2-akinobu.mita@gmail.com Fixes: 488dac0c ("libfs: fix error cast of negative value in simple_attr_write()") Signed-off-by:
-
- 18 Nov, 2022 21 commits
-
-
Colin Ian King authored
Some of the more common spelling mistakes and typos that I've found while fixing up spelling mistakes in the kernel in the past year. Link: https://lkml.kernel.org/r/20221108110712.114611-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Uros Bizjak authored
Use try_cmpxchg instead of cmpxchg (*ptr, old, new) == old in task_numa_work. x86 CMPXCHG instruction returns success in ZF flag, so this change saves a compare after cmpxchg (and related move instruction in front of cmpxchg). No functional change intended. Link: https://lkml.kernel.org/r/20220822173956.82525-1-ubizjak@gmail.comSigned-off-by:
Uros Bizjak <ubizjak@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by:
-
YueHaibing authored
'size' is unsigned, it never less than zero. Link: https://lkml.kernel.org/r/20221105110611.28920-1-yuehaibing@huawei.com Fixes: 6c26df84 ("selftests: cgroup: return -errno from cg_read()/cg_write() on failure") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Yosry Ahmed <yosryahmed@google.com> Acked-by:
Roman Gushchin <roman.gushchin@linux.dev> Reviewed-by:
Kamalesh Babulal <kamalesh.babulal@oracle.com> Cc: David Rientjes <rientjes@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: zefan li <lizefan.x@bytedance.com> Signed-off-by:
-
Zhao Gongyi authored
Add local_config.h and local_config.mk to .gitignore to avoid accidentally checking it in. Link: https://lkml.kernel.org/r/20221103005754.205420-1-zhaogongyi@huawei.comSigned-off-by:
-
Baokun Li authored
When squashfs_read_table() returns an error or `sb->s_magic != SQUASHFS_MAGIC`, enters the error branch and calls msblk->thread_ops->destroy(msblk) to destroy msblk. However, msblk->thread_ops has not been initialized. Therefore, the following problem is triggered: ================================================================== BUG: KASAN: null-ptr-deref in squashfs_fill_super+0xe7a/0x13b0 Read of size 8 at addr 0000000000000008 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc3-next-20221031 #367 Call Trace: <TASK> dump_stack_lvl+0x73/0x9f print_report+0x743/0x759 kasan_report+0xc0/0x120 __asan_load8+0xd3/0x140 squashfs_fill_super+0xe7a/0x13b0 get_tree_bdev+0x27b/0x450 squashfs_get_tree+0x19/0x30 vfs_get_tree+0x49/0x150 path_mount+0xaae/0x1350 init_mount+0xad/0x100 do_mount_root+0xbc/0x1d0 mount_block_root+0x173/0x316 mount_root+0x223/0x236 prepare_namespace+0x1eb/0x237 kernel_init_freeable+0x528/0x576 kernel_init+0x29/0x250 ret_from_fork+0x1f/0x30 </TASK> ================================================================== To solve this issue, msblk->thread_ops is initialized immediately after msblk is assigned a value. Link: https://lkml.kernel.org/r/20221101073343.3961562-1-libaokun1@huawei.com Fixes: b0645770d3c7 ("squashfs: add the mount parameter theads=<single|multi|percpu>") Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Xiaoming Ni <nixiaoming@huawei.com> Reviewed-by:
Phillip Lougher <phillip@squashfs.org.uk> Cc: Yu Kuai <yukuai3@huawei.com> Cc: Zhang Yi <yi.zhang@huawei.com> Signed-off-by:
-
Shang XiaoJing authored
ocfs2_table_header should be free in ocfs2_stack_glue_init() if ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak. BUG: memory leak unreferenced object 0xffff88810eeb5800 (size 128): comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s) hex dump (first 32 bytes): c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@.............. 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0 [<00000000c04f70f7>] 0xffffffffa0050037 [<000000001bd12912>] do_one_initcall+0xdb/0x480 [<0000000064f766c9>] do_init_module+0x1cf/0x680 [<000000002ba52db0>] load_module+0x6441/0x6f20 [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0 [<00000000380c1f22>] do_syscall_64+0x3f/0x90 [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://lkml.kernel.org/r/41651ca1-432a-db34-eb97-d35744559de1@linux.alibaba.com Fixes: 3878f110 ("ocfs2: Move the hb_ctl_path sysctl into the stack glue.") Signed-off-by:Shang XiaoJing <shangxiaojing@huawei.com> Reviewed-by:
-
Xiongfeng Wang authored
Drop the following unused variables inherited from getdelays.c: 'aggr_len', 'len2', 'cmd_type', 'tid', 'containerset', 'containerpath' and 'sigset'. Link: https://lkml.kernel.org/r/20221031091557.192180-1-wangxiongfeng2@huawei.comSigned-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Cc: "Dr. Thomas Orgis" <thomas.orgis@uni-hamburg.de> Cc: Ismael Luceno <ismael@iodev.co.uk> Cc: Xiongfeng Wang <wangxiongfeng2@huawei.com> Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Tetsuo Handa authored
Like commit c4f135d6 ("workqueue: Wrap flush_workqueue() using a macro") says, flush_scheduled_work() is dangerous and will be forbidden. We are on the way for removing all flush_scheduled_work() callers from the kernel, and this patch is for removing flush_scheduled_work() call from tsi721 driver. Since "struct tsi721_device" is per a device struct, I assume that tsi721_remove() needs to wait for only two works associated with that device. Therefore, wait for only these works using flush_work(). Link: https://lkml.kernel.org/r/0e8a2023-7526-f03a-f520-efafbb0ef45c@I-love.SAKURA.ne.jpSigned-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Alexandre Bounine <alex.bou9@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Matt Porter <mporter@kernel.crashing.org> Signed-off-by:
-
Gaosheng Cui authored
Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20 left shift of 1 by 31 places cannot be represented in type 'int' <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Link: https://lkml.kernel.org/r/20221031113829.4183153-1-cuigaosheng1@huawei.com Fixes: c81f717c ("fbcon: Fix typo and bogus logic in get_default_font") Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by:
-
Xiaoming Ni authored
The maximum number of threads in the decompressor_multi.c file is fixed and cannot be adjusted according to user needs. Therefore, the mount parameter needs to be added to allow users to configure the number of threads as required. The upper limit is num_online_cpus() * 2. Link: https://lkml.kernel.org/r/20221019030930.130456-3-nixiaoming@huawei.comSigned-off-by:
-
Xiaoming Ni authored
Patch series 'squashfs: Add the mount parameter "threads="'. Currently, Squashfs supports multiple decompressor parallel modes. However, this mode can be configured only during kernel building and does not support flexible selection during runtime. In the current patch set, the mount parameter "threads=" is added to allow users to select the parallel decompressor mode and configure the number of decompressors when mounting a file system. "threads=<single|multi|percpu|1|2|3|...>" The upper limit is num_online_cpus() * 2. This patch (of 2): Squashfs supports three decompression concurrency modes: Single-thread mode: concurrent reads are blocked and the memory overhead is small. Multi-thread mode/percpu mode: reduces concurrent read blocking but increases memory overhead. The corresponding schema must be fixed at compile time. During mounting, the concurrent decompression mode cannot be adjusted based on file read blocking. The mount parameter theads=<single|multi|percpu> is added to select the concurrent decompression mode of a single SquashFS file system image. Link: https://lkml.kernel.org/r/20221019030930.130456-1-nixiaoming@huawei.com Link: https://lkml.kernel.org/r/20221019030930.130456-2-nixiaoming@huawei.comSigned-off-by:
-
XU pengfei authored
Remove unnecessary void* type casting. Link: https://lkml.kernel.org/r/20221026080517.3221-1-xupengfei@nfschina.comSigned-off-by:
XU pengfei <xupengfei@nfschina.com> Cc: Christian Brauner <brauner@kernel.org> Cc: David Disseldorp <ddiss@suse.de> Cc: "Eric W . Biederman" <ebiederm@xmission.com> Cc: Martin Wilck <mwilck@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: wuchi <wuchi.zero@gmail.com> Signed-off-by:
-
Ryusuke Konishi authored
If field s_log_block_size of superblock data is corrupted and too large, init_nilfs() and load_nilfs() still can trigger a shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn is set): shift exponent 38973 is too large for 32-bit type 'int' Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ubsan_epilogue+0xb/0x50 __ubsan_handle_shift_out_of_bounds.cold.12+0x17b/0x1f5 init_nilfs.cold.11+0x18/0x1d [nilfs2] nilfs_mount+0x9b5/0x12b0 [nilfs2] ... This fixes the issue by adding and using a new helper function for getting block size with sanity check. Link: https://lkml.kernel.org/r/20221027044306.42774-3-konishi.ryusuke@gmail.comSigned-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Tested-by:
-
Ryusuke Konishi authored
Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount time". The first patch fixes a bug reported by syzbot, and the second one fixes the remaining bug of the same kind. Although they are triggered by the same super block data anomaly, I divided it into the above two because the details of the issues and how to fix it are different. Both are required to eliminate the shift-out-of-bounds issues at mount time. This patch (of 2): If the block size exponent information written in an on-disk superblock is corrupted, nilfs_sb2_bad_offset helper function can trigger shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn is set): shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline] nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523 init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577 nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317 ... In addition, since nilfs_sb2_bad_offset() performs multiplication without considering the upper bound, the computation may overflow if the disk layout parameters are not normal. This fixes these issues by inserting preliminary sanity checks for those parameters and by converting the comparison from one involving multiplication and left bit-shifting to one using division and right bit-shifting. Link: https://lkml.kernel.org/r/20221027044306.42774-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20221027044306.42774-2-konishi.ryusuke@gmail.comSigned-off-by:
-
Stanislaw Gruszka authored
Do not report errors like below: ./scripts/checkpatch.pl -f drivers/net/wireless/ath/ath10k/wmi.h ERROR: Macros with complex values should be enclosed in parentheses +#define C2S(x) case x: return #x since many "case ..." macros are already used by some in-kernel drivers. Link: https://lkml.kernel.org/r/20221027134334.164301-1-stf_xl@wp.plSigned-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Acked-by:
-
Alexey Dobriyan authored
syscall(3) returns -1 and sets errno on error, unlike "syscall" instruction. Systems which have <= 32/64 CPUs are unaffected. Test won't bounce to all CPUs before completing if there are more of them. Link: https://lkml.kernel.org/r/Y1bUiT7VRXlXPQa1@p183 Fixes: 1f5bd054 ("proc: selftests: test /proc/uptime") Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Bjorn Helgaas authored
Remove unused __SLOW_DOWN_IO and SLOW_DOWN_IO definitions. Link: https://lkml.kernel.org/r/20221014001911.3342485-3-helgaas@kernel.orgSigned-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Gaosheng Cui authored
flush_register_stack() and invalidate_stacked_regs() have been removed since commit 0aeaf6b3 ("ia64/kprobes: Remove jprobe implementation"), so remove them. Link: https://lkml.kernel.org/r/20220914124707.1483471-1-cuigaosheng1@huawei.comSigned-off-by:
-
ye xingchen authored
Avoid typecasts that are needed for IS_ERR() and use IS_ERR_VALUE() instead. Link: https://lkml.kernel.org/r/20221020113004.400031-1-ye.xingchen@zte.com.cnSigned-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Signed-off-by:
Sergei Trofimovich <slyich@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
Most /proc files don't have length (in fstat sense). This leads to inefficiencies when reading such files with APIs commonly found in modern programming languages. They open file, then fstat descriptor, get st_size == 0 and either assume file is empty or start reading without knowing target size. cat(1) does OK because it uses large enough buffer by default. But naive programs copy-pasted from SO aren't: let mut f = std::fs::File::open("/proc/cmdline").unwrap(); let mut buf: Vec<u8> = Vec::new(); f.read_to_end(&mut buf).unwrap(); will result in openat(AT_FDCWD, "/proc/cmdline", O_RDONLY|O_CLOEXEC) = 3 statx(0, NULL, AT_STATX_SYNC_AS_STAT, STATX_ALL, NULL) = -1 EFAULT (Bad address) statx(3, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0444, stx_size=0, ...}) = 0 lseek(3, 0, SEEK_CUR) = 0 read(3, "BOOT_IMAGE=(hd3,gpt2)/vmlinuz-5.", 32) = 32 read(3, "19.6-100.fc35.x86_64 root=/dev/m", 32) = 32 read(3, "apper/fedora_localhost--live-roo"..., 64) = 64 read(3, "ocalhost--live-swap rd.lvm.lv=fe"..., 128) = 116 read(3, "", 12) open/stat is OK, lseek looks silly but there are 3 unnecessary reads because Rust starts with 32 bytes per Vec<u8> and grows from there. In case of /proc/cmdline, the length is known precisely. Make variables readonly while I'm at it. P.S.: I tried to scp /proc/cpuinfo today and got empty file but this is separate story. Link: https://lkml.kernel.org/r/YxoywlbM73JJN3r+@localhost.localdomainSigned-off-by: -
Bjorn Helgaas authored
The lkml.org, marc.info, spinics.net, etc archives are not quite as useful as lore.kernel.org because they use different styles, add advertising, and may disappear in the future. The lore archives are more consistent and more likely to stick around, so prefer https://lore.kernel.org URLs when they exist. [bhelgaas@google.com: only warn if we see "http" before the archive hostname] Link: https://lkml.kernel.org/r/20221114224315.GA939630@bhelgaas Link: https://lkml.kernel.org/r/20221019202843.40810-1-helgaas@kernel.orgSigned-off-by:
Peter Collingbourne <pcc@google.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> # build-tested Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
