Lack of concern for security in BSP kernel

So it appears that Rockchip care about security in the BSP kernel we are all using approximately zilch.

To start with, I’ve found a trivially exploitable misfeature in the RGA driver that can be used to escalate privileges to system root even from inside a container, and another that would have allowed arbitrary memory read/write, except that the functionality was accidentally broken.

The default config sets CONFIG_DRM_IGNORE_IOTCL_PERMIT=y, which is a hack Rockchip implemented that allows any user to have complete control over display hardware, but the config option also breaks userspace such as wlroots-using Wayland compositors.

I have also found another RGA vulnerability that might allow kernel code execution, and kernel memory manipulation that seems like it could be used to gain out-of-bounds memory access in the NPU driver. There is a lot of questionable code all around; I haven’t looked at any other drivers, but I don’t expect them to be much better.

So my suggestion is that any users who you do not wish to effectively have root access should not be given access to /dev/dri/renderD129 or /dev/dri/card1 for the NPU, /dev/rga for RGA, and /dev/dri/* for any DRM device node if CONFIG_DRM_IGNORE_IOTCL_PERMIT=y. Probably there are more vulnerable drivers.

Though you may wish to consider: Is anyone really going to write exploits targeting Rockchip drivers, rather than, say, Qualcomm or Arm ones used in devices crackers actually care about? Probably the biggest threat would be distributions trying to sabotage each others’ build servers…


If we disable this configuration, how would it impact the drivers? Will it become totally unusable or still working but with quirks?


It shouldn’t affect properly-written userspace, and it’s unlikely to cause issues with distributions using logind. For other distributions, if a setup works with the mainline kernel, then it should still work with the config option disabled.

Disabling it is required to run wlroots-based Wayland compositors headless and/or with Xwayland support: wlroots uses drmIsMaster to check if it has control over the display, by using the AUTH_MAGIC ioctl. It should fail and return EPERM when it doesn’t, but with the config option enabled the kernel skips the check for being “master” and instead causes a kernel oops in drm_authmagic.

thanks for the awesome information.

Thanks. This is disabled in bsp which will be used to build kernel/U-Boot for our future images.

Rockchip SDK contains the following udev rule in their Debian overlay:

We included this file as well:

Hopefully with the above fix, we can still have the video working with Rockchip packages.