{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-26877", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-26877" ], "published": "2024-04-17T10:29:01Z", "summary": "crypto: xilinx - call finalize with bh disabled", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: xilinx - call finalize with bh disabled\n\nWhen calling crypto_finalize_request, BH should be disabled to avoid\ntriggering the following calltrace:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118\n Modules linked in: cryptodev(O)\n CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323\n Hardware name: ZynqMP ZCU102 Rev1.0 (DT)\n pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : crypto_finalize_request+0xa0/0x118\n lr : crypto_finalize_request+0x104/0x118\n sp : ffffffc085353ce0\n x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688\n x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00\n x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000\n x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0\n x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8\n x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001\n x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000\n x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000\n Call trace:\n crypto_finalize_request+0xa0/0x118\n crypto_finalize_aead_request+0x18/0x30\n zynqmp_handle_aes_req+0xcc/0x388\n crypto_pump_work+0x168/0x2d8\n kthread_worker_fn+0xfc/0x3a0\n kthread+0x118/0x138\n ret_from_fork+0x10/0x20\n irq event stamp: 40\n hardirqs last enabled at (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0\n hardirqs last disabled at (40): [] el1_dbg+0x28/0x90\n softirqs last enabled at (36): [] kernel_neon_begin+0x8c/0xf0\n softirqs last disabled at (34): [] kernel_neon_begin+0x60/0xf0\n ---[ end trace 0000000000000000 ]---", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-26877" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8a01335aedc50a66d04dd39203c89f4bc8042596" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/03e6d4e948432a61b35783323b6ab2be071d2619" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a71f66bd5f7b9b35a8aaa49e29565eca66299399" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/23bc89fdce71124cd2126fc919c7076e7cb489cf" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9db89b1fb85557892e6681724b367287de5f9f20" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dbf291d8ffffb70f48286176a15c6c54f0bb0743" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a853450bf4c752e664abab0b2fad395b7ad7701c" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 9.8, "cvss_v3_severity": "Critical", "scenario": "AV:N - The impactful instance of this bug is driven by remote traffic: inbound ESP packets to a ZynqMP IPsec endpoint reach `esp_input()` \u2192 async `gcm(aes)` on this engine \u2192 `esp_input_done()` running in the wrong context, which is exactly the \"iperf over ipsec\" scenario that motivated the `lockdep_assert_in_softirq()` check. Other remote consumers of `gcm(aes)` on the same driver (kTLS, ksmbd/SMB3 encryption) reach the same finalize path.\nAC:L - The BH-enabled completion happens on 100% of requests with no preconditions, and the attacker supplies both sides of the resulting race by simply sustaining packet flow \u2014 the racing NET_RX softirq is generated by the attacker's own traffic, and the preemptible/migratable kthread widens the window arbitrarily.\nPR:N - A remote peer needs no account or credential on the target; sending ESP packets that match an existing inbound SA queues the asynchronous decrypt, and the completion callback runs in the bad context regardless of whether the ICV ultimately validates.\nUI:N - No victim action is required \u2014 the crypto request is submitted and finalized automatically by the network stack as packets arrive.\nS:U - The context violation, the corrupted lists, the deadlock, and the crash are all confined to the kernel's own security authority; no hypervisor, IOMMU, or sandbox boundary is crossed.\nC:H - `xfrm_input()` calls `gro_cells_receive()` unguarded, whose unlocked per-CPU `napi_skbs` list can be corrupted by a concurrent same-CPU `gro_cell_poll()`, yielding use-after-free reads of freed `sk_buff` slab memory that an attacker who reclaims the object can read back; the accompanying WARN also dumps full register and stack state to dmesg.\nI:H - The same unsynchronized `__skb_queue_tail`/`__skb_dequeue` interleaving leaves dangling `next`/`prev` pointers and lets one skb be dequeued and freed twice, giving a double-free/UAF write primitive over reclaimed heap objects; per-CPU `__this_cpu_inc` MIB state and the xfrm replay window are likewise updated without the atomicity they assume.\nA:H - Taking `x->lock` with plain `spin_lock()` from a BH-enabled kthread while softirq paths take it with `spin_lock_bh()` produces same-CPU spinlock recursion \u2014 the exact deadlock/hard lockup the assert was added to catch \u2014 plus a `WARN_ON_ONCE` splat that panics outright on `panic_on_warn` kernels, and skb list corruption that oopses the machine." } } }