[LTS 9.2] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm #44

pvts-mat · 2025-01-09T03:23:34Z

CVE-2022-42896, VULN-210

Solution

The bug fix in the mainline is provided in two commits:

f937b758a188d6fd328a81367087eddbb2fce50f
711f8c3fb3db61897080468586b970c87c61d9e4

Of these the 711f8c3 is already applied on ciqlts9_2.

(Same situation as in #41)

Build

Kernel built on Rocky 9 machine with

CVE=CVE-2022-42896 ./ninja.sh _compile_ciqlts9_2-CVE-2022-42896

from the https://gitlab.conclusive.pl/devices/rocky-patching project.

kABI check: passed

kABI ran on the build machine with

python3 /mnt/code/kernel-dist-git/SOURCES/check-kabi \
        -k /mnt/code/kernel-dist-git/SOURCES/Module.kabi_$(uname -m) \
        -s /mnt/build_files/kernel-src-tree-ciqlts9_2-CVE-2022-42896/Module.symvers

for the /mnt/code/kernel-dist-git repo in the state of

On branch el-9.2
Your branch is up to date with 'origin/el-9.2'.

commit hash d55abe03912e1cf92944e3aaaefc89402923eda3.

Boot test: passed

Logs boot-test.log for the kernel booted with

CVE=CVE-2022-42896 ./ninja.sh _boot_kernel-ciqlts9_2-CVE-2022-42896

from within the rocky-patching project.

Kselftests: passed

Kselftests ran with

MACHINE=test-ciqlts9_2-CVE-2022-42896 CVE=CVE-2022-42896 ./ninja.sh kselftests

and prepared with

modprobe bluetooth

Results:

kselftests-patch–ciqlts9_2-CVE-2022-42896.zip
Flat text file form:
kselftests-patch–ciqlts9_2-CVE-2022-42896.log

Reference results of the tests ran on ciqlts9_2 (c566432b9c6923174f979ee0811749d1b4045d9f):

kselftests-reference–ciqlts9_2.zip
Flat text file form:
kselftests-reference–ciqlts9_2.log

Comparison:

comparison-patch-reference.csv

Summary: all test cases have the same results as the reference. Tests bpf:test_progs, bpf:test_progs-no_alu32, net:fib_tests.sh, net:rps_default_mask.sh, netfilter:conntrack_tcp_unreplied.sh, netfilter:nft_flowtable.sh, netfilter:nft_nat.sh, tc-testing:tdc.sh fail in both reference and patched kernel version. To be investigated on demand.

Additional tests: none

Following the guidelines from the precedent #41.

gvrose8192

LGTM - Thanks.

bmastbergen

🥌

PlaidCat

jira VULN-209 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]>

JIRA: https://issues.redhat.com/browse/RHEL-73484 commit 71c6aa0 Author: Wen Gu <[email protected]> Date: Fri May 26 19:49:01 2023 +0800 net/smc: Don't use RMBs not mapped to new link in SMCRv2 ADD LINK We encountered a crash when using SMCRv2. It is caused by a logical error in smc_llc_fill_ext_v2(). BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 453 Comm: kworker/7:4 Kdump: loaded Tainted: G W E 6.4.0-rc3+ #44 Workqueue: events smc_llc_add_link_work [smc] RIP: 0010:smc_llc_fill_ext_v2+0x117/0x280 [smc] RSP: 0018:ffffacb5c064bd88 EFLAGS: 00010282 RAX: ffff9a6bc1c3c02c RBX: ffff9a6be3558000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 000000000000000a RBP: ffffacb5c064bdb8 R08: 0000000000000040 R09: 000000000000000c R10: ffff9a6bc0910300 R11: 0000000000000002 R12: 0000000000000000 R13: 0000000000000002 R14: ffff9a6bc1c3c02c R15: ffff9a6be3558250 FS: 0000000000000000(0000) GS:ffff9a6eefdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 000000010b078003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> smc_llc_send_add_link+0x1ae/0x2f0 [smc] smc_llc_srv_add_link+0x2c9/0x5a0 [smc] ? cc_mkenc+0x40/0x60 smc_llc_add_link_work+0xb8/0x140 [smc] process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> When an alernate RNIC is available in system, SMC will try to add a new link based on the RNIC for resilience. All the RMBs in use will be mapped to the new link. Then the RMBs' MRs corresponding to the new link will be filled into SMCRv2 LLC ADD LINK messages. However, smc_llc_fill_ext_v2() mistakenly accesses to unused RMBs which haven't been mapped to the new link and have no valid MRs, thus causing a crash. So this patch fixes the logic. Fixes: b4ba465 ("net/smc: extend LLC layer for SMC-Rv2") Signed-off-by: Wen Gu <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mete Durlu <[email protected]>

…() after confirm When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: <TASK> nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it. Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: 62e7151 ("netfilter: bridge: confirm multicast packets before passing them up the stack") Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Wang Liang <[email protected]> Signed-off-by: Florian Westphal <[email protected]>

…() after confirm [ Upstream commit 479a54a ] When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: <TASK> nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it. Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: 62e7151 ("netfilter: bridge: confirm multicast packets before passing them up the stack") Suggested-by: Florian Westphal <[email protected]> Signed-off-by: Wang Liang <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

PlaidCat requested review from gvrose8192, PlaidCat and bmastbergen January 9, 2025 16:29

gvrose8192 approved these changes Jan 9, 2025

View reviewed changes

bmastbergen approved these changes Jan 9, 2025

View reviewed changes

PlaidCat approved these changes Jan 10, 2025

View reviewed changes

PlaidCat changed the title ~~Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm~~ [LTS 9.2] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm Jan 15, 2025

pvts-mat force-pushed the ciqlts9_2-CVE-2022-42896 branch from 7232864 to ca581a4 Compare January 16, 2025 22:27

PlaidCat merged commit f08be21 into ctrliq:ciqlts9_2 Jan 21, 2025
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[LTS 9.2] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm #44

[LTS 9.2] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm #44

Uh oh!

pvts-mat commented Jan 9, 2025

Uh oh!

gvrose8192 left a comment

Uh oh!

bmastbergen left a comment

Uh oh!

PlaidCat left a comment

Uh oh!

Uh oh!

Uh oh!

[LTS 9.2] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm #44

[LTS 9.2] Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm #44

Uh oh!

Conversation

pvts-mat commented Jan 9, 2025

CVE-2022-42896, VULN-210

Solution

Build

kABI check: passed

Boot test: passed

Kselftests: passed

Additional tests: none

Uh oh!

gvrose8192 left a comment

Choose a reason for hiding this comment

Uh oh!

bmastbergen left a comment

Choose a reason for hiding this comment

Uh oh!

PlaidCat left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!