LG: Felica driver dangerous set_fs usage There are multiple weaknesses in the use of KERNEL_DS in the LG felica drivers, in /drivers/felica. See for example felica_i2c_open /* * Description : * Input : * Output : */ int felica_i2c_open (void) { mm_segment_t old_fs = get_fs(); FELICA_DEBUG_MSG_LOW("[FELICA_I2C] felica_i2c_open\n"); set_fs(KERNEL_DS); fd = sys_open(FELICA_IC2_NAME, O_RDWR|O_NONBLOCK, 0); FELICA_DEBUG_MSG_MED("[FELICA] cbal - sys_open fd : %d \n",fd); if (fd < 0) { FELICA_DEBUG_MSG_HIGH("[FELICA_I2C] ERROR - felica_i2c_open : %d \n", fd); return fd; } set_fs(old_fs); return 0; } This code is setting KERNEL_DS, and there is a code-path in which it does not restore USER_DS before returning; similarly to the other reported issue this can be exploited to gain read/write access to kernel memory. This should be triggerable from usermode by simply opening the maximum number of permitted open files (ulimit -Sn), then opening the felica i2c device. The call to sys_open will fail, triggering the error path and skipping the set_fs(old_fs) call. (Every use of set_fs(KERNEL_DS) in the felica code appears to handle error cases badly, failing to restore the original value). The fact that this trick works suggests another issue with this code. Calling sys_open from kernel code will insert the opened file descriptor into the fd table of the current process. This means that userland can tamper with this file descriptor while the kernel is expecting to be able to use it safely; dup'ing it to another fd, closing it, reopening another file in it's place. This makes it easy for userspace to cause errors at almost any place in the felica driver's read/write handlers. I haven't validated this issue on a device as it appears that the felica config options are only set in Japanese builds. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. Found by: markbrand