Well, here's one option. Since CVE-2010-3081 was about not checking access_ok() on the return value from (arch_)compat_alloc_user_space, we can add that check to KCL_IOCTL_AllocUserSpace32, use arch_compat_alloc_user_space, and side-step the GPL-only-ness of compat_alloc_user_space. It's not pretty, and could be dangerous if there are future security-related changes to the new compat_alloc_user_space.
This patch re-writes KCL_IOCTL_AllocUserSpace32 to use arch_compat_alloc_user_space and check access_ok(). Currently it will only compile on kernels with the CVE-2010-3081 patch; it would need to be tweaked to use compat_alloc_user_space if arch_compat_alloc_user_space isn't defined.
Well, here's one option. Since CVE-2010-3081 was about not checking access_ok() on the return value from (arch_) compat_ alloc_user_ space, we can add that check to KCL_IOCTL_ AllocUserSpace3 2, use arch_compat_ alloc_user_ space, and side-step the GPL-only-ness of compat_ alloc_user_ space. It's not pretty, and could be dangerous if there are future security-related changes to the new compat_ alloc_user_ space.
This patch re-writes KCL_IOCTL_ AllocUserSpace3 2 to use arch_compat_ alloc_user_ space and check access_ok(). Currently it will only compile on kernels with the CVE-2010-3081 patch; it would need to be tweaked to use compat_ alloc_user_ space if arch_compat_ alloc_user_ space isn't defined.