mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2026-09-22 09:34:56 +02:00
2eed77fdcb0cc48e8eccb2bcd4b7f2c6d650e84c
1463892
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Tetsuo Handa
|
2eed77fdcb |
kcov: fix data corruption and race conditions on PREEMPT_RT
syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the
temporary storage used for saving/restoring remote KCOV state is currently
allocated as the per-CPU area.
On PREEMPT_RT kernels, softirq handlers run as preemptible task threads
(e.g., ksoftirqd). If a softirq context preempts a task running a remote
KCOV session, it safely saves the task's state into the per-CPU area.
However, if that softirq thread is subsequently preempted by a higher-
priority softirq thread on the same CPU, the second softirq will overwrite
the same per-CPU area, permanently destroying the original task's KCOV
state.
Fix this data corruption by moving the temporary storage from the per-CPU
area to the per-thread area. Since each softirq thread now owns its own
task context, nested softirq preemption no longer causes data overwrites.
Note that while the temporary storage is now on a per-thread basis, the
per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that
kcov_remote_start() and kcov_remote_stop() operate atomically without
racing against asynchronous interrupts that manipulate the current task's
KCOV state.
It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init()
has already called panic() before returning NULL, for there will be no
OOM-killable userspace processes when __init function of built-in module
runs. But this patch also fixes crashing the kernel when vmalloc_node()
in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL
but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in
(1) doing vmalloc() in kcov_remote_start() despite !in_task() context
(2) out-of-array-bounds access if (1) succeeded but
kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE
(3) always leak memory allocated by (1), eventually killing all
OOM-killable userspace processes
problems.
Link: https://lore.kernel.org/43552d09-2ce2-4b19-b0d3-a2d1ab952145@I-love.SAKURA.ne.jp
Reported-by: syzbot+3f51ad7ac3ae57a6fdcc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc
Reported-by: syzbot+47cf95ca1f9dcca872c8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=47cf95ca1f9dcca872c8
Reported-by: syzbot+8a173e13208949931dc7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8a173e13208949931dc7
Reported-by: syzbot+90984d3713722683112e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=90984d3713722683112e
Analyzed-by: AI Mode in Google Search (no mail address)
Fixes:
|
||
 Ian Bridges
|
0cdc7dde00 |
ocfs2: fix missing metadata reservation for large xattrs
[BUG]
lsetxattr() panics the kernel when setting a large xattr value on a
fragmented filesystem where the file already has an external xattr
block.
[CAUSE]
ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new
xattr value's extent tree when the file already has an external xattr
block. The not_found path leaves meta_add at zero, so meta_ac is NULL
when ocfs2_xattr_extend_allocation() runs.
A new value root has room for a single extent record. On a fragmented
filesystem, the allocator cannot satisfy the xattr value in one
contiguous run, so each non-contiguous run requires its own extent
record. When the value root's extent list is full and meta_ac is NULL,
ocfs2_add_clusters_in_btree() returns RESTART_META, and
ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META).
[FIX]
The case where no xattr block exists yet already calls
ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree
metadata. Add the same reservation to the case where an xattr block
already exists, making the two cases consistent.
Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is
returned despite the reservation, the error propagates to userspace
instead of panicking the kernel.
Link: https://lore.kernel.org/amLwn3i9tET8yhG7@dev
Fixes:
|
||
 Randy Dunlap
|
2c5a2a6afe |
stacktrace: header: repair kernel-doc comments
- use the "typedef" keyword when describing a typedef - add a Returns: section to prevent these kernel-doc warnings: Warning: include/linux/stacktrace.h:20 function parameter 'stack_trace_consume_fn' not described in 'bool' Warning: include/linux/stacktrace.h:20 expecting prototype for stack_trace_consume_fn(). Prototype was for bool() instead Warning: include/linux/stacktrace.h:58 No description found for return value of 'arch_stack_walk_reliable' Link: https://lore.kernel.org/20260723161831.138237-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Marc Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Randy Dunlap
|
eb14721d50 |
llist: use correct function parameter name
Correct the function parameter name to avoid kernel-doc warnings: Warning: ./include/linux/llist.h:71 function parameter 'list' not described in 'init_llist_head' Warning: ./include/linux/llist.h:71 Excess function parameter 'head' description in 'init_llist_head' Link: https://lore.kernel.org/20260723165113.225098-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Bradley Morgan
|
1f58a5335c |
taskstats: fix cpumask parsing cutting off the last character
parse() hands nla_strscpy() len as dstsize, and nla_strscpy() copies at
most dstsize - 1 bytes. When the attr payload comes in without a trailing
NUL, srclen == len >= dstsize and the last character of the cpumask string
gets cut off. Register "0-15" and you are silently listening on "0-1",
exit data for the rest never shows up.
The bug only bites when the sender doesn't NUL terminate the payload;
senders that include the NUL were always fine (srclen gets decremented for
the trailing NUL, so srclen < dstsize). Thats probably why this survived
20 years. And the policy is NLA_STRING, not NLA_NUL_STRING, so a payload
without the trailing NUL is legit input here.
Skip the kmalloc/nla_strscpy dance entirely and use nla_strdup(), which
already allocates srclen + 1 and terminates. The nla_len() bounds checks
stay as they were.
Link: https://lore.kernel.org/EC49FE41-7F5F-41E0-A07A-ABEB8ECA514D@grrlz.net
Fixes:
|
||
 Vincent Mailhol
