* Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
From: H. Peter Anvin @ 2012-08-15 20:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stanislav Kinsbursky, tglx, mingo, davem, thierry.reding, bfields,
eric.dumazet, xemul, neilb, netdev, x86, linux-kernel,
paul.gortmaker, viro, gorcunov, akpm, tim.c.chen, devel
In-Reply-To: <87a9xwc4vr.fsf@xmission.com>
On 08/15/2012 12:49 PM, Eric W. Biederman wrote:
>
> There is also the trick of getting a shorter directory name using
> /proc/self/fd if you are threaded and can't change the directory.
>
> The obvious choices at this point are
> - Teach bind and connect and af_unix sockets to take longer AF_UNIX
> socket path names.
>
> - introduce sockaddr_fd that can be applied to AF_UNIX sockets,
> and teach unix_bind and unix_connect how to deal with a second type of sockaddr.
> struct sockaddr_fd { short fd_family; short pad; int fd; };
>
> - introduce sockaddr_unix_at that takes a directory file descriptor
> as well as a unix path, and teach unix_bind and unix_connect to deal with a
> second sockaddr type.
> struct sockaddr_unix_at { short family; short pad; int dfd; char path[102]; }
> AF_UNIX_AT
>
> I don't know what the implications of for breaking connect up into 3
> system calls and changing the semantics are and I would really rather
> not have to think about it.
>
> But it certainly does not look to me like you introduce new systems
> calls to do what you want.
>
How would you distinguish the new sockaddr types from the traditional
one? New AF_?
-hpa
^ permalink raw reply
* Re: regression with poll(2)?
From: Sage Weil @ 2012-08-15 21:03 UTC (permalink / raw)
To: Atchley, Scott
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ceph-devel@vger.kernel.org
In-Reply-To: <43EC24BD-D7FF-4611-9D88-DF9C496A620A@ornl.gov>
On Wed, 15 Aug 2012, Atchley, Scott wrote:
> On Aug 15, 2012, at 3:46 PM, Sage Weil wrote:
>
> > I'm experiencing a stall with Ceph daemons communicating over TCP that
> > occurs reliably with 3.6-rc1 (and linus/master) but not 3.5. The basic
> > situation is:
> >
> > - the socket is two processes communicating over TCP on the same host, e.g.
> >
> > tcp 0 2164849 10.214.132.38:6801 10.214.132.38:51729 ESTABLISHED
> >
> > - one end writes a bunch of data in
> > - the other end consumes data, but at some point stalls.
> > - reads are nonblocking, e.g.
> >
> > int got = ::recv( sd, buf, len, MSG_DONTWAIT );
> >
> > and between those calls we wait with
> >
> > struct pollfd pfd;
> > short evmask;
> > pfd.fd = sd;
> > pfd.events = POLLIN;
> > #if defined(__linux__)
> > pfd.events |= POLLRDHUP;
> > #endif
> >
> > if (poll(&pfd, 1, msgr->timeout) <= 0)
> > return -1;
> >
> > - in my case the timeout is ~15 minutes. at that point it errors out,
> > and the daemons reconnect and continue for a while until hitting this
> > again.
> >
> > - at the time of the stall, the reading process is blocked on that
> > poll(2) call. There are a bunch of threads stuck on poll(2), some of them
> > stuck and some not, but they all have stacks like
> >
> > [<ffffffff8118f6f9>] poll_schedule_timeout+0x49/0x70
> > [<ffffffff81190baf>] do_sys_poll+0x35f/0x4c0
> > [<ffffffff81190deb>] sys_poll+0x6b/0x100
> > [<ffffffff8163d369>] system_call_fastpath+0x16/0x1b
> >
> > - you'll note that the netstat output shows data queued:
> >
> > tcp 0 1163264 10.214.132.36:6807 10.214.132.36:41738 ESTABLISHED
> > tcp 0 1622016 10.214.132.36:41738 10.214.132.36:6807 ESTABLISHED
> >
> > etc.
> >
> > Is this a known regression? Or might I be misusing the API? What
> > information would help track it down?
> >
> > Thanks!
> > sage
>
>
> Sage,
>
> Do you see the same behavior when using two hosts (i.e. not loopback)? If different, how much data is in the pipe in the localhost case?
I have only seen it in the loopback case, and have independently diagnosed
it a half dozen or so times now.
:/
sage
>
> Scott
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [patch net-next] sctp: add function parameter names to fix compile error
From: David Miller @ 2012-08-15 21:07 UTC (permalink / raw)
To: jiri; +Cc: netdev, ebiederm
In-Reply-To: <1345028427-22092-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 15 Aug 2012 13:00:27 +0200
> Commit 13d782f6 introduced this problem.
>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I already integrated a patch to fix this, thanks.
^ permalink raw reply
* Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
From: Eric W. Biederman @ 2012-08-15 21:25 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Stanislav Kinsbursky, tglx, mingo, davem, thierry.reding, bfields,
eric.dumazet, xemul, neilb, netdev, x86, linux-kernel,
paul.gortmaker, viro, gorcunov, akpm, tim.c.chen, devel
In-Reply-To: <502C0D7C.2040707@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> On 08/15/2012 12:49 PM, Eric W. Biederman wrote:
>>
>> There is also the trick of getting a shorter directory name using
>> /proc/self/fd if you are threaded and can't change the directory.
>>
>> The obvious choices at this point are
>> - Teach bind and connect and af_unix sockets to take longer AF_UNIX
>> socket path names.
>>
>> - introduce sockaddr_fd that can be applied to AF_UNIX sockets,
>> and teach unix_bind and unix_connect how to deal with a second type of sockaddr.
>> struct sockaddr_fd { short fd_family; short pad; int fd; };
>>
>> - introduce sockaddr_unix_at that takes a directory file descriptor
>> as well as a unix path, and teach unix_bind and unix_connect to deal with a
>> second sockaddr type.
>> struct sockaddr_unix_at { short family; short pad; int dfd; char path[102]; }
>> AF_UNIX_AT
>>
>> I don't know what the implications of for breaking connect up into 3
>> system calls and changing the semantics are and I would really rather
>> not have to think about it.
>>
>> But it certainly does not look to me like you introduce new systems
>> calls to do what you want.
>>
>
> How would you distinguish the new sockaddr types from the traditional
> one? New AF_?
Yeah. AF_FD or AF_UNIX_AT is what I was thinking. The way the code
falls out that should be compartively simple to implement.
recvmsg etc would give you sockaddr_un sockets when they come from the
kernel.
Eric
^ permalink raw reply
* [PATCH 00/14] net: info leaks and other bugs
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Mathias Krause
Hi David,
this series fixes quite a bunch of info leaks under net/. There is also
one NULL pointer deref fix ("dccp: check ccid before..") that could be
abused for privilege escalation.
The info leak fixes might be material for stable, too. But I leave the
decision up to you.
On request, test code for all (but one) of the issues can be provided.
Regards,
Mathias
Mathias Krause (14):
atm: fix info leak in getsockopt(SO_ATMPVC)
atm: fix info leak via getsockname()
Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
Bluetooth: HCI - Fix info leak via getsockname()
Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)
Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)
Bluetooth: RFCOMM - Fix info leak via getsockname()
Bluetooth: L2CAP - Fix info leak via getsockname()
l2tp: fix info leak via getsockname()
llc: fix info leak via getsockname()
dccp: check ccid before dereferencing
dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)
ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)
net: fix info leak in compat dev_ifconf()
net/atm/common.c | 1 +
net/atm/pvc.c | 1 +
net/bluetooth/hci_sock.c | 2 ++
net/bluetooth/l2cap_sock.c | 1 +
net/bluetooth/rfcomm/sock.c | 2 ++
net/bluetooth/rfcomm/tty.c | 2 +-
net/dccp/ccid.h | 4 ++--
net/dccp/ccids/ccid3.c | 1 +
net/l2tp/l2tp_ip6.c | 1 +
net/llc/af_llc.c | 3 +--
net/netfilter/ipvs/ip_vs_ctl.c | 1 +
net/socket.c | 1 +
12 files changed, 15 insertions(+), 5 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 01/14] atm: fix info leak in getsockopt(SO_ATMPVC)
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Mathias Krause
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The ATM code fails to initialize the two padding bytes of struct
sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
before filling the structure to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
net/atm/common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/atm/common.c b/net/atm/common.c
index b4b44db..0c0ad93 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -812,6 +812,7 @@ int vcc_getsockopt(struct socket *sock, int level, int optname,
if (!vcc->dev || !test_bit(ATM_VF_ADDR, &vcc->flags))
return -ENOTCONN;
+ memset(&pvc, 0, sizeof(pvc));
pvc.sap_family = AF_ATMPVC;
pvc.sap_addr.itf = vcc->dev->number;
pvc.sap_addr.vpi = vcc->vpi;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/14] atm: fix info leak via getsockname()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Mathias Krause
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The ATM code fails to initialize the two padding bytes of struct
sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
before filling the structure to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
net/atm/pvc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/atm/pvc.c b/net/atm/pvc.c
index 3a73491..ae03240 100644
--- a/net/atm/pvc.c
+++ b/net/atm/pvc.c
@@ -95,6 +95,7 @@ static int pvc_getname(struct socket *sock, struct sockaddr *sockaddr,
return -ENOTCONN;
*sockaddr_len = sizeof(struct sockaddr_atmpvc);
addr = (struct sockaddr_atmpvc *)sockaddr;
+ memset(addr, 0, sizeof(*addr));
addr->sap_family = AF_ATMPVC;
addr->sap_addr.itf = vcc->dev->number;
addr->sap_addr.vpi = vcc->vpi;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/14] Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The HCI code fails to initialize the two padding bytes of struct
hci_ufilter before copying it to userland -- that for leaking two
bytes kernel stack. Add an explicit memset(0) before filling the
structure to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/hci_sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index a7f04de..a27bbc3 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -1009,6 +1009,7 @@ static int hci_sock_getsockopt(struct socket *sock, int level, int optname,
{
struct hci_filter *f = &hci_pi(sk)->filter;
+ memset(&uf, 0, sizeof(uf));
uf.type_mask = f->type_mask;
uf.opcode = f->opcode;
uf.event_mask[0] = *((u32 *) f->event_mask + 0);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/14] Bluetooth: HCI - Fix info leak via getsockname()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The HCI code fails to initialize the hci_channel member of struct
sockaddr_hci and that for leaks two bytes kernel stack via the
getsockname() syscall. Initialize hci_channel with 0 to avoid the
info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/hci_sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index a27bbc3..19fdac7 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -694,6 +694,7 @@ static int hci_sock_getname(struct socket *sock, struct sockaddr *addr,
*addr_len = sizeof(*haddr);
haddr->hci_family = AF_BLUETOOTH;
haddr->hci_dev = hdev->id;
+ haddr->hci_channel= 0;
release_sock(sk);
return 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/14] Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The RFCOMM code fails to initialize the key_size member of struct
bt_security before copying it to userland -- that for leaking one
byte kernel stack. Initialize key_size with 0 to avoid the info
leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/rfcomm/sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 7e1e596..64f55ca 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -822,6 +822,7 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
}
sec.level = rfcomm_pi(sk)->sec_level;
+ sec.key_size = 0;
len = min_t(unsigned int, len, sizeof(sec));
if (copy_to_user(optval, (char *) &sec, len))
--
1.7.10.4
^ permalink raw reply related
* [PATCH 06/14] Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The RFCOMM code fails to initialize the two padding bytes of struct
rfcomm_dev_list_req inserted for alignment before copying it to
userland. Additionally there are two padding bytes in each instance of
struct rfcomm_dev_info. The ioctl() that for disclosures two bytes plus
dev_num times two bytes uninitialized kernel heap memory.
Allocate the memory using kzalloc() to fix this issue.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/rfcomm/tty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index cb96077..56f1823 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -456,7 +456,7 @@ static int rfcomm_get_dev_list(void __user *arg)
size = sizeof(*dl) + dev_num * sizeof(*di);
- dl = kmalloc(size, GFP_KERNEL);
+ dl = kzalloc(size, GFP_KERNEL);
if (!dl)
return -ENOMEM;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 07/14] Bluetooth: RFCOMM - Fix info leak via getsockname()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The RFCOMM code fails to initialize the trailing padding byte of struct
sockaddr_rc added for alignment. It that for leaks one byte kernel stack
via the getsockname() syscall. Add an explicit memset(0) before filling
the structure to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/rfcomm/sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 64f55ca..1a17850 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -528,6 +528,7 @@ static int rfcomm_sock_getname(struct socket *sock, struct sockaddr *addr, int *
BT_DBG("sock %p, sk %p", sock, sk);
+ memset(sa, 0, sizeof(*sa));
sa->rc_family = AF_BLUETOOTH;
sa->rc_channel = rfcomm_pi(sk)->channel;
if (peer)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/14] l2tp: fix info leak via getsockname()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Mathias Krause, James Chapman
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The L2TP code for IPv6 fails to initialize the l2tp_unused member of
struct sockaddr_l2tpip6 and that for leaks two bytes kernel stack via
the getsockname() syscall. Initialize l2tp_unused with 0 to avoid the
info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: James Chapman <jchapman@katalix.com>
---
net/l2tp/l2tp_ip6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index 35e1e4b..9275471 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -410,6 +410,7 @@ static int l2tp_ip6_getname(struct socket *sock, struct sockaddr *uaddr,
lsa->l2tp_family = AF_INET6;
lsa->l2tp_flowinfo = 0;
lsa->l2tp_scope_id = 0;
+ lsa->l2tp_unused = 0;
if (peer) {
if (!lsk->peer_conn_id)
return -ENOTCONN;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 10/14] llc: fix info leak via getsockname()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Arnaldo Carvalho de Melo
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The LLC code wrongly returns 0, i.e. "success", when the socket is
zapped. Together with the uninitialized uaddrlen pointer argument from
sys_getsockname this leads to an arbitrary memory leak of up to 128
bytes kernel stack via the getsockname() syscall.
Return an error instead when the socket is zapped to prevent the info
leak. Also remove the unnecessary memset(0). We don't directly write to
the memory pointed by uaddr but memcpy() a local structure at the end of
the function that is properly initialized.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
---
net/llc/af_llc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index f6fe4d4..526f454 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -969,14 +969,13 @@ static int llc_ui_getname(struct socket *sock, struct sockaddr *uaddr,
struct sockaddr_llc sllc;
struct sock *sk = sock->sk;
struct llc_sock *llc = llc_sk(sk);
- int rc = 0;
+ int rc = -EBADF;
memset(&sllc, 0, sizeof(sllc));
lock_sock(sk);
if (sock_flag(sk, SOCK_ZAPPED))
goto out;
*uaddrlen = sizeof(sllc);
- memset(uaddr, 0, *uaddrlen);
if (peer) {
rc = -ENOTCONN;
if (sk->sk_state != TCP_ESTABLISHED)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 11/14] dccp: check ccid before dereferencing
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Gerrit Renker, stable
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
a NULL ccid pointer leading to a NULL pointer dereference. This could
lead to a privilege escalation if the attacker is able to map page 0 and
prepare it with a fake ccid_ops pointer.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Cc: stable@vger.kernel.org
---
net/dccp/ccid.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dccp/ccid.h b/net/dccp/ccid.h
index 75c3582..fb85d37 100644
--- a/net/dccp/ccid.h
+++ b/net/dccp/ccid.h
@@ -246,7 +246,7 @@ static inline int ccid_hc_rx_getsockopt(struct ccid *ccid, struct sock *sk,
u32 __user *optval, int __user *optlen)
{
int rc = -ENOPROTOOPT;
- if (ccid->ccid_ops->ccid_hc_rx_getsockopt != NULL)
+ if (ccid != NULL && ccid->ccid_ops->ccid_hc_rx_getsockopt != NULL)
rc = ccid->ccid_ops->ccid_hc_rx_getsockopt(sk, optname, len,
optval, optlen);
return rc;
@@ -257,7 +257,7 @@ static inline int ccid_hc_tx_getsockopt(struct ccid *ccid, struct sock *sk,
u32 __user *optval, int __user *optlen)
{
int rc = -ENOPROTOOPT;
- if (ccid->ccid_ops->ccid_hc_tx_getsockopt != NULL)
+ if (ccid != NULL && ccid->ccid_ops->ccid_hc_tx_getsockopt != NULL)
rc = ccid->ccid_ops->ccid_hc_tx_getsockopt(sk, optname, len,
optval, optlen);
return rc;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 13/14] ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Wensong Zhang, Simon Horman,
Julian Anastasov
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
If at least one of CONFIG_IP_VS_PROTO_TCP or CONFIG_IP_VS_PROTO_UDP is
not set, __ip_vs_get_timeouts() does not fully initialize the structure
that gets copied to userland and that for leaks up to 12 bytes of kernel
stack. Add an explicit memset(0) before passing the structure to
__ip_vs_get_timeouts() to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Wensong Zhang <wensong@linux-vs.org>
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
---
net/netfilter/ipvs/ip_vs_ctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 84444dd..72bf32a 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2759,6 +2759,7 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
{
struct ip_vs_timeout_user t;
+ memset(&t, 0, sizeof(t));
__ip_vs_get_timeouts(net, &t);
if (copy_to_user(user, &t, sizeof(t)) != 0)
ret = -EFAULT;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 14/14] net: fix info leak in compat dev_ifconf()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Mathias Krause
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The implementation of dev_ifconf() for the compat ioctl interface uses
an intermediate ifc structure allocated in userland for the duration of
the syscall. Though, it fails to initialize the padding bytes inserted
for alignment and that for leaks four bytes of kernel stack. Add an
explicit memset(0) before filling the structure to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
---
net/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/socket.c b/net/socket.c
index dfe5b66..a5471f8 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2657,6 +2657,7 @@ static int dev_ifconf(struct net *net, struct compat_ifconf __user *uifc32)
if (copy_from_user(&ifc32, uifc32, sizeof(struct compat_ifconf)))
return -EFAULT;
+ memset(&ifc, 0, sizeof(ifc));
if (ifc32.ifcbuf == 0) {
ifc32.ifc_len = 0;
ifc.ifc_len = 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/14] Bluetooth: L2CAP - Fix info leak via getsockname()
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Mathias Krause, Marcel Holtmann,
Gustavo Padovan, Johan Hedberg
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The L2CAP code fails to initialize the l2_bdaddr_type member of struct
sockaddr_l2 and the padding byte added for alignment. It that for leaks
two bytes kernel stack via the getsockname() syscall. Add an explicit
memset(0) before filling the structure to avoid the info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
---
net/bluetooth/l2cap_sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index a4bb27e..df5ea9e 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -245,6 +245,7 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr, int *l
BT_DBG("sock %p, sk %p", sock, sk);
+ memset(la, 0, sizeof(struct sockaddr_l2));
addr->sa_family = AF_BLUETOOTH;
*len = sizeof(struct sockaddr_l2);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 12/14] dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)
From: Mathias Krause @ 2012-08-15 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Mathias Krause, Gerrit Renker
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
The CCID3 code fails to initialize the trailing padding bytes of struct
tfrc_tx_info added for alignment on 64 bit architectures. It that for
potentially leaks four bytes kernel stack via the getsockopt() syscall.
Add an explicit memset(0) before filling the structure to avoid the
info leak.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/ccid3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/dccp/ccids/ccid3.c b/net/dccp/ccids/ccid3.c
index d65e987..119c043 100644
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -535,6 +535,7 @@ static int ccid3_hc_tx_getsockopt(struct sock *sk, const int optname, int len,
case DCCP_SOCKOPT_CCID_TX_INFO:
if (len < sizeof(tfrc))
return -EINVAL;
+ memset(&tfrc, 0, sizeof(tfrc));
tfrc.tfrctx_x = hc->tx_x;
tfrc.tfrctx_x_recv = hc->tx_x_recv;
tfrc.tfrctx_x_calc = hc->tx_x_calc;
--
1.7.10.4
^ permalink raw reply related
* smsc75xx maintainer?
From: Grant Grundler @ 2012-08-15 21:48 UTC (permalink / raw)
To: netdev
scripts/get_maintainer.pl can't identify an owner for
drivers/net/usb/smsc75xx.c (USB GigE dongle).
Anyone (at SMSC?) interested in fixing suspend/resume for smsc75xx driver?
I don't have time to chase this but it would be nice if this part
worked. Only suspend/resume appears broken.
Some details in http://crosbug.com/31871.
thanks,
grant
^ permalink raw reply
* Re: [PATCH] vmxnet3: Fix race between dev_open() and register_netdev()
From: David Miller @ 2012-08-15 22:10 UTC (permalink / raw)
To: steve; +Cc: sbhatewara, pv-drivers, netdev
In-Reply-To: <1344960816-12022-1-git-send-email-steve@purestorage.com>
From: Steve Hodgson <steve@purestorage.com>
Date: Tue, 14 Aug 2012 17:13:36 +0100
> dev_open() can complete before register_netdev() returns.
> Fix vmxnet3_probe_device() to support this.
>
> Signed-off-by: Steve Hodgson <steve@purestorage.com>
Applied, thanks Steve.
^ permalink raw reply
* Re: [patch net-next v2 01/15] net: introduce upper device lists
From: David Miller @ 2012-08-15 22:12 UTC (permalink / raw)
To: bhutchings
Cc: bridge, ursula.braun, john.r.fastabend, edumazet, shemminger,
sean.hefty, therbert, roland, linux-s390, linux-rdma, fubar, fbl,
hal.rosenstock, jiri, faisal.latif, linux-driver, blaschka,
sony.chacko, gregory.v.rose, xiyou.wangcong, jitendra.kalsaria,
divy, netdev, linux-kernel, joe, linux390, kaber
In-Reply-To: <1344983624.2690.77.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 14 Aug 2012 23:33:44 +0100
> I think we will also need to limit the depth of the device stack so we
> don't run out of stack space here. __netif_receive() implements a kind
> of tail recursion whenever a packet is passed up, but
> __netdev_has_upper_dev() can't avoid doing real recursion (without the
> addition of a flag to net_device so it can mark its progress).
Agreed, we need some kind of limit here.
^ permalink raw reply
* Re: [PATCH v2] XFRM: remove redundant parameter "int dir" in struct xfrm_mgr.acquire
From: David Miller @ 2012-08-15 22:14 UTC (permalink / raw)
To: fan.du; +Cc: netdev
In-Reply-To: <1344996827-20620-1-git-send-email-fan.du@windriver.com>
From: Fan Du <fan.du@windriver.com>
Date: Wed, 15 Aug 2012 10:13:47 +0800
> Sematically speaking, xfrm_mgr.acquire is called when kernel intends to ask
> user space IKE daemon to negotiate SAs with peers. IOW the direction will
> *always* be XFRM_POLICY_OUT, so remove int dir for clarity.
>
> Signed-off-by: Fan Du <fan.du@windriver.com>
> ---
> Changelog for V2:
> - Remove "int dir" in build_acquire parameter suggested by Steffen Klassert.
Applied, thanks.
Please use lowercase "xfrm: " for subsystem indications in your subject
lines, I fixed it up this time.
Thanks again.
^ permalink raw reply
* Re: [patch net-next v2 01/15] net: introduce upper device lists
From: David Miller @ 2012-08-15 22:15 UTC (permalink / raw)
To: jiri
Cc: bridge, ursula.braun, john.r.fastabend, edumazet, shemminger,
sean.hefty, therbert, roland, linux-s390, linux-rdma, fubar, fbl,
hal.rosenstock, faisal.latif, linux-driver, blaschka, sony.chacko,
gregory.v.rose, bhutchings, xiyou.wangcong, jitendra.kalsaria,
divy, netdev, linux-kernel, joe, linux390, kaber
In-Reply-To: <20120815074612.GB1726@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 15 Aug 2012 09:46:12 +0200
> You are probably right. I'm not sure how to handle this correctly
> though. Adding some hard limit number might not be correct.
I would just use a hard limit of something like 8 for now, and if we
need to expand this limit we can consider how to do so with real known
usage in mind rather than pure speculation.
^ permalink raw reply
* Re: [PATCH] net: remove wrong initialization for snd_wl1
From: David Miller @ 2012-08-15 22:23 UTC (permalink / raw)
To: rghitulete; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, dbaluta
In-Reply-To: <1344951021-22667-1-git-send-email-rghitulete@ixiacom.com>
From: Razvan Ghitulete <rghitulete@ixiacom.com>
Date: Tue, 14 Aug 2012 16:30:20 +0300
> The field tp->snd_wl1 is twice initialized, the second time
> seems to be wrong as it may overwrite any update in tcp_ack.
>
> Signed-off-by: Razvan Ghitulete <rghitulete@ixiacom.com>
I'll apply this, but it is mere redundancy.
The only thing tcp_ack() can set tp->snd_wl1 to is TCP_SKB_CB(skb)->seq
which is exactly what it is being set to here as well.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox