Alexandra Winter

The issue is related to a memory leak in the Linux kernel, specifically in the s390/iucv component. When the MSG PEEK flag is passed to `skb recv datagram()`, it increments the `skb->users` refcount, but `iucv sock recvmsg()` does not decrement the refcount at exit. This results in a memory leak in `skb queue purge()` and a WARN ON in `iucv sock destruct()` during socket close. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited. Technical details about exploitation include: - The `MSG PEEK` flag is used in the `skb recv datagram()` function. - The `skb->users` refcount is incremented when the `MSG PEEK` flag is passed. - The `iucv sock recvmsg()` function does not decrement the `skb->users` refcount at exit. - The memory leak occurs in `skb queue purge()`. - A WARN ON is triggered in `iucv sock destruct()` during socket close.

The vulnerability is related to a use-after-free issue in the `iucv sock close()` function. The `iucv sever path()` function is called from both process context and bh context, and `iucv->path` is used as an indicator of whether someone else is taking care of severing the path. This needs to be done with atomic compare and swap to prevent a small window where `iucv sock close()` tries to work with a path that has already been severed and freed. The issue can lead to a kernel panic and potentially allow an attacker to impact the confidentiality, integrity, and availability of protected information.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.37 Description: The vulnerability is related to the s390/qeth component of the Linux kernel. When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL. This can cause a kernel panic. Technical details about exploitation include: - The `napi.poll` functions are set during `qeth open()`. - The `qeth set offline()`/`qeth set online()` functions no longer call `dev close()`/`dev open()` due to commit 1cfef80d4c2b ("s390/qeth: Don't call dev close/dev open (DOWN/UP)"). - If `qeth free qdio queues()` cleared `card->qdio.out qs[i].napi.poll` while the network interface was UP and the card was offline, they are not set again. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

The issue is related to a deadlock during failing recovery in the s390/qeth component of the Linux kernel. A commit removed the taking of `discipline mutex` inside `qeth do reset()`, fixing potential deadlocks. However, an error path was missed, which still takes `discipline mutex` and thus has the original deadlock potential. Intermittent deadlocks were seen when a qeth channel path is configured offline, causing a race between `qeth do reset` and `ccwgroup remove`. To fix this, `qeth set offline()` is called directly in the `qeth do reset()` error case, and a new variant of `ccwgroup set offline()` is used, without taking `discipline mutex`.