Message ID | 20200720124737.118617-3-hch@lst.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [01/24] bpfilter: reject kernel addresses | expand |
On Mon, Jul 20, 2020 at 02:47:15PM +0200, Christoph Hellwig wrote: > The __user doesn't make sense when casting to an integer type. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > net/bpfilter/bpfilter_kern.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c > index 977e9dad72ca4f..713b4b3d02005d 100644 > --- a/net/bpfilter/bpfilter_kern.c > +++ b/net/bpfilter/bpfilter_kern.c > @@ -49,7 +49,7 @@ static int __bpfilter_process_sockopt(struct sock *sk, int optname, > req.is_set = is_set; > req.pid = current->pid; > req.cmd = optname; > - req.addr = (long __force __user)optval; > + req.addr = (__force long)optval; For casts to integers, even '__force' is not needed (since integers can't be dereferenced, the concept of address-space is meaningless for them, so it's never useful to warn when it's dropped and '__force' is thus not needed). -- Luc
On Tue, Jul 21, 2020 at 04:40:16AM +0200, Luc Van Oostenryck wrote: > > req.pid = current->pid; > > req.cmd = optname; > > - req.addr = (long __force __user)optval; > > + req.addr = (__force long)optval; > > For casts to integers, even '__force' is not needed (since integers > can't be dereferenced, the concept of address-space is meaningless > for them, so it's never useful to warn when it's dropped and > '__force' is thus not needed). That's what I thought. but if I remove it here I actually do get a warning: CHECK net/bpfilter/bpfilter_kern.c net/bpfilter/bpfilter_kern.c:52:21: warning: cast removes address space '__user' of expression Using this recent sparse build: hch@brick:~/work/linux$ sparse --version v0.6.2-49-g707c5017
On Tue, Jul 21, 2020 at 07:23:26AM +0200, Christoph Hellwig wrote: > On Tue, Jul 21, 2020 at 04:40:16AM +0200, Luc Van Oostenryck wrote: > > > req.pid = current->pid; > > > req.cmd = optname; > > > - req.addr = (long __force __user)optval; > > > + req.addr = (__force long)optval; > > > > For casts to integers, even '__force' is not needed (since integers > > can't be dereferenced, the concept of address-space is meaningless > > for them, so it's never useful to warn when it's dropped and > > '__force' is thus not needed). > > That's what I thought. but if I remove it here I actually do get a > warning: > > CHECK net/bpfilter/bpfilter_kern.c > net/bpfilter/bpfilter_kern.c:52:21: warning: cast removes address space '__user' of expression Cast to unsigned long. Or to uintptr_t if you want to be fancy.
diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c index 977e9dad72ca4f..713b4b3d02005d 100644 --- a/net/bpfilter/bpfilter_kern.c +++ b/net/bpfilter/bpfilter_kern.c @@ -49,7 +49,7 @@ static int __bpfilter_process_sockopt(struct sock *sk, int optname, req.is_set = is_set; req.pid = current->pid; req.cmd = optname; - req.addr = (long __force __user)optval; + req.addr = (__force long)optval; req.len = optlen; if (!bpfilter_ops.info.tgid) goto out;
The __user doesn't make sense when casting to an integer type. Signed-off-by: Christoph Hellwig <hch@lst.de> --- net/bpfilter/bpfilter_kern.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)