Frederick Lawler <fred@xxxxxxxxxxxxxx> writes: > While experimenting with the security_prepare_creds() LSM hook, we > noticed that our EPERM error code was not propagated up the callstack. > Instead ENOMEM is always returned. As a result, some tools may send a > confusing error message to the user: > > $ unshare -rU > unshare: unshare failed: Cannot allocate memory > > A user would think that the system didn't have enough memory, when > instead the action was denied. > > This problem occurs because prepare_creds() and prepare_kernel_cred() > return NULL when security_prepare_creds() returns an error code. Later, > functions calling prepare_creds() and prepare_kernel_cred() return > ENOMEM because they assume that a NULL meant there was no memory > allocated. > > Fix this by propagating an error code from security_prepare_creds() up > the callstack. > > Signed-off-by: Frederick Lawler <fred@xxxxxxxxxxxxxx> The fs/aio.c part looks ok to me. We should probably also update the man page for io_submit, though, to document the conditions under which EPERM can be returned. Acked-by: Jeff Moyer <jmoyer@xxxxxxxxxx> -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
