* [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
* Re: pull request: wireless-next 2012-08-15
From: David Miller @ 2012-08-15 22:52 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120815185409.GA2137-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 15 Aug 2012 14:54:10 -0400
> This is a batch of updates intended for 3.7. The ath9k, mwifiex,
> and b43 drivers get the bulk of the commits this time, with a handful
> of other driver bits thrown-in. It is mostly just minor fixes and
> cleanups, etc.
>
> Also included is a Bluetooth pull, with a lot of refactoring.
> Gustavo says:
>
> "These are the changes I queued for 3.7. There are a many
> small fixes/improvements by Andre Guedes. A l2cap channel
> refcounting refactor by Jaganath. Bluetooth sockets now
> appears in /proc/net, by Masatake Yamato and Sachin Kamat
> changes ours drivers to use devm_kzalloc()."
>
> Please let me know if there are problems!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] XFRM: remove redundant parameter "int dir" in struct xfrm_mgr.acquire
From: Fan Du @ 2012-08-16 1:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120815.151403.2191772611303249590.davem@davemloft.net>
On 2012年08月16日 06:14, David Miller wrote:
> 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.
Well understood, will do it next time :)
> --
> 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
>
--
Love each day!
--fan
^ permalink raw reply
* RE: [PATCH] net: add new QCA alx ethernet driver
From: Ren, Cloud @ 2012-08-16 2:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qca-linux-team, nic-devel,
Huang, Xiong, hao-ran.liu@canonical.com, joe@perches.com,
Rodriguez, Luis
In-Reply-To: <20120815080226.388ea856@nehalam.linuxnetplumber.net>
From: Stephen Hemminger [mailto:shemminger@vyatta.com]
Sent: Wednesday, August 15, 2012 11:02 PM
>> >>>> + strncpy(netdev->name, pci_name(pdev), sizeof(netdev->name) -
>1);
>> >>>> ...
>> >>>> + strcpy(netdev->name, "eth%d");
>> >>>> + retval = register_netdev(netdev);
>> >>>
>> >>>The strcpy is unnecessary, alloc_etherdev already sets that.
>> >>
>> >> The strcpy is useful. netdev->name is set as pci_name in front. So the strcpy
>> >restores it.
>> >
>> >Are you doing this just to influence the initial driver log messages?
>>
>> Yes.
>>
>> >
>> >Don't do that, it's gross.
>>
>> Ok, I will remove it.
>
>Before the driver is registered, use dev_info() type of logging.
Ok, I will do.
^ permalink raw reply
* Re: [RFC PATCH 0/5] net: socket bind to file descriptor introduced
From: Eric W. Biederman @ 2012-08-16 3:03 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: tglx, mingo, davem, hpa, thierry.reding, bfields, eric.dumazet,
xemul, neilb, netdev, x86, linux-kernel, paul.gortmaker, viro,
gorcunov, akpm, tim.c.chen, devel
In-Reply-To: <20120815161141.7598.16682.stgit@localhost.localdomain>
Stanislav Kinsbursky <skinsbursky@parallels.com> writes:
> This patch set introduces new socket operation and new system call:
> sys_fbind(), which allows to bind socket to opened file.
> File to bind to can be created by sys_mknod(S_IFSOCK) and opened by
> open(O_PATH).
>
> This system call is especially required for UNIX sockets, which has name
> lenght limitation.
>
> The following series implements...
Hmm. I just realized this patchset is even sillier than I thought.
Stanislav is the problem you are ultimately trying to solve nfs clients
in a container connecting to the wrong user space rpciod?
Aka net/sunrpc/xprtsock.c:xs_setup_local only taking an absolute path
and then creating a delayed work item to actually open the unix domain
socket?
The straight correct and straight forward thing to do appears to be:
- Capture the root from current->fs in xs_setup_local.
- In xs_local_finish_connect change current->fs.root to the captured
version of root before kernel_connect, and restore current->fs.root
after kernel_connect.
It might not be a bad idea to implement open on unix domain sockets in
a filesystem as create(AF_LOCAL)+connect() which would allow you to
replace __sock_create + kernel_connect with a simple file_open_root.
But I think the simple scheme of:
struct path old_root;
old_root = current->fs.root;
kernel_connect(...);
current->fs.root = old_root;
Is more than sufficient and will remove the need for anything
except a purely local change to get nfs clients to connect from
containers.
Eric
^ permalink raw reply
* Re: [PATCH 00/14] net: info leaks and other bugs
From: David Miller @ 2012-08-16 4:40 UTC (permalink / raw)
To: minipli; +Cc: netdev, linux-kernel
In-Reply-To: <1345066317-22512-1-git-send-email-minipli@googlemail.com>
From: Mathias Krause <minipli@googlemail.com>
Date: Wed, 15 Aug 2012 23:31:43 +0200
> 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.
All applied and queued up for -stable, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next] igb: Change how we check for pre-existing and assigned VFs
From: Stefan Assmann @ 2012-08-16 5:05 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, e1000-devel, carolyn.wyborny, gregory.v.rose
In-Reply-To: <502BCA89.1030900@intel.com>
On 15.08.2012 18:12, Alexander Duyck wrote:
> On 08/14/2012 10:51 PM, Stefan Assmann wrote:
>> Adapt the pre-existing and assigned VFs code to the ixgbe way introduced
>> in commit 9297127b9cdd8d30c829ef5fd28b7cc0323a7bcd.
>>
>> Instead of searching the enabled VFs we use pci_num_vf to determine enabled VFs.
>> By comparing to which PF an assigned VF is owned it's possible to decide
>> whether to leave it enabled or not.
>>
>> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
[...]
>
> As the author of commit 9297127b9cdd8d30c829ef5fd28b7cc0323a7bcd it
> would have been nice to include me on the CC since I am probably one of
> the best people to review this patch. That being said, the patch itself
> looks good.
Sorry, my mistake. I forgot to do that.
>
> A follow-on patch that probably needs to be written would be to create a
> generic version of "vfs_are_assigned" as a part of the SR-IOV API. That
> way we can avoid duplicating the function in each of the drivers. All
> that would need to be changed is to pull the vendor ID from the pdev,
> and to pull the VF device ID from the SR-IOV configuration space of the
> physical function. I'll try to get to that sometime in the next few
> weeks if nobody gets to it before I do.
Sounds like a good idea.
>
> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
Thanks for the review!
Stefan
^ permalink raw reply
* Re: [patch net-next v2 01/15] net: introduce upper device lists
From: Jiri Pirko @ 2012-08-16 5:48 UTC (permalink / raw)
To: David Miller
Cc: bhutchings-s/n/eUQHGBpZroRs9YW3xA, netdev-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA,
faisal.latif-ral2JQCrhuEAvxtiuMwx3w,
roland-DgEjT+Ai2ygdnm+yROfE0A, sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
fubar-r/Jw6+rmf7HQT0dZR+AlfA, andy-QlMahl40kYEqcZcGjlUOXw,
divy-ut6Up61K2wZBDgjK7y7TUQ,
jitendra.kalsaria-h88ZbnxC6KDQT0dZR+AlfA,
sony.chacko-h88ZbnxC6KDQT0dZR+AlfA,
linux-driver-h88ZbnxC6KDQT0dZR+AlfA, kaber-dcUjhNyLwpNeoWH0uzbU5w,
ursula.braun-tA70FqPdS9bQT0dZR+AlfA,
blaschka-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linux390-tA70FqPdS9bQT0dZR+AlfA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA,
therbert-hpIqsD4AKlfQT0dZR+AlfA,
xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w, joe-6d6DIl74uiNBDgjK7y7TUQ,
gregory.v.rose-ral2JQCrhuEAvxtiuMwx3w,
john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
fbl-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <20120815.151549.1835466517645273818.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Thu, Aug 16, 2012 at 12:15:49AM CEST, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org wrote:
>From: Jiri Pirko <jiri-rHqAuBHg3fBzbRFIqnYvSA@public.gmane.org>
>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.
Okay. I will repost the set soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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