CVE-2023-53746

What it actually does

The vfio_ap device release callback uses dev_get_drvdata to retrieve the vfio_matrix_dev pointer for kfree but the object is not stored as drvdata, so kfree receives NULL and the allocation is never released; container_of should be used instead since the device is embedded in the object.

Why it matters to the business

On s390 systems using vfio-ap, repeated device release operations cause gradual memory exhaustion that can degrade or interrupt virtualization and device-passthrough workloads; the listed dcmtk packages on multiple Ubuntu releases require patching despite the kernel nature of the flaw.

How an attack unfolds

An attacker triggers repeated attach and release cycles against vfio-ap matrix devices on s390 hardware; each release path calls the buggy callback, leaking a vfio_matrix_dev object because dev_get_drvdata returns NULL, allowing slow accumulation of unreclaimed kernel memory.

How to fix it

Apply the vendor-supplied updates for the listed packages: dcmtk on Ubuntu Pro 16.04 to 3.6.1~20150924-5ubuntu0.1~esm1, on Ubuntu Pro 18.04 to 3.6.2-3ubuntu0.1~esm1, on Ubuntu 20.04 to 3.6.4-2.1ubuntu0.1, on Ubuntu Pro 20.04 to 3.6.4-2.1ubuntu0.1~esm1, and on Ubuntu Pro 22.04 to 3.6.6-5ubuntu0.1~esm1; rebuild or reboot as required by the distribution.

How to confirm the fix worked

After patching, confirm the updated package versions are installed and verify that the release callback source now uses container_of to obtain the vfio_matrix_dev pointer before freeing.

Typical attack path

1. Gain local access or control of a process that can manipulate vfio-ap devices
2. Repeatedly create and release matrix devices to invoke the release callback
3. Observe steadily increasing kernel memory usage without corresponding process termination

How to detect it

Review kernel logs and slab allocator statistics for repeated allocations of vfio_matrix_dev objects without matching frees; correlate with vfio-ap device attach/detach events.

What your security team should do

• Prioritize patching all affected Ubuntu dcmtk packages within the CISA-style timelines if any internal KEV-like policy applies
• Audit s390 systems for vfio-ap usage and schedule kernel/driver updates
• Monitor memory usage trends on virtualization hosts until patches are deployed