| Message ID | 1371045747-15203-1-git-send-email-dborkman@redhat.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Daniel Borkmann <dborkman@redhat.com> Date: Wed, 12 Jun 2013 16:02:27 +0200 > uaddr->sa_data is exactly of size 14, which is hard-coded here and > passed as a size argument to strncpy(). A device name can be of size > IFNAMSIZ (== 16), meaning we might leave the destination string > unterminated. Thus, use strlcpy() and also sizeof() while we're > at it. We need to memset the data area beforehand, since strlcpy > does not padd the remaining buffer with zeroes for user space, so > that we do not possibly leak anything. > > Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Applied, and queued up for -stable, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2013-06-13 at 01:38 -0700, David Miller wrote: > From: Daniel Borkmann <dborkman@redhat.com> > Date: Wed, 12 Jun 2013 16:02:27 +0200 > > > uaddr->sa_data is exactly of size 14, which is hard-coded here and > > passed as a size argument to strncpy(). A device name can be of size > > IFNAMSIZ (== 16), meaning we might leave the destination string > > unterminated. Thus, use strlcpy() and also sizeof() while we're > > at it. We need to memset the data area beforehand, since strlcpy > > does not padd the remaining buffer with zeroes for user space, so > > that we do not possibly leak anything. > > > > Signed-off-by: Daniel Borkmann <dborkman@redhat.com> > > Applied, and queued up for -stable, thanks. I don't think this should be applied anywhere. Dropping support for 14-character device names is a regression. Ben.
On Thu, 2013-06-13 at 18:05 +0100, Ben Hutchings wrote: > On Thu, 2013-06-13 at 01:38 -0700, David Miller wrote: > > From: Daniel Borkmann <dborkman@redhat.com> > > Date: Wed, 12 Jun 2013 16:02:27 +0200 > > > > > uaddr->sa_data is exactly of size 14, which is hard-coded here and > > > passed as a size argument to strncpy(). A device name can be of size > > > IFNAMSIZ (== 16), meaning we might leave the destination string > > > unterminated. Thus, use strlcpy() and also sizeof() while we're > > > at it. We need to memset the data area beforehand, since strlcpy > > > does not padd the remaining buffer with zeroes for user space, so > > > that we do not possibly leak anything. > > > > > > Signed-off-by: Daniel Borkmann <dborkman@redhat.com> > > > > Applied, and queued up for -stable, thanks. > > I don't think this should be applied anywhere. Dropping support for > 14-character device names is a regression. ...not that this actually prevents binding to 14-character device names; it just means the name is then not reported back correctly. Whatever, it is a regression. The fact that a 14-character name is not null- terminated should be documented instead (I'm not sure where). Ben.
On 06/13/2013 07:05 PM, Ben Hutchings wrote: > On Thu, 2013-06-13 at 01:38 -0700, David Miller wrote: >> From: Daniel Borkmann <dborkman@redhat.com> >> Date: Wed, 12 Jun 2013 16:02:27 +0200 >> >>> uaddr->sa_data is exactly of size 14, which is hard-coded here and >>> passed as a size argument to strncpy(). A device name can be of size >>> IFNAMSIZ (== 16), meaning we might leave the destination string >>> unterminated. Thus, use strlcpy() and also sizeof() while we're >>> at it. We need to memset the data area beforehand, since strlcpy >>> does not padd the remaining buffer with zeroes for user space, so >>> that we do not possibly leak anything. >>> >>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> >> >> Applied, and queued up for -stable, thanks. > > I don't think this should be applied anywhere. Dropping support for > 14-character device names is a regression. I don't think this would be reasonable, because it can pose a security risk for user space. In all other cases, we null-terminate the string, so people might trust what they get from the kernel and expect this to happen except in this particular border case. I agree that this is pretty broken, but I would say it's a bug in the kernel that can potentially cause user space to crash (or worse) that is making use of this. There also seems to be no man page documentation about it, only that spkt is heavily deprecated from what I read, and shouldn't be used nowadays. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2013-06-13 at 22:02 +0200, Daniel Borkmann wrote: > On 06/13/2013 07:05 PM, Ben Hutchings wrote: > > On Thu, 2013-06-13 at 01:38 -0700, David Miller wrote: > >> From: Daniel Borkmann <dborkman@redhat.com> > >> Date: Wed, 12 Jun 2013 16:02:27 +0200 > >> > >>> uaddr->sa_data is exactly of size 14, which is hard-coded here and > >>> passed as a size argument to strncpy(). A device name can be of size > >>> IFNAMSIZ (== 16), meaning we might leave the destination string > >>> unterminated. Thus, use strlcpy() and also sizeof() while we're > >>> at it. We need to memset the data area beforehand, since strlcpy > >>> does not padd the remaining buffer with zeroes for user space, so > >>> that we do not possibly leak anything. > >>> > >>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> > >> > >> Applied, and queued up for -stable, thanks. > > > > I don't think this should be applied anywhere. Dropping support for > > 14-character device names is a regression. > > I don't think this would be reasonable, because it can pose a security > risk for user space. In all other cases, we null-terminate the string, so > people might trust what they get from the kernel and expect this to happen > except in this particular border case. It seems to have been this way forever, so any userland programs already using the API should be aware of this oddity. > I agree that this is pretty broken, but I would say it's a bug in the kernel > that can potentially cause user space to crash (or worse) that is making use > of this. It's a bug in the API but you're about 15 years too late to fix that. > There also seems to be no man page documentation about it, only that > spkt is heavily deprecated from what I read, and shouldn't be used nowadays. So leave well alone! Ben.
On 06/13/2013 10:47 PM, Ben Hutchings wrote: > On Thu, 2013-06-13 at 22:02 +0200, Daniel Borkmann wrote: >> On 06/13/2013 07:05 PM, Ben Hutchings wrote: >>> On Thu, 2013-06-13 at 01:38 -0700, David Miller wrote: >>>> From: Daniel Borkmann <dborkman@redhat.com> >>>> Date: Wed, 12 Jun 2013 16:02:27 +0200 >>>> >>>>> uaddr->sa_data is exactly of size 14, which is hard-coded here and >>>>> passed as a size argument to strncpy(). A device name can be of size >>>>> IFNAMSIZ (== 16), meaning we might leave the destination string >>>>> unterminated. Thus, use strlcpy() and also sizeof() while we're >>>>> at it. We need to memset the data area beforehand, since strlcpy >>>>> does not padd the remaining buffer with zeroes for user space, so >>>>> that we do not possibly leak anything. >>>>> >>>>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> >>>> >>>> Applied, and queued up for -stable, thanks. >>> >>> I don't think this should be applied anywhere. Dropping support for >>> 14-character device names is a regression. >> >> I don't think this would be reasonable, because it can pose a security >> risk for user space. In all other cases, we null-terminate the string, so >> people might trust what they get from the kernel and expect this to happen >> except in this particular border case. > > It seems to have been this way forever, so any userland programs already > using the API should be aware of this oddity. Since it seems nowhere documented, that's quite an assumption, right? ;-) E.g., having seen a fair amount proprietary C code before, I would well believe that people ignore checking/caring for such an oddity in the API ... >> I agree that this is pretty broken, but I would say it's a bug in the kernel >> that can potentially cause user space to crash (or worse) that is making use >> of this. > > It's a bug in the API but you're about 15 years too late to fix that. Very well, then it would probably also not break much to have this fixed in the kernel as is. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 8ec1bca..20a1bd0 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -2851,12 +2851,11 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr, return -EOPNOTSUPP; uaddr->sa_family = AF_PACKET; + memset(uaddr->sa_data, 0, sizeof(uaddr->sa_data)); rcu_read_lock(); dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex); if (dev) - strncpy(uaddr->sa_data, dev->name, 14); - else - memset(uaddr->sa_data, 0, 14); + strlcpy(uaddr->sa_data, dev->name, sizeof(uaddr->sa_data)); rcu_read_unlock(); *uaddr_len = sizeof(*uaddr);
uaddr->sa_data is exactly of size 14, which is hard-coded here and passed as a size argument to strncpy(). A device name can be of size IFNAMSIZ (== 16), meaning we might leave the destination string unterminated. Thus, use strlcpy() and also sizeof() while we're at it. We need to memset the data area beforehand, since strlcpy does not padd the remaining buffer with zeroes for user space, so that we do not possibly leak anything. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> --- net/packet/af_packet.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)