|
dbf0633e42 |
lib/ucs2_string.c: fix indentation
checkpatch.pl reports a total of 18 incorrect use of spaces instead of tabulations in lib/ucs2_string.c. Apply ./scripts/checkpatch.pl --fix-inplace lib/ucs2_string.c to fix them all. Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-2-9ea94e32a358@kernel.org Signed-off-by: Vincent Mailhol <mailhol@kernel.org> Cc: Kees Cook <kees@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Vincent Mailhol
|
cec0d03fe7 |
lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()
Patch series "lib/ucs2_string.c: fix out-of-bounds read in
ucs2_strnlen()", v2.
This series fixes an off-by-one out-of-bounds read in ucs2_strnlen().
The first patch is the real fix, the second patch comes as a bonus and
fixes the code indentation.
This patch (of 2):
ucs2_strnlen() checks the current character before checking whether the
caller-provided maximum length has been reached. If the input is not
NUL-terminated within that bound, the loop can read one ucs2_char_t past
the limit.
Test the length before dereferencing to prevent an off-by-one
out-of-bounds read.
Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-0-9ea94e32a358@kernel.org
Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-1-9ea94e32a358@kernel.org
Fixes:
|
||
|
Randy Dunlap
|
7f96e4a781 |
rbtree: fixup kernel-doc names
Use the correct function parameter name in rb_next_match(). Use the struct keyword when describing struct latch_tree_ops. Prevents the following kernel-doc warnings: Warning: ./include/linux/rbtree.h:510 function parameter 'node' not described in 'rb_next_match' Warning: ./include/linux/rbtree.h:510 Excess function parameter 'tree' description in 'rb_next_match' Warning: ./include/linux/rbtree_latch.h:63 cannot understand function prototype: 'struct latch_tree_ops' Link: https://lore.kernel.org/20260722050759.3892887-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Joseph Qi
|
12c2ab42db |
ocfs2: cluster: fix o2hb_dependent_users leak on pin failure
In o2hb_region_inc_user(), o2hb_dependent_users is incremented
unconditionally before calling o2hb_region_pin(). If the pin fails, the
counter is never decremented and any partially-pinned regions are never
unpinned, since the caller does not call o2hb_region_dec_user() on error.
The leaked counter causes subsequent o2hb_region_inc_user() calls to skip
pinning entirely (the > 1 check), leaving heartbeat regions unprotected.
Fix by rolling back on failure: call o2hb_region_unpin(NULL) to release
any partially-pinned regions and decrement o2hb_dependent_users to restore
the pre-increment state.
Link: https://lore.kernel.org/20260722124933.430554-4-joseph.qi@linux.alibaba.com
Fixes:
|
||
|
Joseph Qi
|
cd789996db |
ocfs2: cluster: avoid lock order inversion in o2hb_region_pin() from drop_item
o2hb_heartbeat_group_drop_item() is called from configfs rmdir with the
parent directory's inode_lock held. It calls o2hb_region_pin() ->
o2nm_depend_item() -> configfs_depend_item(), which acquires the configfs
root inode_lock. This creates a parent -> root inode_lock nesting that
could deadlock against paths taking root -> parent (e.g. subsystem
unregistration).
Fix this by using configfs_depend_item_unlocked() when o2hb_region_pin()
is called from a configfs callback context. This variant skips the root
inode_lock when caller and target are in the same subsystem, which is safe
because VFS already holds a lock preventing unregistration.
Add o2nm_depend_item_unlocked() wrapper and a from_callback parameter to
o2hb_region_pin() to select the appropriate variant.
Link: https://lore.kernel.org/20260722124933.430554-3-joseph.qi@linux.alibaba.com
Fixes:
|
||
|
Joseph Qi
|
af09df89db |
ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin()
Patch series "ocfs2: cluster: o2hb_region_pin() fixes", v2. This series fixes three related issues in o2hb_region_pin(), all are from the original implementation in commit: |
||
 Dmitry Antipov
|
82ea9d4fc0 |
ocfs2: always run deallocs on copy-on-write completion
Local fuzzing of 6.12.94 has found the following memory leak
caused by doing 'copy_file_range()' within the same filesystem:
unreferenced object 0xffff88812192c980 (size 32):
comm "syz.0.49", pid 12095, jiffies 4294964143
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 ................
c0 c5 92 21 81 88 ff ff 00 02 00 00 00 06 00 00 ...!............
backtrace (crc 7068d63f):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
ocfs2_find_per_slot_free_list fs/ocfs2/alloc.c:6618 [inline]
ocfs2_cache_block_dealloc+0x155/0x4b0 fs/ocfs2/alloc.c:6786
ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline]
ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613
ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline]
__ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985
ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237
ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825
ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138
ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098
ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline]
ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline]
ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349
ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline]
ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470
ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline]
ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451
iter_file_splice_write+0x890/0xf60 fs/splice.c:743
do_splice_from fs/splice.c:944 [inline]
direct_splice_actor+0x232/0x480 fs/splice.c:1167
splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111
do_splice_direct_actor fs/splice.c:1210 [inline]
do_splice_direct+0x10f/0x1c0 fs/splice.c:1236
do_sendfile+0x430/0xbf0 fs/read_write.c:1388
unreferenced object 0xffff88812192c5c0 (size 32):
comm "syz.0.49", pid 12095, jiffies 4294964143
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
29 70 00 00 00 00 00 00 19 00 00 00 00 00 00 00 )p..............
backtrace (crc afec850f):
kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]
slab_post_alloc_hook mm/slub.c:4152 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358
kmalloc_noprof include/linux/slab.h:878 [inline]
kzalloc_noprof include/linux/slab.h:1014 [inline]
ocfs2_cache_block_dealloc+0x25c/0x4b0 fs/ocfs2/alloc.c:6793
ocfs2_cache_extent_block_free fs/ocfs2/alloc.c:6819 [inline]
ocfs2_unlink_path+0x286/0x450 fs/ocfs2/alloc.c:2613
ocfs2_rotate_subtree_left fs/ocfs2/alloc.c:2779 [inline]
__ocfs2_rotate_tree_left+0x1f6f/0x2da0 fs/ocfs2/alloc.c:2985
ocfs2_rotate_tree_left+0x283/0xe00 fs/ocfs2/alloc.c:3237
ocfs2_try_to_merge_extent+0xf56/0x1a20 fs/ocfs2/alloc.c:3825
ocfs2_split_extent+0x15f4/0x2940 fs/ocfs2/alloc.c:5138
ocfs2_clear_ext_refcount+0x2f6/0x550 fs/ocfs2/refcounttree.c:3098
ocfs2_replace_clusters fs/ocfs2/refcounttree.c:3131 [inline]
ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3255 [inline]
ocfs2_replace_cow+0x991/0x1660 fs/ocfs2/refcounttree.c:3349
ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3427 [inline]
ocfs2_refcount_cow+0x5e1/0x9f0 fs/ocfs2/refcounttree.c:3470
ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline]
ocfs2_file_write_iter+0xbda/0x1880 fs/ocfs2/file.c:2451
iter_file_splice_write+0x890/0xf60 fs/splice.c:743
do_splice_from fs/splice.c:944 [inline]
direct_splice_actor+0x232/0x480 fs/splice.c:1167
splice_direct_to_actor+0x4b4/0xb60 fs/splice.c:1111
do_splice_direct_actor fs/splice.c:1210 [inline]
do_splice_direct+0x10f/0x1c0 fs/splice.c:1236
do_sendfile+0x430/0xbf0 fs/read_write.c:1388
This happens when 'ocfs2_cache_block_dealloc()' called from
'ocfs2_cache_extent_block_free()' uses the suballocator to
schedule extent removal, so 'ocfs2_run_deallocs()' should
be run unconditionally to complete the removal with
'ocfs2_free_cached_blocks()'. An extra semi-automated static
analysis [1] suspects that the same scenario looks possible in
'ocfs2_attach_refcount_tree()' and 'ocfs2_reflink_remap_blocks()'
as well, but, since 'ocfs2_run_deallocs()' is a safe no-op for
an empty dealloc context, 'ocfs2_create_reflink_node()' and
'ocfs2_reflink_xattrs()' may be adjusted in the same way too,
thus keeping the code pattern consistent.
Link: https://lore.kernel.org/20260721102840.387663-1-dmantipov@yandex.ru
Link: https://lore.kernel.org/ocfs2-devel/f1d7e266-4b44-41b9-98c0-5b3868a8d9c3@yandex.ru [1]
Fixes:
|
||
 Paul White
