can_rx_register callbacks may be called concurrently to the call to
can_rx_unregister. The callbacks and callback data, though, are protected by
RCU and the struct sock reference count.
So the callback data is really attached to the life of sk, meaning that it
should be released on sk_destruct. However, bcm_remove_op calls tasklet_kill,
and RCU callbacks may be called under RCU softirq, so that cannot be used on
kernels before the introduction of HRTIMER_MODE_SOFT.
However, bcm_rx_handler is called under RCU protection, so after calling
can_rx_unregister, we may call synchronize_rcu in order to wait for any RCU
read-side critical sections to finish. That is, bcm_rx_handler won't be called
anymore for those ops. So, we only free them, after we do that synchronize_rcu.
Reported-by: <email address hidden>
Reported-by: Norbert Slusarek <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Benjamin M Romer <email address hidden>
Acked-by: Ian May <email address hidden>
The backport of commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call
into vfs_setxattr()") did not consider that vfs_setxattr had other exit
paths that would require a converted value to be freed.
If xattr_permission returns a failure, it would cause a memory leak. In the
case of security.capability attribute, which is the only that can allocate
a new value, xattr_permission will return a failure in case of
HAS_UNMAPPED_ID(inode), which would already be caught by cap_convert_nscap,
at !capable_wrt_inode_uidgid(inode, CAP_SETFCAP).
However, if the file IS_IMMUTABLE or IS_APPEND, the failure will be
returned and the leak will happen.
Though setting a file as immutable or append is restricted to
CAP_FILE_IMMUTABLE, the leak was still shown to happen when trying to
setcap on an immutable file after doing a mount unshare.
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Krzysztof Kozlowski <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
