Preface: In fact, when the details of a vulnerability were announced. It’s hard to guess when it first happened. This is a well-known fact in the cybersecurity community. However, security analysts and researchers don’t mind the delay. Since the goal is to fix the problem and avoid a similar vulnerability in another product.
For example, the details of the fix for this vulnerability were released on February 18, 2022. But details of the vulnerability just revealed this week.
Background: Currently, there are three technologies that support RDMA: InfiniBand, Ethernet RoCE and Ethernet iWARP. All three technologies share a common user API which is defined in this docu- ment, but have different physical and link layers.
InfiniBand (IB) is a computer network communication standard for high-performance computing with extremely high throughput and low latency. Six of the top ten high-performance computing (HPC) and artificial intelligence (AI) supercomputers on June 2019 TOP500 list. They deployed infiniBand technology.
Vulnerability details: CVE-2022-29156 – drivers/infiniband/ulp/rtrs/rtrs-clt[.]c in the Linux kernel before 5.16.12 has a double free related to rtrs_clt_dev_release.
Traditionally, the kfree( ) function is generally paired with the kmalloc( ) function to free a section of memory starting at address objp.
What is objp? The memory address, usually the return value of the kmalloc( ) function, that is, the address pointer to the starting address of the allocated memory block.
In practice, double-freeing a block of memory will corrupt the state of the memory manager, which might cause existing blocks of memory to get corrupted or for future allocations to fail in bizarre ways (for example, the same memory getting handed out on two different successive calls of malloc). Double frees can happen in all sorts of cases.
- kmalloc() can be called only in kernel-space
- malloc() can be called in user-space and kernel-space
Reason (Official announcement): Callback function rtrs_clt_dev_release() for put_device() calls kfree(clt) to free memory. We shouldn’t call kfree(clt) again, and we can’t use the clt after kfree too.
Solution: Replace device_register() with device_initialize() and device_add() so that dev_set_name can() be used appropriately. Move mutex_destroy() to the release function so it can be called in the alloc_clt err path.
Do mutexes need to be destroyed? Implementations are required to allow an object to be destroyed and freed and potentially unmapped immediately after the object is unlocked.
Below version of rtrs-clt[.]c was fixed this vulnerability.
v5.18-rc2 v5.18-rc1 v5.17 v5.17-rc8 v5.17-rc7 v5.17-rc6