* [PATCH] bluetooth: bnep: fix buffer overflow
From: Vasiliy Kulikov @ 2011-02-14 10:54 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: security-DgEjT+Ai2ygdnm+yROfE0A, Marcel Holtmann,
Gustavo F. Padovan, David S. Miller, Tejun Heo,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Struct ca is copied from userspace. It is not checked whether the "device"
field is NULL terminated. This potentially leads to BUG() inside of
alloc_netdev_mqs() and/or information leak by creating a device with a name
made of contents of kernel stack.
Signed-off-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
---
Compile tested.
net/bluetooth/bnep/sock.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/bnep/sock.c b/net/bluetooth/bnep/sock.c
index 2862f53..30faaf1 100644
--- a/net/bluetooth/bnep/sock.c
+++ b/net/bluetooth/bnep/sock.c
@@ -88,6 +88,7 @@ static int bnep_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long
sockfd_put(nsock);
return -EBADFD;
}
+ ca.device[sizeof(ca.device)-1] = 0;
err = bnep_add_connection(&ca, nsock);
if (!err) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH] bridge: netfilter: fix information leak
From: Vasiliy Kulikov @ 2011-02-14 10:54 UTC (permalink / raw)
To: linux-kernel
Cc: security, Bart De Schuymer, Patrick McHardy, Stephen Hemminger,
David S. Miller, ebtables-user, ebtables-devel, netfilter-devel,
netfilter, coreteam, bridge, netdev
Struct tmp is copied from userspace. It is not checked whether the "name"
field is NULL terminated. This may lead to buffer overflow and passing
contents of kernel stack as a module name to try_then_request_module() and,
consequently, to modprobe commandline. It would be seen by all userspace
processes.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
net/bridge/netfilter/ebtables.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 5f1825d..1ea820b 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1107,6 +1107,8 @@ static int do_replace(struct net *net, const void __user *user,
if (tmp.num_counters >= INT_MAX / sizeof(struct ebt_counter))
return -ENOMEM;
+ tmp.name[sizeof(tmp.name)-1] = 0;
+
countersize = COUNTER_OFFSET(tmp.nentries) * nr_cpu_ids;
newinfo = vmalloc(sizeof(*newinfo) + countersize);
if (!newinfo)
--
1.7.0.4
^ permalink raw reply related
* [PATCH] core: dev: don't call BUG() on bad input
From: Vasiliy Kulikov @ 2011-02-14 10:56 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Eric Dumazet, Tom Herbert, Changli Gao,
Jesse Gross, netdev
alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
net/core/dev.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6392ea0..12ef4b0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
size_t alloc_size;
struct net_device *p;
- BUG_ON(strlen(name) >= sizeof(dev->name));
+ if (strnlen(name, sizeof(dev->name)) >= sizeof(dev->name)) {
+ pr_err("alloc_netdev: Too long device name \n");
+ return NULL;
+ }
if (txqs < 1) {
pr_err("alloc_netdev: Unable to allocate device "
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-14 11:44 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, Balazs Scheidler, KOVACS Krisztian
Assigning a socket in timewait state to skb->sk can trigger
kernel oops, e.g. in nfnetlink_log, which does:
if (skb->sk) {
read_lock_bh(&skb->sk->sk_callback_lock);
if (skb->sk->sk_socket && skb->sk->sk_socket->file) ...
in the timewait case, accessing sk->sk_callback_lock and sk->sk_socket
is invalid.
Either all of these spots will need to add a test for sk->sk_state != TCP_TIME_WAIT,
or xt_TPROXY must not assign a timewait socket to skb->sk.
This does the latter.
If a TW socket is found, assign the tproxy nfmark, but skip the skb->sk assignment,
thus mimicking behaviour of a '-m socket .. -j MARK/ACCEPT' re-routing rule.
The 'SYN to TW socket' case is left unchanged -- we try to redirect to the
listener socket.
Cc: Balazs Scheidler <bazsi@balabit.hu>
Cc: KOVACS Krisztian <hidden@balabit.hu>
Signed-off-by: Florian Westphal <fwestphal@astaro.com>
---
include/net/netfilter/nf_tproxy_core.h | 12 +-----------
net/netfilter/nf_tproxy_core.c | 27 ++++++++++++---------------
net/netfilter/xt_TPROXY.c | 22 ++++++++++++++++++++--
net/netfilter/xt_socket.c | 13 +++++++++++--
4 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/include/net/netfilter/nf_tproxy_core.h b/include/net/netfilter/nf_tproxy_core.h
index cd85b3b..e505358 100644
--- a/include/net/netfilter/nf_tproxy_core.h
+++ b/include/net/netfilter/nf_tproxy_core.h
@@ -201,18 +201,8 @@ nf_tproxy_get_sock_v6(struct net *net, const u8 protocol,
}
#endif
-static inline void
-nf_tproxy_put_sock(struct sock *sk)
-{
- /* TIME_WAIT inet sockets have to be handled differently */
- if ((sk->sk_protocol == IPPROTO_TCP) && (sk->sk_state == TCP_TIME_WAIT))
- inet_twsk_put(inet_twsk(sk));
- else
- sock_put(sk);
-}
-
/* assign a socket to the skb -- consumes sk */
-int
+void
nf_tproxy_assign_sock(struct sk_buff *skb, struct sock *sk);
#endif
diff --git a/net/netfilter/nf_tproxy_core.c b/net/netfilter/nf_tproxy_core.c
index 4d87bef..474d621 100644
--- a/net/netfilter/nf_tproxy_core.c
+++ b/net/netfilter/nf_tproxy_core.c
@@ -28,26 +28,23 @@ nf_tproxy_destructor(struct sk_buff *skb)
skb->destructor = NULL;
if (sk)
- nf_tproxy_put_sock(sk);
+ sock_put(sk);
}
/* consumes sk */
-int
+void
nf_tproxy_assign_sock(struct sk_buff *skb, struct sock *sk)
{
- bool transparent = (sk->sk_state == TCP_TIME_WAIT) ?
- inet_twsk(sk)->tw_transparent :
- inet_sk(sk)->transparent;
-
- if (transparent) {
- skb_orphan(skb);
- skb->sk = sk;
- skb->destructor = nf_tproxy_destructor;
- return 1;
- } else
- nf_tproxy_put_sock(sk);
-
- return 0;
+ /* assigning tw sockets complicates things; most
+ * skb->sk->X checks would have to test sk->sk_state first */
+ if (sk->sk_state == TCP_TIME_WAIT) {
+ inet_twsk_put(inet_twsk(sk));
+ return;
+ }
+
+ skb_orphan(skb);
+ skb->sk = sk;
+ skb->destructor = nf_tproxy_destructor;
}
EXPORT_SYMBOL_GPL(nf_tproxy_assign_sock);
diff --git a/net/netfilter/xt_TPROXY.c b/net/netfilter/xt_TPROXY.c
index 640678f..dcfd57e 100644
--- a/net/netfilter/xt_TPROXY.c
+++ b/net/netfilter/xt_TPROXY.c
@@ -33,6 +33,20 @@
#include <net/netfilter/nf_tproxy_core.h>
#include <linux/netfilter/xt_TPROXY.h>
+static bool tproxy_sk_is_transparent(struct sock *sk)
+{
+ if (sk->sk_state != TCP_TIME_WAIT) {
+ if (inet_sk(sk)->transparent)
+ return true;
+ sock_put(sk);
+ } else {
+ if (inet_twsk(sk)->tw_transparent)
+ return true;
+ inet_twsk_put(inet_twsk(sk));
+ }
+ return false;
+}
+
static inline __be32
tproxy_laddr4(struct sk_buff *skb, __be32 user_laddr, __be32 daddr)
{
@@ -141,7 +155,7 @@ tproxy_tg4(struct sk_buff *skb, __be32 laddr, __be16 lport,
skb->dev, NFT_LOOKUP_LISTENER);
/* NOTE: assign_sock consumes our sk reference */
- if (sk && nf_tproxy_assign_sock(skb, sk)) {
+ if (sk && tproxy_sk_is_transparent(sk)) {
/* This should be in a separate target, but we don't do multiple
targets on the same rule yet */
skb->mark = (skb->mark & ~mark_mask) ^ mark_value;
@@ -149,6 +163,8 @@ tproxy_tg4(struct sk_buff *skb, __be32 laddr, __be16 lport,
pr_debug("redirecting: proto %hhu %pI4:%hu -> %pI4:%hu, mark: %x\n",
iph->protocol, &iph->daddr, ntohs(hp->dest),
&laddr, ntohs(lport), skb->mark);
+
+ nf_tproxy_assign_sock(skb, sk);
return NF_ACCEPT;
}
@@ -306,7 +322,7 @@ tproxy_tg6_v1(struct sk_buff *skb, const struct xt_action_param *par)
par->in, NFT_LOOKUP_LISTENER);
/* NOTE: assign_sock consumes our sk reference */
- if (sk && nf_tproxy_assign_sock(skb, sk)) {
+ if (sk && tproxy_sk_is_transparent(sk)) {
/* This should be in a separate target, but we don't do multiple
targets on the same rule yet */
skb->mark = (skb->mark & ~tgi->mark_mask) ^ tgi->mark_value;
@@ -314,6 +330,8 @@ tproxy_tg6_v1(struct sk_buff *skb, const struct xt_action_param *par)
pr_debug("redirecting: proto %hhu %pI6:%hu -> %pI6:%hu, mark: %x\n",
tproto, &iph->saddr, ntohs(hp->source),
laddr, ntohs(lport), skb->mark);
+
+ nf_tproxy_assign_sock(skb, sk);
return NF_ACCEPT;
}
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 00d6ae8..6d2226e 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -35,6 +35,15 @@
#include <net/netfilter/nf_conntrack.h>
#endif
+static void
+xt_socket_put_sk(struct sock *sk)
+{
+ if (sk->sk_state == TCP_TIME_WAIT)
+ inet_twsk_put(inet_twsk(sk));
+ else
+ sock_put(sk);
+}
+
static int
extract_icmp4_fields(const struct sk_buff *skb,
u8 *protocol,
@@ -164,7 +173,7 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
(sk->sk_state == TCP_TIME_WAIT &&
inet_twsk(sk)->tw_transparent));
- nf_tproxy_put_sock(sk);
+ xt_socket_put_sk(sk);
if (wildcard || !transparent)
sk = NULL;
@@ -298,7 +307,7 @@ socket_mt6_v1(const struct sk_buff *skb, struct xt_action_param *par)
(sk->sk_state == TCP_TIME_WAIT &&
inet_twsk(sk)->tw_transparent));
- nf_tproxy_put_sock(sk);
+ xt_socket_put_sk(sk);
if (wildcard || !transparent)
sk = NULL;
--
1.7.2.2
^ permalink raw reply related
* [PATCH] phy/micrel: add ability to support 50MHz RMII clock on KZS8051RNL
From: Baruch Siach @ 2011-02-14 12:05 UTC (permalink / raw)
To: netdev; +Cc: Baruch Siach, David J. Choi
Platform code can now set the MICREL_PHY_50MHZ_CLK bit of dev_flags in a fixup
routine (registered with phy_register_fixup_for_uid()), to make the KZS8051RNL
PHY work with 50MHz RMII reference clock.
Cc: David J. Choi <david.choi@micrel.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/phy/micrel.c | 24 ++++++++++++++++--------
include/linux/micrel_phy.h | 16 ++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100644 include/linux/micrel_phy.h
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 8bb7db6..a6c3bf5 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -19,13 +19,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/phy.h>
-
-#define PHY_ID_KSZ9021 0x00221611
-#define PHY_ID_KS8737 0x00221720
-#define PHY_ID_KS8041 0x00221510
-#define PHY_ID_KS8051 0x00221550
-/* both for ks8001 Rev. A/B, and for ks8721 Rev 3. */
-#define PHY_ID_KS8001 0x0022161A
+#include <linux/micrel_phy.h>
/* general Interrupt control/status reg in vendor specific block. */
#define MII_KSZPHY_INTCS 0x1B
@@ -46,6 +40,7 @@
#define KSZPHY_CTRL_INT_ACTIVE_HIGH (1 << 9)
#define KSZ9021_CTRL_INT_ACTIVE_HIGH (1 << 14)
#define KS8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
+#define KSZ8051_RMII_50MHZ_CLK (1 << 7)
static int kszphy_ack_interrupt(struct phy_device *phydev)
{
@@ -106,6 +101,19 @@ static int kszphy_config_init(struct phy_device *phydev)
return 0;
}
+static int ks8051_config_init(struct phy_device *phydev)
+{
+ int regval;
+
+ if (phydev->dev_flags & MICREL_PHY_50MHZ_CLK) {
+ regval = phy_read(phydev, MII_KSZPHY_CTRL);
+ regval |= KSZ8051_RMII_50MHZ_CLK;
+ phy_write(phydev, MII_KSZPHY_CTRL, regval);
+ }
+
+ return 0;
+}
+
static struct phy_driver ks8737_driver = {
.phy_id = PHY_ID_KS8737,
.phy_id_mask = 0x00fffff0,
@@ -142,7 +150,7 @@ static struct phy_driver ks8051_driver = {
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
| SUPPORTED_Asym_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
- .config_init = kszphy_config_init,
+ .config_init = ks8051_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
new file mode 100644
index 0000000..dd8da34
--- /dev/null
+++ b/include/linux/micrel_phy.h
@@ -0,0 +1,16 @@
+#ifndef _MICREL_PHY_H
+#define _MICREL_PHY_H
+
+#define MICREL_PHY_ID_MASK 0x00fffff0
+
+#define PHY_ID_KSZ9021 0x00221611
+#define PHY_ID_KS8737 0x00221720
+#define PHY_ID_KS8041 0x00221510
+#define PHY_ID_KS8051 0x00221550
+/* both for ks8001 Rev. A/B, and for ks8721 Rev 3. */
+#define PHY_ID_KS8001 0x0022161A
+
+/* struct phy_device dev_flags definitions */
+#define MICREL_PHY_50MHZ_CLK 0x00000001
+
+#endif /* _MICREL_PHY_H */
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] core: dev: don't call BUG() on bad input
From: Nicolas de Pesloüan @ 2011-02-14 12:16 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <1297680967-11893-1-git-send-email-segoon@openwall.com>
Le 14/02/2011 11:56, Vasiliy Kulikov a écrit :
> alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
> Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
> even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
> other errors.
>
> Signed-off-by: Vasiliy Kulikov<segoon@openwall.com>
> ---
> Compile tested.
>
> net/core/dev.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 6392ea0..12ef4b0 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> size_t alloc_size;
> struct net_device *p;
>
> - BUG_ON(strlen(name)>= sizeof(dev->name));
> + if (strnlen(name, sizeof(dev->name))>= sizeof(dev->name)) {
"size_t strnlen(const char *s, size_t maxlen) : The strnlen() function returns strlen(s), if that is
less than maxlen, or maxlen if there is no '\0' character among the first maxlen characters pointed
to by s."
How can strnlen(name, sizeof(dev->name)) be greater than sizeof(dev->name)?
Shouldn't it be "if (strnlen(name, sizeof(dev->name)) == sizeof(dev->name))" instead?
Nicolas.
> + pr_err("alloc_netdev: Too long device name \n");
> + return NULL;
> + }
>
> if (txqs< 1) {
> pr_err("alloc_netdev: Unable to allocate device "
^ permalink raw reply
* Re: [PATCH] core: dev: don't call BUG() on bad input
From: Vasiliy Kulikov @ 2011-02-14 12:23 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <4D591D04.4050000@gmail.com>
Hi Nicolas,
On Mon, Feb 14, 2011 at 13:16 +0100, Nicolas de Pesloüan wrote:
> >- BUG_ON(strlen(name)>= sizeof(dev->name));
> >+ if (strnlen(name, sizeof(dev->name))>= sizeof(dev->name)) {
Ehh... Space after ")" is needed :)
> "size_t strnlen(const char *s, size_t maxlen) : The strnlen()
> function returns strlen(s), if that is less than maxlen, or maxlen
> if there is no '\0' character among the first maxlen characters
> pointed to by s."
>
> How can strnlen(name, sizeof(dev->name)) be greater than sizeof(dev->name)?
>
> Shouldn't it be "if (strnlen(name, sizeof(dev->name)) == sizeof(dev->name))" instead?
Not a big deal, but MO it's better to guard from everything that
is not a good input by negating the check. strnlen() < sizeof() is OK,
strnlen() >= sizeof() is bad. Is "==" more preferable for net/ coding style?
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH] core: dev: don't call BUG() on bad input
From: Nicolas de Pesloüan @ 2011-02-14 13:01 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <20110214122313.GA10062@albatros>
Le 14/02/2011 13:23, Vasiliy Kulikov a écrit :
> Hi Nicolas,
Hi Vasiliy,
> On Mon, Feb 14, 2011 at 13:16 +0100, Nicolas de Pesloüan wrote:
>>> - BUG_ON(strlen(name)>= sizeof(dev->name));
>>> + if (strnlen(name, sizeof(dev->name))>= sizeof(dev->name)) {
>
> Ehh... Space after ")" is needed :)
:-D
>> "size_t strnlen(const char *s, size_t maxlen) : The strnlen()
>> function returns strlen(s), if that is less than maxlen, or maxlen
>> if there is no '\0' character among the first maxlen characters
>> pointed to by s."
>>
>> How can strnlen(name, sizeof(dev->name)) be greater than sizeof(dev->name)?
>>
>> Shouldn't it be "if (strnlen(name, sizeof(dev->name)) == sizeof(dev->name))" instead?
>
> Not a big deal, but MO it's better to guard from everything that
> is not a good input by negating the check. strnlen()< sizeof() is OK,
> strnlen()>= sizeof() is bad. Is "==" more preferable for net/ coding style?
Agreed, both cannot cause any troubles. == is supposed to be better from the API point of view, but
>= is probably more readable.
Nicolas.
^ permalink raw reply
* (unknown),
From: robertjet.fellow @ 2011-02-14 11:45 UTC (permalink / raw)
My name is Mr. R. Jet Fellows. Am a citizen of the united states presently in Hong Kong where i have been diagnosed with Esophageal cancer and it has defied all forms of medical treatment, and right now I have only about a few months to live according to the medical experts.
Though am very rich, i never thought of raising my own family, I only focused on my businesses as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. The treatment of this disease has so far squashed a handsome amount of my money in savings.
Now that my health has deteriorated so badly and it has been confirmed to me by the doctors that my ailment will defy all forms of medical treatment, i have decided not to spend more money on this ailment anymore.
The last of my money which no one knows of is the huge cash deposit of $2.6m United States Dollars that I have with a Finance Vaulting Unit in the Europe . I will want you to help me collect this deposit from the company and help me distribute it to charity in your region. You will have 25% of this total sum for your time and effort. I cannot talk with you on the phone due to my health situation, and I am using my Laptop Computer to communicate with you, since this is my only means of communication. One passionate appeal i will make to you is to keep this transaction confidential until this money gets to you. If you are interested in carrying out this assignment on my behalf fill this form below when when writing me back.
Email: robertjet.fellow@gmail.com
Your names .......
Your resident address. ......
Your country name..........
Your present location........
Your occupation...............
Your tel/cell number.........
Your age/sex..................
Your company name if any.......
I will be waiting to hear from you as soon as you can.
Sincerely yours,
R. Jet Fellows.
^ permalink raw reply
* (unknown),
From: robertjet.fellow @ 2011-02-14 11:49 UTC (permalink / raw)
My name is Mr. R. Jet Fellows. Am a citizen of the united states presently in Hong Kong where i have been diagnosed with Esophageal cancer and it has defied all forms of medical treatment, and right now I have only about a few months to live according to the medical experts.
Though am very rich, i never thought of raising my own family, I only focused on my businesses as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. The treatment of this disease has so far squashed a handsome amount of my money in savings.
Now that my health has deteriorated so badly and it has been confirmed to me by the doctors that my ailment will defy all forms of medical treatment, i have decided not to spend more money on this ailment anymore.
The last of my money which no one knows of is the huge cash deposit of $2.6m United States Dollars that I have with a Finance Vaulting Unit in the Europe . I will want you to help me collect this deposit from the company and help me distribute it to charity in your region. You will have 25% of this total sum for your time and effort. I cannot talk with you on the phone due to my health situation, and I am using my Laptop Computer to communicate with you, since this is my only means of communication. One passionate appeal i will make to you is to keep this transaction confidential until this money gets to you. If you are interested in carrying out this assignment on my behalf fill this form below when when writing me back.
Email: robertjet.fellow@gmail.com
Your names .......
Your resident address. ......
Your country name..........
Your present location........
Your occupation...............
Your tel/cell number.........
Your age/sex..................
Your company name if any.......
I will be waiting to hear from you as soon as you can.
Sincerely yours,
R. Jet Fellows.
^ permalink raw reply
* Re: [RFC PATCH V2 0/5] macvtap TX zero copy between guest and host kernel
From: Michael S. Tsirkin @ 2011-02-14 13:09 UTC (permalink / raw)
To: Shirley Ma
Cc: Avi Kivity, Arnd Bergmann, xiaohui.xin, netdev, kvm, linux-kernel
In-Reply-To: <1291974691.2167.24.camel@localhost.localdomain>
On Fri, Dec 10, 2010 at 01:51:31AM -0800, Shirley Ma wrote:
> This patchset add supports for TX zero-copy between guest and host
> kernel through vhost. It significantly reduces CPU utilization on the
> local host on which the guest is located (It reduced 30-50% CPU usage
> for vhost thread for single stream test). The patchset is based on
> previous submission and comments from the community regarding when/how
> to handle guest kernel buffers to be released. This is the simplest
> approach I can think of after comparing with several other solutions.
>
> This patchset includes:
>
> 1. Induce a new sock zero-copy flag, SOCK_ZEROCOPY;
>
> 2. Induce a new device flag, NETIF_F_ZEROCOPY for device can support
> zero-copy;
>
> 3. Add a new struct skb_ubuf_info in skb_share_info for userspace
> buffers release callback when device DMA has done for that skb;
>
> 4. Add vhost zero-copy callback in vhost when skb last refcnt is gone;
> add vhost_zerocopy_add_used_and_signal to notify guest to release TX
> skb buffers.
>
> 5. Add macvtap zero-copy in lower device when sending packet is greater
> than 128 bytes.
>
> The patchset has passed netperf/netserver test on Chelsio, and
> continuing test on other 10GbE NICs, like Intel ixgbe, Mellanox mlx4...
> I will provide guest to host, host to guest performance data next week.
>
> However when running stress test, vhost & virtio_net seems out of sync,
> and virito_net interrupt was disabled somehow, and it stopped to send
> any packet. This problem has bothered me for a long long time, I will
> continue to look at this.
>
> Please review this.
>
> Thanks
> Shirley
What's the status here? Since there are core net changes, we'll need to
see the final version soon if it's to appear in 2.6.39.
Could the problem be related to the patch
virtio_net: Add schedule check to napi_enable call
?
Also, I expect there should be driver patches for some
devices? Where are they?
Thanks,
--
MST
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Subhasish Ghosh @ 2011-02-14 13:15 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
open list:CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
open list:CAN NETWORK DRIVERS, Wolfgang Grandegger,
m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4D58F77B.9080005-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hello,
The problem with the "all" implementation is that it hogs the ARM/DSP
heavily and that's the reason why we specifically avoided this in our
firmware design.
Hence, implementing this condition spoils the whole purpose of the PRU!!
--------------------------------------------------
From: "Marc Kleine-Budde" <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Sent: Monday, February 14, 2011 3:05 PM
To: "Subhasish Ghosh" <subhasish-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Cc: "Wolfgang Grandegger" <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>; "Kurt Van Dijck"
<kurt.van.dijck-/BeEPy95v10@public.gmane.org>; <davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>;
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; <m-watkins-l0cyMroinI0@public.gmane.org>;
<nsekhar-l0cyMroinI0@public.gmane.org>; <sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>; "open list:CAN NETWORK
DRIVERS" <socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; "open list:CAN NETWORK DRIVERS"
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "open list" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.
Hello,
On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
> That is correct, we receive only pre-programmed CAN ids and "all" or
> "range" implementation is not there in the PRU firmware.
I'd really like to see that you add a "all" implementation to the
firmware. Or even better use the standard id/mask approach.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* (unknown),
From: robertjet.fellow @ 2011-02-14 11:53 UTC (permalink / raw)
My name is Mr. R. Jet Fellows. Am a citizen of the united states presently in Hong Kong where i have been diagnosed with Esophageal cancer and it has defied all forms of medical treatment, and right now I have only about a few months to live according to the medical experts.
Though am very rich, i never thought of raising my own family, I only focused on my businesses as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. The treatment of this disease has so far squashed a handsome amount of my money in savings.
Now that my health has deteriorated so badly and it has been confirmed to me by the doctors that my ailment will defy all forms of medical treatment, i have decided not to spend more money on this ailment anymore.
The last of my money which no one knows of is the huge cash deposit of $2.6m United States Dollars that I have with a Finance Vaulting Unit in the Europe . I will want you to help me collect this deposit from the company and help me distribute it to charity in your region. You will have 25% of this total sum for your time and effort. I cannot talk with you on the phone due to my health situation, and I am using my Laptop Computer to communicate with you, since this is my only means of communication. One passionate appeal i will make to you is to keep this transaction confidential until this money gets to you. If you are interested in carrying out this assignment on my behalf fill this form below when when writing me back.
Email: robertjet.fellow@gmail.com
Your names .......
Your resident address. ......
Your country name..........
Your present location........
Your occupation...............
Your tel/cell number.........
Your age/sex..................
Your company name if any.......
I will be waiting to hear from you as soon as you can.
Sincerely yours,
R. Jet Fellows.
^ permalink raw reply
* Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: chriss @ 2011-02-14 13:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <4D4FE100.5090808@gmail.com>
Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:
> I think you should have a look at ebtables command, in particular, the
BROUTING chain of broute
> table. If this chain ask the packet to be dropped, then bridge will ignore it
and give a chance to
> the upper layer to use it. Upper layer might be IP, or in your particular
setup, VLAN.
>
> HTH,
>
> Nicolas.
Thank you very much for the ebtables hint.
I also tried to add the vlan to my bridge device but only droping the vlan
tagged paket with ebtables got it working.
I'm not sure if this is the wanted behavior for bridging vlan actions.
..or my network setup is just to ..f%%%'ed up?!
Thanks nicolas
regards//chriss
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Marc Kleine-Budde @ 2011-02-14 13:33 UTC (permalink / raw)
To: Subhasish Ghosh
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Wolfgang Grandegger, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <8CB9F2C8F75C4041B9F0691D209DDAFD@subhasishg>
[-- Attachment #1.1: Type: text/plain, Size: 1296 bytes --]
On 02/14/2011 02:15 PM, Subhasish Ghosh wrote:
> Hello,
>
> The problem with the "all" implementation is that it hogs the ARM/DSP
> heavily and that's the reason why we specifically avoided this in our
> firmware design.
> Hence, implementing this condition spoils the whole purpose of the PRU!!
What about implementing the standard id/mask approach?
if (canid & mask == id & mask)
aceept();
else
discard();
To keep the hot-path as small as possible, the id & mask operation is
done during setup, only one. This is probably just an additional "and"
operation (the "& mask"). This opens the way to act like a normal can
controller.
As long as we don't have any support for hardware filters in socketcan,
it's a good choice to use sysfs to configure your filters.
Have a look at [1] and [2] for how to use sysfs files.
cheers, Marc
[1]
http://git.kernel.org/linus/3a5655a5b545e9647c3437473ee3d815fe1b9050
[2]
http://git.kernel.org/linus/fef52b0171dfd7dd9b85c9cc201bd433b42a8ded
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Wolfgang Grandegger @ 2011-02-14 13:42 UTC (permalink / raw)
To: Subhasish Ghosh
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Marc Kleine-Budde, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <8CB9F2C8F75C4041B9F0691D209DDAFD@subhasishg>
On 02/14/2011 02:15 PM, Subhasish Ghosh wrote:
> Hello,
>
> The problem with the "all" implementation is that it hogs the ARM/DSP
> heavily and that's the reason why we specifically avoided this in our
> firmware design.
> Hence, implementing this condition spoils the whole purpose of the PRU!!
Well, I doubt that a CAN controller just supporting 8 CAN identifiers
will make many CAN users happy. Anyway, the CAN identifiers could/should
be configured via SysFS files (as Marc suggested).
Wolfgang.
> --------------------------------------------------
> From: "Marc Kleine-Budde" <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Sent: Monday, February 14, 2011 3:05 PM
> To: "Subhasish Ghosh" <subhasish-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Cc: "Wolfgang Grandegger" <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>; "Kurt Van Dijck"
> <kurt.van.dijck-/BeEPy95v10@public.gmane.org>;
> <davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>;
> <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; <m-watkins-l0cyMroinI0@public.gmane.org>;
> <nsekhar-l0cyMroinI0@public.gmane.org>; <sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>; "open list:CAN NETWORK
> DRIVERS" <socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; "open list:CAN NETWORK
> DRIVERS" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "open list"
> <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.
>
> Hello,
>
> On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
>> That is correct, we receive only pre-programmed CAN ids and "all" or
>> "range" implementation is not there in the PRU firmware.
>
> I'd really like to see that you add a "all" implementation to the
> firmware. Or even better use the standard id/mask approach.
>
> cheers, Marc
>
^ permalink raw reply
* [PATCH net-next-2.6] ipv4: fix rcu lock imbalance in fib_select_default()
From: Eric Dumazet @ 2011-02-14 14:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Commit 0c838ff1ade7 (ipv4: Consolidate all default route selection
implementations.) forgot to remove one rcu_read_unlock() from
fib_select_default().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/fib_semantics.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 146bd82..562f34c 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1189,7 +1189,7 @@ void fib_select_default(struct fib_result *res)
fib_result_assign(res, last_resort);
tb->tb_default = last_idx;
out:
- rcu_read_unlock();
+ return;
}
#ifdef CONFIG_IP_ROUTE_MULTIPATH
^ permalink raw reply related
* Re: [patch net-next-2.6] net: make dev->master general
From: Nicolas de Pesloüan @ 2011-02-14 14:11 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet
In-Reply-To: <20110214090133.GB2746@psychotron.redhat.com>
Le 14/02/2011 10:01, Jiri Pirko a écrit :
> Mon, Feb 14, 2011 at 09:48:44AM CET, nicolas.2p.debian@gmail.com wrote:
>> Le 12/02/2011 17:48, Jiri Pirko a écrit :
>>> dev->master is now tightly connected to bonding driver. This patch makes
>>> this pointer more general and ready to be used by others.
>>>
>>> - netdev_set_master() - bond specifics moved to new function
>>> netdev_set_bond_master()
>>> - introduced netif_is_bond_slave() to check if device is a bonding slave
>>>
>>> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>>
>> Hi Jiri,
>>
>> Even if DaveM already applied your patch, I'm not comfortable with it.
>>
>> What is the rational behind it? Do you have anything in mind to use
>> the now "more general" master field of net_device?
>>
>> Of course, I won't advocate for every fields having only a single
>> possible usage, but, using master for several different things might
>> jeopardize our ability to share an interface between several logical
>> interface systems:
>>
>> Due to the current usage of the rx_handler field in net_device, the
>> code suggest that an interface cannot be part of a bridge and of a
>> macvlan at the same time. Even if bridge provide an hook for ebtables
>> to ignore an skb and allow other to get it, macvlan cannot be
>> registered on the same lower interface as a bridge, because
>> rx_handler can only hold a single value.
>>
>> By giving master a more general meaning, I think we might face a
>> similar problem. It might disallow an interface to be enslaved to
>> bonding and part of another logical interface at the same time, if
>> such logical interface also use the master field.
>
> That is true. I think that it makes no sense to have iface enslaved in
> bond and bridge at the same time. Do you have a scenario where it makes
> sense?
Agreed for bonding/bridge, because both tend to eat all skb, even if bridge has a way to give skb to
others, as stated above. Bonding might/should do the same.
But, for macvlan or vlan for example, it is different. They will ignore skb not matching the correct
dst_mac (macvlan) or vlan_id (vlan) and give a chance to other to use the skb.
Many setups involving several logical ifaces sharing a physical iface make sense:
- bridge+vlan (see "2.6.37 regression: adding main interface to a bridge breaks vlan interface RX")
- bride+macvlan (In particular because bridge might no know about the other dst_macs that should be
considered local. I didn't check that particular point in detail.)
- bonding+vlan
- bonding+macvlan
So, would master be used only for ifaces that "eat all skb"?
Nicolas.
^ permalink raw reply
* Re: [PATCH] bluetooth: bnep: fix buffer overflow
From: Gustavo F. Padovan @ 2011-02-14 14:35 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, security, Marcel Holtmann, David S. Miller,
Tejun Heo, linux-bluetooth, netdev
In-Reply-To: <1297680871-11617-1-git-send-email-segoon@openwall.com>
Hi Vasiliy,
* Vasiliy Kulikov <segoon@openwall.com> [2011-02-14 13:54:31 +0300]:
> Struct ca is copied from userspace. It is not checked whether the "device"
> field is NULL terminated. This potentially leads to BUG() inside of
> alloc_netdev_mqs() and/or information leak by creating a device with a name
> made of contents of kernel stack.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Compile tested.
>
> net/bluetooth/bnep/sock.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] bluethooth: sco: fix information leak to userspace
From: Gustavo F. Padovan @ 2011-02-14 14:36 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
security-DgEjT+Ai2ygdnm+yROfE0A, Marcel Holtmann, David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1297680867-11551-1-git-send-email-segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
Hi Vasiliy,
* Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> [2011-02-14 13:54:26 +0300]:
> struct sco_conninfo has one padding byte in the end. Local variable
> cinfo of type sco_conninfo is copied to userspace with this uninizialized
> one byte, leading to old stack contents leak.
>
> Signed-off-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
> ---
> Compile tested.
>
> net/bluetooth/sco.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied as well, thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* [PATCH v2] core: dev: don't call BUG() on bad input
From: Vasiliy Kulikov @ 2011-02-14 14:42 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Eric Dumazet, Tom Herbert, Changli Gao,
Jesse Gross, netdev
alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
v2 - fixed checkpatch warning - space before "\n".
net/core/dev.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6392ea0..12ef4b0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
size_t alloc_size;
struct net_device *p;
- BUG_ON(strlen(name) >= sizeof(dev->name));
+ if (strnlen(name, sizeof(dev->name)) >= sizeof(dev->name)) {
+ pr_err("alloc_netdev: Too long device name\n");
+ return NULL;
+ }
if (txqs < 1) {
pr_err("alloc_netdev: Unable to allocate device "
--
1.7.0.4
^ permalink raw reply related
* Re: Possible netfilter-related memory corruption in 2.6.37
From: Eric Dumazet @ 2011-02-14 15:11 UTC (permalink / raw)
To: Avi Kivity
Cc: netfilter-devel, Marcelo Tosatti, nicolas prochazka, KVM list,
netdev
In-Reply-To: <4D594313.4050009@redhat.com>
Le lundi 14 février 2011 à 16:58 +0200, Avi Kivity a écrit :
> We see severe memory corruption in kvm while used in conjunction with
> bridge/netfilter. Enabling slab debugging points the finger at a
> netfilter chain invoked from the bridge code.
>
> Can someone take a look?
>
> https://bugzilla.kernel.org/show_bug.cgi?id=27052
>
CC netdev
Does a revert of commit ca44ac386181ba7 help a bit ?
(net: don't reallocate skb->head unless the current one hasn't the
needed extra size or is shared)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-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 v2] core: dev: don't call BUG() on bad input
From: Alexey Dobriyan @ 2011-02-14 15:16 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <1297694579-23611-1-git-send-email-segoon@openwall.com>
On Mon, Feb 14, 2011 at 4:42 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
> Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
> even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
> other errors.
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> size_t alloc_size;
> struct net_device *p;
>
> - BUG_ON(strlen(name) >= sizeof(dev->name));
> + if (strnlen(name, sizeof(dev->name)) >= sizeof(dev->name)) {
> + pr_err("alloc_netdev: Too long device name\n");
> + return NULL;
> + }
Netdevice name isn't some random junk you get from userspace, so BUG is fine.
^ permalink raw reply
* Re: Possible netfilter-related memory corruption in 2.6.37
From: Jan Engelhardt @ 2011-02-14 15:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: Avi Kivity, netfilter-devel, Marcelo Tosatti, nicolas prochazka,
KVM list, netdev
In-Reply-To: <1297696283.2996.33.camel@edumazet-laptop>
On Monday 2011-02-14 16:11, Eric Dumazet wrote:
>Le lundi 14 février 2011 à 16:58 +0200, Avi Kivity a écrit :
>> We see severe memory corruption in kvm while used in conjunction with
>> bridge/netfilter. Enabling slab debugging points the finger at a
>> netfilter chain invoked from the bridge code.
>>
>> Can someone take a look?
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=27052
Maybe looks familiar to https://lkml.org/lkml/2011/2/3/147
^ permalink raw reply
* Re: [PATCH v2] core: dev: don't call BUG() on bad input
From: Vasiliy Kulikov @ 2011-02-14 15:23 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <AANLkTimidxVJxw-XKTWwCZh8k_vKHDeqxAwVbY6+aJ6x@mail.gmail.com>
Alexey,
On Mon, Feb 14, 2011 at 17:16 +0200, Alexey Dobriyan wrote:
> On Mon, Feb 14, 2011 at 4:42 PM, Vasiliy Kulikov <segoon@openwall.com> wrote:
> > alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
> > Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
> > even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
> > other errors.
>
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> > size_t alloc_size;
> > struct net_device *p;
> >
> > - BUG_ON(strlen(name) >= sizeof(dev->name));
> > + if (strnlen(name, sizeof(dev->name)) >= sizeof(dev->name)) {
> > + pr_err("alloc_netdev: Too long device name\n");
> > + return NULL;
> > + }
>
> Netdevice name isn't some random junk you get from userspace, so BUG is fine.
It IS for bluetooth, see net/bluetooth/bnep/core.c: bnep_add_connection() and
net/bluetooth/bnep/sock.c: bnep_sock_ioctl().
And txqs, txqs? Then why do not BUG() on bad txqs too? Why so
insonsistent? BUG() should be called in some critical situation, net
device creation is probably not such a thing.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ 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