Hugo Villeneuve

The issue is related to a regression introduced by a commit that changed the EFR locking to operate on each channel instead of chip-wise. This regression causes the Tx buffer data on one channel to be corrupted with data from another channel when a packet is received on one channel at almost the same time as a packet is about to be transmitted on the other channel. The problem is due to the EFR lock being used not only to protect the EFR registers access but also to protect access to the shared data buffer. To fix this regression, the solution involves switching to kfifo out linear ptr() in sc16is7xx handle tx() to eliminate the need for a shared Rx/Tx buffer and replacing the chip-wise Rx buffer with a separate Rx buffer for each channel.

The issue arises when the last MAX3100 device is removed, triggering the removal of the driver. However, the code fails to update the respective global variable, leading to a kernel crash after an insmod — rmmod — insmod cycle. This results in a NULL pointer dereference. The error path in the probe is also affected by the variable not being cleared. To resolve this, the assignment should be moved after the successful `uart register driver()` call.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a NULL pointer dereference in the I2C instantiation of the max310x driver in the Linux kernel. When trying to instantiate a max14830 device from userspace using the command `echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new device`, a kernel NULL pointer dereference error occurs. The error is caused by the `max310x i2c probe` function and can be prevented by adding a check for the validity of the devtype. The `i2c device probe` function is also involved in the call trace. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.