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.