Bugzilla – Bug 1223934
VUL-0: CVE-2022-48673: kernel: net/smc: Fix possible access to freed memory in link clear
Last modified: 2024-07-15 10:40:41 UTC
In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix possible access to freed memory in link clear After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context. Here is a crash example: BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20 References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48673 https://www.cve.org/CVERecord?id=CVE-2022-48673 https://git.kernel.org/stable/c/89fcb70f1acd6b0bbf2f7bfbf45d7aa75a9bdcde https://git.kernel.org/stable/c/e9b1a4f867ae9c1dbd1d71cd09cbdb3239fb4968 https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2022/CVE-2022-48673.mbox https://bugzilla.redhat.com/show_bug.cgi?id=2278938
I'll push it shorlty
Hi Thomas, can you sync this bug and help us fix it? Also it is a little unclear whether SMC is fully supported or not. Thank you, Marcela
Please punt it over to IBM. SMC is the guest-to-guest communication between zSeries guests (and the _only_ user of that), so IBM needs at least to be made aware. And actually we are rely on IBM to provide us backports for 'normal' fixes, so this might as well handled by them, too. Marcela, can you please contact IBM?
------- Comment From tstaudt@de.ibm.com 2024-07-15 06:34 EDT------- (In reply to comment #7) > Please punt it over to IBM. SMC is the guest-to-guest communication between > zSeries guests (and the _only_ user of that), so IBM needs at least to be > made aware. And actually we are rely on IBM to provide us backports for > 'normal' fixes, so this might as well handled by them, too. > Marcela, can you please contact IBM? Hello Hannes, we are aware - the bug has been mirrored, see the "See also:" link in the SUSE bug. Apologies for not replying externally - we are working on this.