|
fd3c1fd8ba |
selftests: ipc: change operation not supported error number
The application doesn't know what ENOTSUPP means, as it is a kernelspace error code and the application doesn't have access to kernelspace error codes.I used EOPNOTSUPP in its place as that is an error number the application will recognize and know an operation is being attempted that it cannot support. Link: https://lore.kernel.org/20260720204001.1663473-1-paul.white.kernel@gmail.com Signed-off-by: Paul White <paul.white.kernel@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Wei Yang <richard.weiyang@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Doruk Tan Ozturk
|
bc70726dda |
ocfs2: validate directory-index entry counts when reading metadata
ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) dx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit |
||
 Shivank Sharma
|
31288373f6 |
tools/accounting: fix macro typos in getdelays
Correct the spelling of PRINT_FILED_DELAY and PRINT_FILED_DELAY_WITH_TS to PRINT_FIELD_DELAY and PRINT_FIELD_DELAY_WITH_TS respectively. This resolves typo naming errors across the macro definitions and their matching inside print_delayacct(). Link: https://lore.kernel.org/20260716141545.1292951-1-shivanksharma2376543@gmail.com Signed-off-by: Shivank Sharma <shivanksharma2376543@gmail.com> Cc: Fan Yu <fan.yu9@zte.com.cn> Cc: Wang Yaxin <wang.yaxin@zte.com.cn> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Yichong Chen
|
83e98dbf19 |
fat: release buffer head after rebuilding parent
fat_scan_logstart() leaves the matching directory entry's buffer head in
sinfo.bh for the caller to release, just like fat_scan().
fat_rebuild_parent() uses the directory entry to rebuild the parent inode
for the nostale_ro NFS export path, but does not release sinfo.bh after a
successful scan. Release it once fat_build_inode() has consumed the
directory entry data.
Link: https://lore.kernel.org/20260715020957.1096309-1-chenyichong@uniontech.com
Fixes:
|
||
 Christoph Hellwig
