[LTS 8.8 RT] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm #84
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pvts-mat
force-pushed
the
ciqlts8_8-rt-CVE-2022-42896
branch
from
f782661 to
7fdf696
Compare
jira VULN-207 cve CVE-2022-42896 commit-author Luiz Augusto von Dentz <[email protected]> commit f937b75 l2cap_global_chan_by_psm shall not return fixed channels as they are not meant to be connected by (S)PSM. Signed-off-by: Luiz Augusto von Dentz <[email protected]> Reviewed-by: Tedd Ho-Jeong An <[email protected]> (cherry picked from commit f937b75) Signed-off-by: Marcin Wcisło <[email protected]>
pvts-mat
force-pushed
the
ciqlts8_8-rt-CVE-2022-42896
branch
from
7fdf696 to
0a9abf0
Compare
bmastbergen
approved these changes
Jan 27, 2025
github-actions bot
pushed a commit
that referenced
this pull request
May 31, 2025
w/ below testcase, it will cause inconsistence in between SIT and SSA. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file fallocate -l 4GiB /mnt/f2fs/file F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: <TASK> dump_stack_lvl+0xb3/0xd0 dump_stack+0x14/0x20 f2fs_handle_critical_error+0x18c/0x220 [f2fs] f2fs_stop_checkpoint+0x38/0x50 [f2fs] do_garbage_collect+0x674/0x6e0 [f2fs] f2fs_gc_range+0x12b/0x230 [f2fs] f2fs_allocate_pinning_section+0x5c/0x150 [f2fs] f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs] f2fs_fallocate+0x3c3/0x410 [f2fs] vfs_fallocate+0x15f/0x4b0 __x64_sys_fallocate+0x4a/0x80 x64_sys_call+0x15e8/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f9dba5197ca F2FS-fs (nullb0): Stopped filesystem due to reason: 4 The reason is f2fs_gc_range() may try to migrate block in curseg, however, its SSA block is not uptodate due to the last summary block data is still in cache of curseg. In this patch, we add a condition in f2fs_gc_range() to check whether section is opened or not, and skip block migration for opened section. Fixes: 9703d69 ("f2fs: support file pinning for zoned devices") Reviewed-by: Daeho Jeong <[email protected]> Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
github-actions bot
pushed a commit
that referenced
this pull request
Jun 20, 2025
[ Upstream commit 773704c ] w/ below testcase, it will cause inconsistence in between SIT and SSA. create_null_blk 512 2 1024 1024 mkfs.f2fs -m /dev/nullb0 mount /dev/nullb0 /mnt/f2fs/ touch /mnt/f2fs/file f2fs_io pinfile set /mnt/f2fs/file fallocate -l 4GiB /mnt/f2fs/file F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: <TASK> dump_stack_lvl+0xb3/0xd0 dump_stack+0x14/0x20 f2fs_handle_critical_error+0x18c/0x220 [f2fs] f2fs_stop_checkpoint+0x38/0x50 [f2fs] do_garbage_collect+0x674/0x6e0 [f2fs] f2fs_gc_range+0x12b/0x230 [f2fs] f2fs_allocate_pinning_section+0x5c/0x150 [f2fs] f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs] f2fs_fallocate+0x3c3/0x410 [f2fs] vfs_fallocate+0x15f/0x4b0 __x64_sys_fallocate+0x4a/0x80 x64_sys_call+0x15e8/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f9dba5197ca F2FS-fs (nullb0): Stopped filesystem due to reason: 4 The reason is f2fs_gc_range() may try to migrate block in curseg, however, its SSA block is not uptodate due to the last summary block data is still in cache of curseg. In this patch, we add a condition in f2fs_gc_range() to check whether section is opened or not, and skip block migration for opened section. Fixes: 9703d69 ("f2fs: support file pinning for zoned devices") Reviewed-by: Daeho Jeong <[email protected]> Cc: Daeho Jeong <[email protected]> Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
github-actions bot
pushed a commit
that referenced
this pull request
Aug 5, 2025
============================= [ BUG: Invalid wait context ] 6.13.0-rc1 #84 Tainted: G O ----------------------------- cat/56160 is trying to lock: ffff888105c86648 (&cprc->stat_lock){+.+.}-{3:3}, at: update_general_status+0x32a/0x8c0 [f2fs] other info that might help us debug this: context-{5:5} 2 locks held by cat/56160: #0: ffff88810a002a98 (&p->lock){+.+.}-{4:4}, at: seq_read_iter+0x56/0x4c0 #1: ffffffffa0462638 (f2fs_stat_lock){....}-{2:2}, at: stat_show+0x29/0x1020 [f2fs] stack backtrace: CPU: 0 UID: 0 PID: 56160 Comm: cat Tainted: G O 6.13.0-rc1 #84 Tainted: [O]=OOT_MODULE Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: <TASK> dump_stack_lvl+0x88/0xd0 dump_stack+0x14/0x20 __lock_acquire+0x8d4/0xbb0 lock_acquire+0xd6/0x300 _raw_spin_lock+0x38/0x50 update_general_status+0x32a/0x8c0 [f2fs] stat_show+0x50/0x1020 [f2fs] seq_read_iter+0x116/0x4c0 seq_read+0xfa/0x130 full_proxy_read+0x66/0x90 vfs_read+0xc4/0x350 ksys_read+0x74/0xf0 __x64_sys_read+0x1d/0x20 x64_sys_call+0x17d9/0x1b80 do_syscall_64+0x68/0x130 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f2ca53147e2 - seq_read - stat_show - raw_spin_lock_irqsave(&f2fs_stat_lock, flags) : f2fs_stat_lock is raw_spinlock_t type variable - update_general_status - spin_lock(&sbi->cprc_info.stat_lock); : stat_lock is spinlock_t type variable The root cause is the lock order is incorrect [1], we should not acquire spinlock_t lock after raw_spinlock_t lock, as if CONFIG_PREEMPT_LOCK is on, spinlock_t is implemented based on rtmutex, which can sleep after holding the lock. To fix this issue, let's use change f2fs_stat_lock lock type from raw_spinlock_t to spinlock_t, it's safe due to: - we don't need to use raw version of spinlock as the path is not performance sensitive. - we don't need to use irqsave version of spinlock as it won't be used in irq context. Quoted from [1]: "Extend lockdep to validate lock wait-type context. The current wait-types are: LD_WAIT_FREE, /* wait free, rcu etc.. */ LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */ LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */ LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */ Where lockdep validates that the current lock (the one being acquired) fits in the current wait-context (as generated by the held stack). This ensures that there is no attempt to acquire mutexes while holding spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In other words, its a more fancy might_sleep()." [1] https://lore.kernel.org/all/[email protected] Fixes: 98237fc ("f2fs: use spin_lock to avoid hang") Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
github-actions bot
pushed a commit
that referenced
this pull request
Oct 7, 2025
For 8-bit and 16-bit sign-extention mov instructions, it can use the native instructions ext.w.b and ext.w.h directly, no need to use the temporary t1 register, just remove the redundant operations. Here are the test results: # modprobe test_bpf test_range=81,84 # dmesg -t | tail -5 test_bpf: #81 ALU_MOVSX | BPF_B jited:1 5 PASS test_bpf: #82 ALU_MOVSX | BPF_H jited:1 5 PASS test_bpf: #83 ALU64_MOVSX | BPF_B jited:1 5 PASS test_bpf: #84 ALU64_MOVSX | BPF_H jited:1 5 PASS test_bpf: Summary: 4 PASSED, 0 FAILED, [4/4 JIT'ed] Acked-by: Hengqi Chen <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CVE-2022-42896
VULN-207
Solution
The bug fix in the mainline is provided1 in two commits:
f937b758a188d6fd328a81367087eddbb2fce50f711f8c3fb3db61897080468586b970c87c61d9e4Of these the
711f8c3is already applied onciqlts8_8-rt(commit698b38781fe5e12c9a62104a6e4d2d09d1b49b68).(Same situation as in #41)
Build
Kernel built on virtual machine instantiated on physical Rocky 9 machine with
from the https://gitlab.conclusive.pl/devices/rocky-patching project. Installed on a testing machine created with
kABI check: omitted
Boot test: passed
boot-test.log
Kselftests: passed relative
Kselftests were split into two parts:
kernel-rt-selftests-internalpackage (for ease of use and stability of the tests) andPackaged tests
Tests set covered
bpflivepatchnetnet/forwardingnet/mptcpnetfiltertc-testingvmTests stability analysis on a reference kernel
A series of 7 test runs were conducted on the reference LTS 8.8 RT kernel
ciqlts8_8-rt(eca3abc5e9ff4cae5b5d2a54869f2196d281aefe) of which 3 finished without issues.kselftests–rpm–ciqlts8_8-rt–run-1.log
kselftests–rpm–ciqlts8_8-rt–run-2.log
kselftests–rpm–ciqlts8_8-rt–run-3.log
It was found that
bpf:test_progs-no_alu32,bpf:test_progs: Sometimes cause the machine to spontaneously reboot, interrupting the tests run.bpf:test_xsk.sh: Sometimes hangs the machine indefinitely.net/mptcp:simult_flows.sh,net:gro.sh,net:udpgro_fwd.shFor the full picture of unit tests stability state refer to the column https://docs.google.com/spreadsheets/d/1tUwJ2rV57cYZXh7momPtraSjZcHDjMYHLeHA3DYWrUU/edit?pli=1&gid=0#gid=0&range=F:F
Patched kernel
A series of 2 test runs were conducted on the patched kernel, with the machine-hanging
bpf:test_xsk.shtest omitted.kselftests–rpm–ciqlts8_8-rt-CVE-2022-42896–run-1.log
kselftests–rpm–ciqlts8_8-rt-CVE-2022-42896–run-2.log
Comparison
With the unstable tests
bpf:test_progs-no_alu32,bpf:test_progs,bpf:test_xsk.sh,net/mptcp:simult_flows.sh,net:gro.sh,net:udpgro_fwd.shomitted all test results are the same in the patched and referential kernels.Source-compiled tests
Tests set covered
breakpointscapabilitiescgroupcorecpu-hotplugcpufreqdrivers/net/bondingdrivers/net/teamefivarfsexecfilesystemsfirmwarefpuftracefutexintel_pstateipckcmpkvmliblivepatchmembarriermemory-hotplugmountmqueuenetnet/forwardingnet/mptcpnetfilternsfsprocpstoreptracertcsgxsigaltstacksizesplicestatic_keyssyncsysctltc-testingtdxtimenstimerstpm2uservmx86zramTests stability analysis on a reference kernel
A series of 2 test runs were conducted on the reference LTS 8.8 RT kernel
ciqlts8_8-rt(eca3abc5e9ff4cae5b5d2a54869f2196d281aefe)kselftests–source–ciqlts8_8-rt–run-1.log
kselftests–source–ciqlts8_8-rt–run-2.log
It was found that three tests are "flappy", their results differing depending on the run:
ipc:msgquekvm:hardware_disable_testnet:devlink_port_split.pyFor the full picture of unit tests stability state refer to the column https://docs.google.com/spreadsheets/d/1tUwJ2rV57cYZXh7momPtraSjZcHDjMYHLeHA3DYWrUU/edit?pli=1&gid=0#gid=0&range=G:G
Patched kernel
A series of 2 test runs were conducted on the patched kernel
kselftests–source–ciqlts8_8-rt-CVE-2022-42896–run-1.log
kselftests–source–ciqlts8_8-rt-CVE-2022-42896–run-2.log
Comparison
With the tests found to be indeterministic in the stability analysis omitted the test results for the patched kernel were the same as for the reference kernel, except for the
kvm:vmx_preemption_timer_testtest.Additional
kvmtest runs on the patched kernel resulted inkvm:vmx_preemption_timer_testagain passing, indicating that this test is also unstablekselftests–source–ciqlts8_8-rt-CVE-2022-42896–run-kvm.log
Additional tests: none
Following the guidelines from the precedent #41.
Footnotes
1 GHSA-pf87-6c9q-jvm4