{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-26957", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-26957" ], "published": "2024-05-01T05:22:01Z", "summary": "s390/zcrypt: fix reference counting on zcrypt card objects", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/zcrypt: fix reference counting on zcrypt card objects\n\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\n\nThis is an example of the slab message:\n\n kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n kernel: kmalloc_trace+0x3f2/0x470\n kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt]\n kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n kernel: ap_device_probe+0x15c/0x290\n kernel: really_probe+0xd2/0x468\n kernel: driver_probe_device+0x40/0xf0\n kernel: __device_attach_driver+0xc0/0x140\n kernel: bus_for_each_drv+0x8c/0xd0\n kernel: __device_attach+0x114/0x198\n kernel: bus_probe_device+0xb4/0xc8\n kernel: device_add+0x4d2/0x6e0\n kernel: ap_scan_adapter+0x3d0/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n kernel: kfree+0x37e/0x418\n kernel: zcrypt_card_put+0x54/0x80 [zcrypt]\n kernel: ap_device_remove+0x4c/0xe0\n kernel: device_release_driver_internal+0x1c4/0x270\n kernel: bus_remove_device+0x100/0x188\n kernel: device_del+0x164/0x3c0\n kernel: device_unregister+0x30/0x90\n kernel: ap_scan_adapter+0xc8/0x7c0\n kernel: ap_scan_bus+0x5a/0x3b0\n kernel: ap_scan_bus_wq_callback+0x40/0x60\n kernel: process_one_work+0x26e/0x620\n kernel: worker_thread+0x21c/0x440\n kernel: kthread+0x150/0x168\n kernel: __ret_from_fork+0x3c/0x58\n kernel: ret_from_fork+0xa/0x30\n kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........\n kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk\n kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk.\n kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........\n kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ\n kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n kernel: Call Trace:\n kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120\n kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140\n kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8\n kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8\n kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0\n kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8\n kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8\n kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590\n kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0\n kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0\n kernel: \n---truncated---", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/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.84", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-26957" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c" } ], "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": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerability is reached through ioctls on the `/dev/z90crypt` misc device (ICARSAMODEXPO, ICARSACRT, ZSECSENDCPRB, ZSENDEP11CPRB), requiring local access to the s390 guest/LPAR. There is no network-facing consumer of `zcrypt_pick_queue()`.\nAC:L - The attacker fully controls the vulnerable window \u2014 `wait_for_completion_interruptible()` has no timeout, so unlimited threads park inside the pick/drop region indefinitely \u2014 and can synchronously force the removal-processing side via the `-ENODEV` retry path, which calls `ap_bus_force_rescan()` \u2192 `ap_scan_bus()` in the caller's own context. Queue teardown wakes the parked waiters with `-EAGAIN` just before the card `kfree()`, so no narrow timing window has to be won.\nPR:L - `zcrypt_unlocked_ioctl()` contains no `capable()` or `CAP_*` check; the only gate is `zcrypt_check_ioctl()` against `ap_perms`, which `ap_perms_init()` fills with 0xFF (all ioctls, all cards, all queues permitted) by default. The device node is world-accessible by design so unprivileged crypto libraries can use the adapters, so any local unprivileged user qualifies.\nUI:N - No victim action is needed \u2014 the attacker's own ioctl loop holds the stale pointer, and the attacker forces the AP bus rescan themselves via the `-ENODEV` retry path. Adapter deconfiguration is a system/hardware event, not a required user interaction.\nS:U - The use-after-free corrupts kernel slab memory within the same kernel security authority; there is no crossing of a guest/host, IOMMU, or sandbox boundary.\nC:H - Use-after-free on the freed `zcrypt_card` includes genuine reads of freed memory \u2014 `zq->zcard->max_mod_size` selects the CRB message format and `zq->zcard->max_exp_bit_length` gates the retry path \u2014 so reclaimed heap contents leak into attacker-observable behavior, and a reclaimed kmalloc-96 slot yields a general read primitive.\nI:H - The bug provides UAF writes into freed memory at known offsets: a 32-bit atomic decrement at offset 88 (`zc->load`) and a 32-bit store of 17 at offset 72 (`max_exp_bit_length`). With heap grooming of the shared kmalloc-96 cache, these controlled-offset writes into an attacker-reclaimed object are escalatable to arbitrary write and control-flow hijack.\nA:H - The reported symptom is slab poison corruption on a freed object; writing into a reclaimed kmalloc-96 slot reliably corrupts unrelated kernel structures and produces oopses or panics (immediate BUG under SLUB_DEBUG/KASAN), and the attacker can repeat it at will." } } }