|
10dab13117 |
raid6/kunit: add a benchmark
Add a benchmark to test the RAID 6 P/Q functions for more representative block sizes and numbers of disks. This splits the maximum alloc size used for the benchmark from the max size for the kunit test because recovery is currently limited to a single page at a time. Hopefully this will be fixed soon. The runtime numbers are reported in GB/s as the numbers of modern implementations are basically unreadable as MB/s. This means retro-architectures could report 0, but that is an easy tradeoff. Link: https://lore.kernel.org/20260715144825.95432-9-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Christoph Hellwig
|
cfbdbecb29 |
raid6: improve the runtime selection benchmark
Use plain ktime_get_ns for the timing, use 8 + 2 disks for a realistic load, and report the throughput on the data disks as that is what storage systems are measured on. Link: https://lore.kernel.org/20260715144825.95432-8-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Christoph Hellwig
|
d999af2192 |
raid6: defer implementation selection when built-in
Don't hold up early boot and defer the selection just like we've been
doing for the RAID5 XOR code since commit
|
||
|
Christoph Hellwig
|
2083d99bd8 |
raid6: enable lock context analysis
The code doesn't have any locking, so this is trivial. Link: https://lore.kernel.org/20260715144825.95432-6-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Christoph Hellwig
|
874d2edd07 |
xor/kunit: add a benchmark
Add a benchmark to test the XOR functions for more representative block sizes and numbers of disks. Including 64k would be useful here, but increasing the test buffer size increases the runtime of the functional kunit test too much unfortunately. The runtime numbers are reported in GB/s as the numbers of modern implementations are basically unreadable as MB/s. This means retro-architectures could report 0, but that is an easy tradeoff. Link: https://lore.kernel.org/20260715144825.95432-5-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Christoph Hellwig
|
75182f8d57 |
xor/kunit: fix a spelling error
Link: https://lore.kernel.org/20260715144825.95432-4-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Christoph Hellwig
|
2bfd85fd81 |
xor: improve the runtime selection benchmark
Use plain ktime_get_ns for the timing, use 4 + 1 disks for a realistic load, and report the throughput on the data disks instead of the that on the parity disk, which isn't all that useful. Link: https://lore.kernel.org/20260715144825.95432-3-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Christoph Hellwig
|
b6a1359bbe |
xor: enable lock context analysis
Patch series "misc lib/raid/ improvements v2". This series improves the benchmark-based algorithm selection and adds kunit benchmarks for both the XOR and raid6 libraries, and tidies up a few very minor other bits. This patch (of 8): The code doesn't have any locking, so this is trivial. Link: https://lore.kernel.org/20260715144825.95432-1-hch@lst.de Link: https://lore.kernel.org/20260715144825.95432-2-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Ziran Zhang
|
bc96ad381f |
FAT: allow 0xE9 near jump in fat_read_static_bpb()
fat_read_static_bpb() only accepts a short jump as a valid bootstrap code signature for DOS 1.x volumes when the dos1xfloppy mount option is used. However, according to the Microsoft fatgen103.doc, the BS_jmpBoot field has two allowed forms: 0xEB 0x?? 0x90 (short jump + NOP) and 0xE9 0x?? 0x?? (near jump). The specification explicitly states that either form is acceptable. This patch relaxes the check to also accept 0xE9 as the first byte of the jump instruction. Link: https://lore.kernel.org/20260412070109.5197-1-zhangcoder@yeah.net Signed-off-by: Ziran Zhang <zhangcoder@yeah.net> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Christian Brauner <brauner@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Yiyang Chen
|
0a2418c327 |
selftests/acct: share netlink helpers
Extract the duplicated generic netlink boilerplate (netlink_open,
send_request, get_family_id, and NLA walker macros) from cgroupstats.c and
taskstats_fill_stats_tgid.c into a shared netlink_helper.{h,c}.
Link: https://lore.kernel.org/a2adf27308b5cd90d50b59e8519b87da49486bee.1783876192.git.cyyzero16@gmail.com
Signed-off-by: Yiyang Chen <cyyzero16@gmail.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Balbir Singh <balbirs@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
||
|
Joseph Qi
|
041c9d0ab5 |
ocfs2: cluster: use an on-stack bio for the heartbeat write
The disk heartbeat write always covers this node's own single slot, i.e. one heartbeat block that lives within a single page. It is submitted by o2hb_issue_node_write() and waited on by the caller before the ctxt goes out of scope, so its lifetime is well bounded. Turn it into an on-stack bio embedded in struct o2hb_bio_wait_ctxt rather than allocating one from the mempool. This removes any allocation from the fence-critical write path entirely: a delayed or blocked heartbeat write is what leads to the local node being fenced, so it should not depend on the state of a shared bio pool. Because the bio is embedded rather than allocated, add a dedicated o2hb_write_bio_end_io() that does not call bio_put(), and tear the bio down with bio_uninit() once the caller has waited on the I/O. The read path still allocates via o2hb_setup_one_bio() with GFP_NOFS, since it issues a variable number of bios in a loop. Link: https://lore.kernel.org/20260710071756.3586797-2-joseph.qi@linux.alibaba.com Signed-off-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: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Joseph Qi
|
609d45af83 |
ocfs2: cluster: use GFP_NOFS for heartbeat bio allocation
o2hb_setup_one_bio() allocates the heartbeat bio with GFP_ATOMIC. The disk heartbeat runs in the o2hb kernel thread (o2hb_do_disk_heartbeat), which is process context and can sleep, so there is no atomicity requirement here. GFP_ATOMIC lacks __GFP_DIRECT_RECLAIM, so the allocation is not served from the fs_bio_set mempool reserve and can return NULL under memory pressure. A failed heartbeat allocation aborts the heartbeat and can lead to the local node being fenced, which is exactly what the old comment worried about. Use GFP_NOFS instead. It keeps __GFP_DIRECT_RECLAIM so the allocation is backed by the fs_bio_set mempool and cannot fail, while avoiding recursion back into the filesystem during heartbeat I/O. As the allocation can no longer fail, drop the dead ERR_PTR(-ENOMEM) path in o2hb_setup_one_bio() and the now-redundant IS_ERR() handling in its callers. Link: https://lore.kernel.org/20260710071756.3586797-1-joseph.qi@linux.alibaba.com Signed-off-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: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Yiyang Chen
|
e31d33fc33 |
selftests/acct: add cgroupstats functional test
Add a self-contained test for the CGROUPSTATS_CMD_GET genl command that covers three cases: - querying a cgroup v1 hierarchy and verifying the response contains non-zero task counts - rejecting an invalid fd without NLM_F_ACK - rejecting an invalid fd with NLM_F_ACK Link: https://lore.kernel.org/2a56921276f0962f97f00863e8c7d3c3f6893d5a.1783713230.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen <cyyzero16@gmail.com> Cc: Balbir Singh <balbirs@nvidia.com> Cc: Dr. Thomas Orgis <thomas.orgis@uni-hamburg.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
|
Yiyang Chen
|
b0860c1df2 |
taskstats: return -EBADF when cgroupstats receives an invalid fd
Patch series "taskstats: fix cgroupstats invalid fd handling and add selftests". This series fixes an issue where cgroupstats mishandles invalid file descriptors, and introduces a functional kselftest to prevent regressions. When an invalid file descriptor is passed via CGROUPSTATS_CMD_ATTR_FD, cgroupstats_user_cmd() returns 0 instead of an error code. This leads to two broken behaviors depending on netlink flags: - Callers without NLM_F_ACK block indefinitely on recv(). - Callers with NLM_F_ACK receive a misleading success ACK (errno == 0) but no actual statistics payload. The first patch addresses this by returning -EBADF when the fd cannot be resolved. The second patch adds a comprehensive kselftest covering both the valid cgroup v1 query and the invalid fd paths (with and without NLM_F_ACK) to ensure the fixes work as intended. This patch (of 2): cgroupstats_user_cmd() returns 0 without sending a reply or a netlink error when the fd passed via CGROUPSTATS_CMD_ATTR_FD does not resolve to an open file in the caller's table. As a result: - clients that did not set NLM_F_ACK block on recv() indefinitely waiting for a CGROUPSTATS_CMD_NEW message that is never emitted; - clients that set NLM_F_ACK receive a misleading "success" ACK (errno == 0) with no statistics payload. Return -EBADF instead so the netlink layer propagates the error to userspace as expected. Link: https://lore.kernel.org/cover.1783713230.git.cyyzero16@gmail.com Link: https://lore.kernel.org/b4fd9e288e4a48efebaf41b4ffcdb204b06675c4.1783713230.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen <cyyzero16@gmail.com> Acked-by: Balbir Singh <balbirs@nvidia.com> Cc: Dr. Thomas Orgis <thomas.orgis@uni-hamburg.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Ibrahim Hashimov
|
4ca62df6bc |
ocfs2: validate rl_used against rl_count in refcount block validator
ocfs2_find_refcount_rec_in_rl() walks the on-disk refcount record array
with:
for (; i < le16_to_cpu(rb->rf_records.rl_used); i++) {
rec = &rb->rf_records.rl_recs[i];
...
rl_recs[] lives in a single metadata block (4096 bytes on the common
configuration), so its real capacity is fixed by
ocfs2_refcount_recs_per_rb(sb) (247 records for a 4K block with the
16-byte ocfs2_refcount_rec). rl_used and rl_count are both read directly
off disk by ocfs2_validate_refcount_block() and are never checked against
that capacity, nor against each other, before any refcount/reflink/CoW
operation walks the array.
A crafted (or corrupted) refcount block with rl_used == 0xffff makes the
loop above walk far past the end of the block, dereferencing rl_recs[i]
for i up to 65534. The resulting index is then handed to the sibling
ocfs2_insert_refcount_rec(), whose insert-shift does:
if (index < le16_to_cpu(rf_list->rl_used))
memmove(&rf_list->rl_recs[index + 1],
&rf_list->rl_recs[index],
(le16_to_cpu(rf_list->rl_used) - index) *
sizeof(struct ocfs2_refcount_rec));
i.e. a memmove() of up to (0xffff - index) * 16 bytes (~1 MiB) from an
offset already past the block. This is reachable from an ordinary reflink
(FICLONE) against a crafted/corrupted ocfs2 image: attaching an extent
whose cpos sorts past every real record in the leaf forces the lookup to
run off the end instead of returning early on a match. The attacker model
is local: CAP_SYS_ADMIN mounting a crafted or corrupted ocfs2 image, or a
raw write to the block device backing an already-mounted ocfs2 filesystem.
ocfs2_validate_refcount_block() already validates the block's ECC,
signature, rf_blkno and rf_fs_generation, but never rl_count/rl_used
against the block's actual on-disk capacity. This is the same class of
gap that ocfs2_validate_extent_block() (fs/ocfs2/alloc.c) already closes
for the sibling extent-list header, which checks both the record capacity
and the "used" bound before any code walks h_list.l_recs[]:
if (le16_to_cpu(eb->h_list.l_count) != ocfs2_extent_recs_per_eb(sb)) {
rc = ocfs2_error(...);
goto bail;
}
if (le16_to_cpu(eb->h_list.l_next_free_rec) >
le16_to_cpu(eb->h_list.l_count)) {
rc = ocfs2_error(...);
goto bail;
}
Add the equivalent pair of checks to ocfs2_validate_refcount_block():
reject a refcount block whose rl_count does not match the fixed per-block
capacity returned by ocfs2_refcount_recs_per_rb(), and reject rl_used >
rl_count. Both checks are skipped when OCFS2_REFCOUNT_TREE_FL is set,
because in that case the same union bytes hold an ocfs2_extent_list
(rf_list), not the refcount record list (rf_records) -- that layout is
already validated separately by ocfs2_validate_extent_block() when the
referenced extent block is read. This mirrors the existing
"!(rb->rf_flags & OCFS2_REFCOUNT_TREE_FL)" guard used elsewhere in this
file (e.g. ocfs2_get_refcount_rec()) to decide whether rf_records or
rf_list is the live member of the union.
With this in place, a forged rl_used/rl_count is caught at block
validation time (ocfs2_error()), consistent with every other corruption
check in this function, instead of driving an out-of-bounds read in
ocfs2_find_refcount_rec_in_rl() and a subsequent out-of-bounds memmove()
in ocfs2_insert_refcount_rec().
Verified against a crafted image on a v6.19 KASAN (KASAN_GENERIC) build:
replaying the same reflink (FICLONE) reliably hit a KASAN report in
__ocfs2_increase_refcount()/ocfs2_insert_refcount_rec() before this patch,
and triggers no report once ocfs2_validate_refcount_block() rejects the
forged rl_used/rl_count.
Link: https://lore.kernel.org/20260709132609.44233-1-security@auditcode.ai
Fixes:
|
||
 Guangshuo Li
|
b74030fbf1 |
rapidio: clear mport->net when rio_add_net() fails
rio_alloc_net() stores the newly allocated rio_net in mport->net before
rio_scan_alloc_net() registers the device.
If rio_add_net() fails, rio_scan_alloc_net() drops the device reference
with put_device(), which releases the rio_net through the device release
callback. However, mport->net is left pointing at the freed object.
A later mport unregister path can then dereference the dangling mport->net
pointer and may try to free the same rio_net again.
Clear mport->net in the rio_add_net() failure path, matching the cleanup
done for the destID table allocation failure path.
Link: https://lore.kernel.org/20260708070628.721010-1-lgs201920130244@gmail.com
Fixes:
|
||
|
Dmitry Antipov
|
d48ace6532 |
ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full()
This reverts commit |
||
 Charlie Jenkins
|
03d0a3bebc |
mailmap: add entry for Charlie Jenkins
My Rivos email started bouncing so redirect to my personal email. Link: https://lore.kernel.org/20260709-mailmap-v1-1-74d98b8149d6@gmail.com Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Cc: Paul Walmsley <pjw@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Chen-Yu Tsai
|
d66bf04b99 |
checkpatch: don't emit warnings for ID-base USB & PCI DT compatibles
The USB and PCI device bindings define some compatible patterns based on
device IDs that use the comma to separate vendor and product IDs.
These prefix patterns include:
- ^usb(if)?[0-9a-f]{1,4},
- ^pci[0-9a-f]{2,4},
- ^pciclass,
These are not real vendor prefixes. Don't emit warnings for them.
Instead just skip over the DT compatible check altogether, and leave the
real check to the DT validator. This avoids false positive warnings about
undocumented DT vendor prefixes and compatibles.
Note that the script mostly only checks the first compatible string of
each node, as it processes the source file line-by-line, and the check
only matches on the line with 'compatible = "..."'. Otherwise there would
be more warnings from arch/mips/boot/dts/loongson/ls7a-pch.dtsi since that
file also includes compatibles like "pciclass0c0310" and "pciclass0c03"
which are not accepted either. "pci0014,7a24.0" is not valid either, but
this patch leaves the real check to the DT validator.
Link: https://lore.kernel.org/20260707074629.3132930-1-wenst@chromium.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Dwaipayan Ray <dwaipayanray1@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
||
 Nathan Chancellor
|
f9632fe349 |
.get_maintainer.ignore: add Nathan Chancellor
I do work all over the tree as part of ClangBuiltLinux and Kbuild, which ultimately results in a lot of irrelevant CCs when submitters run get_maintainer.pl with the default git fallback enabled. Add myself to .get_maintainer.ignore so I only get CC'd through explicitly maintained files/patterns or a submitter intentionally adding me to the list. Link: https://lore.kernel.org/20260707-add-nathan-to-get_maintainers-ignore-v1-1-810926e8eea3@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 JianChunfu
|
1db1573bc5 |
kernel/fork: declare max_threads __read_mostly
max_threads is initialized once by fork_init()->set_max_threads(), and
thereafter is mostly read in hot path, such as copy_process().
The fact that it is mostly read and not written to makes it candidates for
__read_mostly declarations.
I have already tested on my machine(arm64,256core,kernel-7.1.3) with
'hackbench -P -l 500 -g 100/500/1000/2000' and the results show that there
is an average of 13% improvement in performance.
before patch:
hackbench -g 100 500 1000 2000
1.094 4.651 13.305 36.322
after patch:
hackbench -g 100 500 1000 2000
0.823 4.487 11.107 32.987
Above data are the average values obtained from multiple tests, and there
was indeed some fluctuation in the data during the tests.
Link: https://lore.kernel.org/20260707092354.465847-1-jansef.jian@hj-micro.com
Signed-off-by: JianChunfu <jansef.jian@hj-micro.com>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
||
 Petr Mladek
|
dc334b36ed |
Revert "printf: Compile the kunit test with DISABLE_BRANCH_PROFILING DISABLE_BRANCH_PROFILING"
This reverts commit |
||
|
Yiyang Chen
|
99f62c4842 |
taskstats: remove dead taskstats_exit_mutex declaration
The extern declaration of taskstats_exit_mutex has never been defined nor referenced anywhere now. Just remove it. Link: https://lore.kernel.org/98948e69094b73d6dfa63dcf0770067b57f3becf.1783435695.git.cyyzero16@gmail.com Signed-off-by: Yiyang Chen <cyyzero16@gmail.com> Cc: Balbir Singh <balbirs@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Cen Zhang
|
2cf82b46d5 |
ocfs2: validate external xattr entries when reading metadata
ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block. Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check. Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time. The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target. Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_list_entries+0xd7/0x190 ocfs2_listxattr+0x3f6/0x610 listxattr+0x90/0xe0 path_listxattrat+0xed/0x220 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Link: https://lore.kernel.org/20260705025311.3429854-3-zzzccc427@gmail.com Fixes: |
||
|
Cen Zhang
|
8914a3330b |
ocfs2: validate inline xattrs during inode block validation
Patch series "ocfs2: validate xattr entry bounds", v7.
This series validates OCFS2 xattr entry name/value bounds when xattr
metadata is read and validated, before getxattr() or listxattr() can walk
out-of-range entry arrays or offsets from corrupted metadata.
This patch (of 2):
ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk
metadata from it, but inline xattr metadata is still checked only in
operation-specific consumers. The existing ibody lookup helper validates
inline header placement and entry count, but inode block validation does
not reject entry name/value bounds.
Add a flat xattr entry validator and call it from inode block validation
for inline xattrs. Keep the operation paths on their existing
header/count lookup checks; the full entry bounds check now runs when the
inode block is validated at read time.
Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or
listxattr() can walk past the inline storage.
Validation reproduced this kernel report:
BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170
Read of size 2 at addr ffff8881242a2000 by task python3/529
Call Trace:
dump_stack_lvl+0x66/0xa0
print_report+0xce/0x630
kasan_report+0xe0/0x110
ocfs2_xattr_find_entry+0x5a/0x170
ocfs2_xattr_get_nolock+0x20a/0x820
ocfs2_xattr_get+0x10c/0x1e0
__vfs_getxattr+0xe2/0x130
vfs_getxattr+0x185/0x1b0
Link: https://lore.kernel.org/20260705025311.3429854-1-zzzccc427@gmail.com
Link: https://lore.kernel.org/20260705025311.3429854-2-zzzccc427@gmail.com
Fixes:
|
||
 Calvin Owens
|
b899e0279f |
pps-gpio: remove dead capture_clear code
The capture_clear field is never set, and all code conditional on it being set has been unreachable since the platform data logic was removed from pps-gpio in |
||
|
Calvin Owens
|
3649f9a6b8 |
pps: don't allow PPS_KC_BIND on removed devices
If userspace holds its file descriptor open, it can call PPS_KC_BIND on a
device which has been unplugged, leaving pps_kc_hardpps_dev as a dangling
pointer after close().
After that sequence, PPS_KC_BIND is broken until the system is rebooted,
because the pointer comparison in pps_kc_bind() can never be true.
calling pps_ktimer_init+0x0/0x1000 [pps_ktimer] @ 1081
initcall pps_ktimer_init+0x0/0x1000 [pps_ktimer] returned 0 after 811 usecs
pps pps0: bound kernel consumer: edge=0x1
pps pps0: unbound kernel consumer on device removal
pps pps0: bound kernel consumer: edge=0x1
calling pps_ktimer_init+0x0/0x1000 [pps_ktimer] @ 1085
initcall pps_ktimer_init+0x0/0x1000 [pps_ktimer] returned 0 after 340 usecs
pps pps0: another kernel consumer is already bound
Here is a short reproducer, which uses rmmod of the pps-ktimer testcase
to simulate a device being unplugged:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/pps.h>
#include <errno.h>
#include <err.h>
int main(void)
{
while (1) {
int fd;
if (system("insmod ./pps-ktimer.ko"))
err(1, "insmod failed");
fd = open("/dev/pps0", O_RDWR);
if (fd == -1)
err(1, "open failed");
struct pps_bind_args args = {
.tsformat = PPS_TSFMT_TSPEC,
.edge = PPS_CAPTUREASSERT,
.consumer = PPS_KC_HARDPPS,
};
if (ioctl(fd, PPS_KC_BIND, &args))
err(1, "first PPS_KC_BIND failed");
if (system("rmmod pps-ktimer"))
err(1, "rmmod failed");
if (ioctl(fd, PPS_KC_BIND, &args)) {
if (errno != ENODEV)
err(1, "second PPS_KC_BIND failed");
else
puts("Got ENODEV, kernel is patched");
}
close(fd);
}
}
Fix this by setting a flag when the device is unplugged, returning -ENODEV
from PPS_KC_BIND if the flag is set.
For userspace to encounter this new behavior, it must do something which
breaks the interface today, so this fix shouldn't cause any observable
behavior change for working programs.
Link: https://lore.kernel.org/672778c177ac9b6fdcb445e35c97ac4ca7d1149f.1780506611.git.calvin@wbinvd.org
Signed-off-by: Calvin Owens <calvin@wbinvd.org>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/cover.1779733602.git.calvin%40wbinvd.org?part=1
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
||
|
Calvin Owens
|
45217e9898 |
pps: don't try to wait for negative timeouts in PPS_FETCH
If userspace passes a negative timeout to PPS_FETCH, it triggers a kernel
splat from schedule_timeout():
schedule_timeout: wrong timeout value fffffffffff0bfb4
CPU: 17 UID: 0 PID: 4720 Comm: a.out Not tainted 7.1.0-rc5-x86-kvm-00150-g331d97e36b37 #1 PREEMPT_RT
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-20240910_120124-localhost 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x4b/0x70
schedule_timeout+0xb7/0xe0
pps_cdev_pps_fetch.isra.0+0x93/0x150
pps_cdev_ioctl+0x70/0x310
__x64_sys_ioctl+0x7b/0xc0
do_syscall_64+0xb6/0xfc0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Here is a trivial reproducer that works with the PPS_CLIENT_KTIMER test
device enabled in the kernel:
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/pps.h>
#include <err.h>
int main() {
struct pps_fdata fdata;
int fd;
fd = open("/dev/pps0", O_RDWR);
if (fd == -1)
err(1, "Failed to open /dev/pps0");
fdata.timeout.sec = -1;
fdata.timeout.nsec = 0;
if (ioctl(fd, PPS_FETCH, &fdata))
err(2, "PPS_FETCH failed");
close(fd);
return 0;
}
Sashiko imagines this to be some sort of security problem, which is
obviously really silly. But I think it is still worth fixing, so buggy
userspace code can't trigger the splat.
Silence the splat by using timespec64_to_jiffies(), which hard limits the
timeout to LONG_MAX jiffies. To be safe, explicitly preserve the
-ETIMEDOUT return value userspace sees today if it passes a negative
timeout.
If you really squint, this is still a slight behavior change in that there
are "denormalized" combinations of tv_sec and tv_nsec which used to work
but will now return -ETIMEDOUT. I can't imagine anybody will care about
that...
Link: https://lore.kernel.org/c5c97c3b3c9d66010382094fd538e59a38f4aacf.1781289959.git.calvin@wbinvd.org
Fixes:
|
||
 Kir Chou
|
108646f7d9 |
lib/random32: convert selftest to KUnit
Convert the existing prandom selftest (lib/random32.c) to use the KUnit framework (lib/tests/random32_kunit.c). Unlike typical KUnit tests, this file is directly #included into lib/random32.c. The new test: - Removes the legacy CONFIG_RANDOM32_SELFTEST from lib/random32.c. - Adds CONFIG_PRANDOM_KUNIT_TEST (defaulting to KUNIT_ALL_TESTS). - Moves the test logic to lib/tests/random32_kunit.c. This commit is verified by `./tools/testing/kunit/kunit.py run` with the .kunit/.kunitconfig: CONFIG_KUNIT=y CONFIG_PRANDOM_KUNIT_TEST=y Link: https://lore.kernel.org/20260703050100.23944-1-note351@hotmail.com Signed-off-by: Kir Chou <note351@hotmail.com> Reviewed-by: David Gow <davidgow@google.com> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: David S. Miller <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Kuan-Wei Chiu <visitorckw@gmail.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Michael Byczkowski
|
93781560b2 |
pps: pps-gpio: split IRQ handler into hardirq timestamper + threaded handler
Split the pps-gpio interrupt handler into a primary (hardirq) handler that captures the PPS timestamp at interrupt entry, and a threaded handler that processes the event. This produces the same two-part handler structure on both PREEMPT_RT and non-RT kernels. On non-RT kernels the threaded portion runs immediately after the primary, with no behavioral change compared to the previous single-handler implementation. On PREEMPT_RT, where interrupt handlers are force-threaded by default, the previous single-handler implementation captured the timestamp inside the threaded portion, after IRQ-thread scheduling delay. With the split, the timestamp is captured in true hardirq context as it is on non-RT kernels, eliminating a significant source of PPS jitter on RT systems. Link: https://lore.kernel.org/2e32729029fbf6977ecf04665eb00f2efd3e2c17.1780359378.git.calvin@wbinvd.org Signed-off-by: Michael Byczkowski <by@by-online.de> Signed-off-by: Calvin Owens <calvin@wbinvd.org> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: Michael Byczkowski <by@by-online.de> Tested-by: Calvin Owens <calvin@wbinvd.org> Acked-by: Rodolfo Giometti <giometti@enneenne.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Jiaming Zhang
|
8fdcbb5b37 |
ocfs2: fix hung task in orphan recovery
A crafted OCFS2 image with corrupted orphan-directory extent metadata can make umount hang. During unmount, ocfs2_recovery_disable() waits for the ocfs2_complete_recovery work item to finish. The worker scans the orphan directory through ocfs2_queue_orphans() and ocfs2_dir_foreach(). If ocfs2_read_dir_block() fails on a corrupted directory block, ocfs2_dir_foreach_blk_el() skips the block and continues walking. On a badly corrupted directory this can keep orphan recovery busy for a long time, leaving umount blocked while flushing osb->ocfs2_wq. Return the read error immediately for full directory scans and propagate the error from ocfs2_dir_foreach(). When ocfs2_empty_dir() receives such an error, report the directory as non-empty so unlink/rmdir does not proceed on an unreadable directory. Link: https://lore.kernel.org/20260702090507.446517-1-r772577952@gmail.com Closes: https://lore.kernel.org/lkml/CANypQFbWH76Y6LWHEwAvTP7aQL04uMJ=dDyL6YDmxa3fv3Tyjg@mail.gmail.com/ Assisted-by: Codex:gpt-5.5-xhigh Signed-off-by: Jiaming Zhang <r772577952@gmail.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: Jun Piao <piaojun@huawei.com> Cc: Heming Zhao <heming.zhao@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
 Bryam Vargas
|
b54e03d9b3 |
ocfs2: validate lengths in dlm_mig_lockres_handler
A node receiving a DLM_MIG_LOCKRES message trusts several fields of the
peer-supplied dlm_migratable_lockres without validation. num_locks and
lockname_len are bounded only on the sending side, and the message is
never checked to actually carry num_locks migratable_lock entries. As a
result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the
kmalloc(data_len) copy of the message (an out-of-bounds read that ends in
a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the
fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write).
Both are reachable by any node in the domain.
Validate these fields right after dlm_grab(), before anything uses them --
including the not-joined error path, which already prints mres->lockname
with the unbounded lockname_len as a %.*s precision. Reject the message
unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <=
DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the
payload is large enough to hold the claimed locks. Conforming recovery
and migration messages are unaffected.
Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-2-6953bcc0421f@proton.me
Fixes:
|
||
|
Bryam Vargas
|
ea5b560930 |
ocfs2: bound namelen in dlm_migrate_request_handler
Patch series "ocfs2/dlm: bound peer-controlled lengths in the o2dlm".
The o2dlm receive handlers trust u8 length and count fields from the wire
without bounding them, so a node in a DLM domain can corrupt or panic any
other node with a malformed message. Three defects:
- dlm_migrate_request_handler() passes migrate->namelen unchecked to
dlm_init_mle(), which memcpy()s it into the 32-byte mname[] of an
o2dlm_mle slab object: a heap out-of-bounds write of up to ~215
attacker-controlled bytes.
- dlm_mig_lockres_handler() passes mres->lockname_len unchecked to
dlm_init_lockres(), which memcpy()s it into the 32-byte o2dlm_lockname
slab object: a heap out-of-bounds write of up to ~223 bytes.
- the same handler trusts mres->num_locks without checking that the
message is large enough to hold that many entries, so
dlm_process_recovery_data() walks mres->ml[] past the kmalloc(data_len)
copy and trips a BUG_ON (an out-of-bounds read ending in a panic).
The other o2dlm receive handlers already reject an oversized name; the
migration and recovery handlers have omitted it since the DLM was added
(see the Fixes tags). Patch 1 bounds namelen; patch 2 validates
lockname_len, num_locks, and the payload size. Conforming recovery and
migration traffic is unaffected.
o2net authenticates peers only by the DLM domain key, so any node that has
joined the domain -- including a compromised or malicious member -- can
send these messages. There is no local trigger; the attacker must already
be a member of the cluster.
Each sink was confirmed under KASAN with an out-of-tree module mirroring
it exactly -- a kmem_cache/kmalloc of the real destination size, then the
same unclamped memcpy/loop: slab-out-of-bounds Write for the two writes,
Read for the recovery walk, and a panic. A userspace AddressSanitizer
build faults identically under -m32 and -m64. Scrubbed logs are available
on request.
I reported this privately to security@kernel.org and the ocfs2 maintainers
on 2026-06-20; with no response after the standard embargo period I am
posting the fix publicly. I have no embargo requirement.
This patch (of 2):
A node receiving a DLM_MIGRATE_REQUEST message trusts the peer-supplied
name length (migrate->namelen) without bounding it. dlm_init_mle() then
copies that many bytes into the fixed DLM_LOCKID_NAME_MAX-byte mname[]
array of an o2dlm_mle slab object, so a malformed message from a cluster
peer overflows the slab object by up to ~215 bytes: a heap out-of-bounds
write of attacker-controlled data, reachable by any node in the domain.
Reject an oversized name, the way dlm_master_request_handler() and the
other o2dlm receive handlers already do; the migration handler omits the
check entirely. Conforming messages are unaffected.
Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-0-6953bcc0421f@proton.me
Link: https://lore.kernel.org/20260629-b4-disp-94fb6521-v1-1-6953bcc0421f@proton.me
Fixes:
|
||
 Joy H.J. Lee
|
8700a4761b |
tools/compiler: match glibc 2.42 definition of __attribute_const__
glibc 2.42 added __attribute_const__ to sys/cdefs.h:
# define __attribute_const__ __attribute__ ((__const__))
GCC 15 warns when a macro is redefined to a different replacement list
(-Wbuiltin-macro-redefined). Since host tool Makefiles (resolve_btfids,
objtool) pass -Werror, this conflict becomes fatal.
The warning is suppressed on standard native builds because GCC treats
/usr/include as a system header path (-isystem), and macro-redefinition
warnings from system headers are silently suppressed by GCC. It fires
when glibc headers are on a regular include path (-I) instead, which
is the case in cross-compilation setups such as NixOS, where the
sysroot's glibc is passed explicitly via -I rather than -isystem.
Per (C11 6.10.3), identical replacement lists are accepted silently.
Match the glibc definition exactly, including the space before "((", so
the redefinition is accepted without warning regardless of whether
glibc headers are treated as system or non-system includes.
Link: https://lore.kernel.org/20260701200635.3992767-1-rkr0k0r@gmail.com
Signed-off-by: Joy H.J. Lee <rkr0k0r@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|