* [PATCH] rds: Lost locking in loop connection freeing
From: Pavel Emelyanov @ 2010-11-02 11:52 UTC (permalink / raw)
To: Andy Grover, David Miller; +Cc: rds-devel, Linux Netdev List
The conn is removed from list in there and this requires
proper lock protection.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/rds/loop.c b/net/rds/loop.c
index c390156..aeec1d4 100644
--- a/net/rds/loop.c
+++ b/net/rds/loop.c
@@ -134,8 +134,12 @@ static int rds_loop_conn_alloc(struct rds_connection *conn, gfp_t gfp)
static void rds_loop_conn_free(void *arg)
{
struct rds_loop_connection *lc = arg;
+ unsigned long flags;
+
rdsdebug("lc %p\n", lc);
+ spin_lock_irqsave(&loop_conns_lock, flags);
list_del(&lc->loop_node);
+ spin_unlock_irqrestore(&loop_conns_lock, flags);
kfree(lc);
}
--
1.5.5.6
^ permalink raw reply related
* [PATCH] rds: Remove kfreed tcp conn from list
From: Pavel Emelyanov @ 2010-11-02 11:54 UTC (permalink / raw)
To: Andy Grover, David Miller; +Cc: rds-devel, Linux Netdev List
All the rds_tcp_connection objects are stored list, but when
being freed it should be removed from there.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 08a8c6c..8e0a320 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -221,7 +221,13 @@ static int rds_tcp_conn_alloc(struct rds_connection *conn, gfp_t gfp)
static void rds_tcp_conn_free(void *arg)
{
struct rds_tcp_connection *tc = arg;
+ unsigned long flags;
rdsdebug("freeing tc %p\n", tc);
+
+ spin_lock_irqsave(&rds_tcp_conn_lock, flags);
+ list_del(&tc->t_tcp_node);
+ spin_unlock_irqrestore(&rds_tcp_conn_lock, flags);
+
kmem_cache_free(rds_tcp_conn_slab, tc);
}
--
1.5.5.6
^ permalink raw reply related
* For your interest
From: Srood Sherif @ 2010-11-02 12:59 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Greeting,
My name is Mr. Srood A. Sherif, I live and work in Abu
Dhabi UAE. I have an urgent business which I believe
will interest you. Find the enclose for details.
For any reason you cannot open that attachment, please
let me know so that I can resend it in the body of the
mail, thank you.
I wait for your response, Thank you.
Regards
Srood A. Sherif
[-- Attachment #2: THE INFORMATION.jpg --]
[-- Type: image/jpeg, Size: 240015 bytes --]
^ permalink raw reply
* Re: [PATCH] net: sh_eth: ctrl_in/outX to __raw_read/writeX conversion.
From: Paul Mundt @ 2010-11-02 13:39 UTC (permalink / raw)
To: Nobuhiro Iwamatsu; +Cc: netdev
In-Reply-To: <1288666295-12529-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
On Tue, Nov 02, 2010 at 11:51:35AM +0900, Nobuhiro Iwamatsu wrote:
> The ctrl_xxx routines are deprecated, switch over to the __raw_xxx
> versions.
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
I sent a similar patch yesterday:
http://patchwork.ozlabs.org/patch/69831/
It doesn't matter really which one gets applied, although I opted to use
the accessors with strong ordering given that we'll continue to see this
block in newer CPUs where weak ordering is unlikely to be sufficient.
^ permalink raw reply
* Partnership..?
From: Mr. Vincent Cheng @ 2010-11-02 9:44 UTC (permalink / raw)
To: info
Hello,
I am Mr. Vincent Cheng, and have a sensitive and confidential brief from
Hong Kong.
I am asking for your partnership in re-profiling funds and will give the
details.
This is a legitimate transaction and you will be paid a handsome
percentage for your "Management Fees". If interested you can kindly write
and provide me with your confidential telephone number or fax number
and I will provide further details with proper guidelines. I require absolute
confidentiality as to any political problems.
Finally, note that this must be concluded within two weeks. Kindly write
back to this email mrchengvich66@yahoo.com.hk, I look forward to hear from
you.
Regards,
Vincent Cheng.
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Denys Fedoryshchenko @ 2010-11-02 13:49 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <20101028070550.GA7647@ff.dom.local>
I didn't try yet, but i enable more debugs and catch linked list corruption.
Here is dumps from netconsole:
http://www.nuclearcat.com/ll.txt
http://www.nuclearcat.com/ll2.txt
I have another PC, also fails to run 2.6.36, but netconsole don't give
anything.
Both PC's have strange issue with clock drifting away too much (on 2.6.35 and
maybe even before).
On Thursday 28 October 2010 10:05:50 Jarek Poplawski wrote:
> On 2010-10-25 11:22, Denys Fedoryshchenko wrote:
> > Hi
> >
> > Here is what i got from netconsole
> >
> > [ 259.238755] BUG: unable to handle kernel
> > paging request
> > at f8ba001c
> > [ 259.238953] IP:
> > [<c0199ebe>] do_select+0x2cc/0x502
>
> ...
>
> > It is not easy to do full git bisect(it is semi-embedded distro), but i
> > can try reversing particular commits, if someone can give idea which
> > one, and can try debug patches.
>
> Hi,
> Nothing concrete, but you might try reverting this one:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commi
> tdiff;h=15fd0cd9a2ad24a78fbee369dec8ca660979d57e
>
> Jarek P.
> --
> 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
^ permalink raw reply
* [SECURITY] memory corruption in X.25 facilities parsing
From: Dan Rosenberg @ 2010-11-02 15:02 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev, security, stable
I put this together after a quick glance, so if someone knows this code
better than I do (i.e. at all), feel free to comment or drop this patch
if it's unnecessary.
A value of 0 will cause a memcpy() of ULONG_MAX size, destroying the
kernel heap.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
--- linux-2.6.36-rc6.orig/net/x25/x25_facilities.c 2010-09-28 21:01:22.000000000 -0400
+++ linux-2.6.36-rc6/net/x25/x25_facilities.c 2010-11-02 10:36:02.827291324 -0400
@@ -134,14 +134,14 @@ int x25_parse_facilities(struct sk_buff
case X25_FAC_CLASS_D:
switch (*p) {
case X25_FAC_CALLING_AE:
- if (p[1] > X25_MAX_DTE_FACIL_LEN)
+ if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] == 0)
break;
dte_facs->calling_len = p[2];
memcpy(dte_facs->calling_ae, &p[3], p[1] - 1);
*vc_fac_mask |= X25_MASK_CALLING_AE;
break;
case X25_FAC_CALLED_AE:
- if (p[1] > X25_MAX_DTE_FACIL_LEN)
+ if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] == 0)
break;
dte_facs->called_len = p[2];
memcpy(dte_facs->called_ae, &p[3], p[1] - 1);
^ permalink raw reply
* Re: [PATCH] bluetooth: bnep: fix information leak to userland
From: Marcel Holtmann @ 2010-11-02 15:35 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Gustavo F. Padovan,
David S. Miller, Eric Dumazet, Thadeu Lima de Souza Cascardo,
Tejun Heo, Jiri Kosina, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1288448782-5582-1-git-send-email-segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Vasiiy,
> Structure bnep_conninfo is copied to userland with the field "device"
> that has the last elements unitialized. It leads to leaking of
> contents of kernel stack memory.
>
> Signed-off-by: Vasiliy Kulikov <segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] bluetooth: cmtp: fix information leak to userland
From: Marcel Holtmann @ 2010-11-02 15:35 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, Gustavo F. Padovan, David S. Miller,
Eric Dumazet, linux-bluetooth, netdev, linux-kernel
In-Reply-To: <1288448787-5848-1-git-send-email-segooon@gmail.com>
Hi Vasiliy,
> Structure cmtp_conninfo is copied to userland with some padding fields
> unitialized. It leads to leaking of contents of kernel stack memory.
>
> Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] bluetooth: hidp: fix information leak to userland
From: Marcel Holtmann @ 2010-11-02 15:36 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA, Gustavo F. Padovan,
David S. Miller, Jiri Kosina, Michael Poole, Bastien Nocera,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1288448791-6009-1-git-send-email-segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Vasiliy,
> Structure hidp_conninfo is copied to userland with version, product,
> vendor and name fields unitialized if both session->input and session->hid
> are NULL. It leads to leaking of contents of kernel stack memory.
>
> Signed-off-by: Vasiliy Kulikov <segooon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] virtio_net: Fix queue full check
From: Michael S. Tsirkin @ 2010-11-02 16:17 UTC (permalink / raw)
To: Rusty Russell; +Cc: Krishna Kumar2, davem, netdev, yvugenfi
In-Reply-To: <201010292158.40411.rusty@rustcorp.com.au>
On Fri, Oct 29, 2010 at 09:58:40PM +1030, Rusty Russell wrote:
> On Fri, 29 Oct 2010 09:25:09 pm Krishna Kumar2 wrote:
> > Rusty Russell <rusty@rustcorp.com.au> wrote on 10/29/2010 03:17:24 PM:
> >
> > > > Oct 17 10:22:40 localhost kernel: net eth0: Unexpected TX queue
> > failure: -28
> > > > Oct 17 10:28:22 localhost kernel: net eth0: Unexpected TX queue
> > failure: -28
> > > > Oct 17 10:35:58 localhost kernel: net eth0: Unexpected TX queue
> > failure: -28
> > > > Oct 17 10:41:06 localhost kernel: net eth0: Unexpected TX queue
> > failure: -28
> > > >
> > > > I initially changed the check from -ENOMEM to -ENOSPC, but
> > > > virtqueue_add_buf can return only -ENOSPC when it doesn't have
> > > > space for new request. Patch removes redundant checks but
> > > > displays the failure errno.
> > > >
> > > > Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> > > > ---
> > > > drivers/net/virtio_net.c | 15 ++++-----------
> > > > 1 file changed, 4 insertions(+), 11 deletions(-)
> > > >
> > > > diff -ruNp org/drivers/net/virtio_net.c new/drivers/net/virtio_net.c
> > > > --- org/drivers/net/virtio_net.c 2010-10-11 10:20:02.000000000 +0530
> > > > +++ new/drivers/net/virtio_net.c 2010-10-21 17:37:45.000000000 +0530
> > > > @@ -570,17 +570,10 @@ static netdev_tx_t start_xmit(struct sk_
> > > >
> > > > /* This can happen with OOM and indirect buffers. */
> > > > if (unlikely(capacity < 0)) {
> > > > - if (net_ratelimit()) {
> > > > - if (likely(capacity == -ENOMEM)) {
> > > > - dev_warn(&dev->dev,
> > > > - "TX queue failure: out of memory\n");
> > > > - } else {
> > > > - dev->stats.tx_fifo_errors++;
> > > > - dev_warn(&dev->dev,
> > > > - "Unexpected TX queue failure: %d\n",
> > > > - capacity);
> > > > - }
> > > > - }
> > > > + if (net_ratelimit())
> > > > + dev_warn(&dev->dev,
> > > > + "TX queue failure (%d): out of memory\n",
> > > > + capacity);
> > >
> > > Hold on... you were getting -ENOSPC, which shouldn't happen. What makes
> > you
> > > think it's out of memory?
> >
> > virtqueue_add_buf_gfp returns only -ENOSPC on failure, whether
> > direct or indirect descriptors are used, so isn't -ENOSPC
> > "expected"? (vring_add_indirect returns -ENOMEM on memory
> > failure, but that is masked out and we go direct which is
> > the failure point).
>
> Ah, OK, gotchya.
> I'm not even sure the fallback to linear makes sense; if we're failing
> kmallocs we should probably just return -ENOMEM. Would mean we can
> tell the difference between "out of space" (which should never happen
> since we stop the queue when we have < 2+MAX_SKB_FRAGS slots left)
> and this case.
>
> Michael, what do you think?
>
> Thanks,
> Rusty.
Let's make sure I understand the issue: we use indirect buffers
so we assume there's still a lot of place in the ring, then
allocation for the indirect fails and so we return -ENOSPC?
So first, I agree it's a bug. But I am not sure killing the fallback
is such a good idea: recovering from add buf failure is hard
generally, we should try to accomodate if we can. Let's just fix
the return code for now?
And generally, we should be smarter: as long as the ring is almost
empty, and s/g list is short, it is a waste to use indirect buffers.
BTW we have had a FIXME there for a long while, I think Yan suggested
increasing that threshold to 3. Yan?
Further, maybe preallocating some memory for the indirect buffers might
be a good idea.
In short, lots of good ideas, let's start with the minimal patch that is
a good 2.6.37 candidate too. How about the following (untested)?
virtio: fix add_buf return code for OOM
add_buff returned ENOSPC on out of memory: this is a bug
as at leats virtio-net expects ENOMEM and handles it
specially. Fix that.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 1475ed6..0a89098 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -165,7 +165,7 @@ int virtqueue_add_buf_gfp(struct virtqueue *_vq,
{
struct vring_virtqueue *vq = to_vvq(_vq);
unsigned int i, avail, uninitialized_var(prev);
- int head;
+ int head = -ENOSPC;
START_USE(vq);
@@ -191,7 +191,7 @@ int virtqueue_add_buf_gfp(struct virtqueue *_vq,
if (out)
vq->notify(&vq->vq);
END_USE(vq);
- return -ENOSPC;
+ return head;
}
/* We're about to use some buffers from the free list. */
--
MST
^ permalink raw reply related
* [SECURITY] CAN info leak/minor heap overflow
From: Dan Rosenberg @ 2010-11-02 18:28 UTC (permalink / raw)
To: socketcan, oliver.hartkopp, urs.thuermann; +Cc: netdev, security
In bcm_connect() (in net/can/bcm.c), I noticed the following code:
sprintf(bo->procname, "%p", sock);
"procname" is a 9-byte char array. This code is wrong on two levels.
First, leaking a kernel address via a /proc filename is bad. Secondly,
on 64-bit platforms, up to 17 bytes may be copied into the buffer.
Fortunately, structure padding will most likely prevent this from being
a problem, except for the trailing NULL byte, which may overwrite the
first byte of the next heap object. Please name your procfile in a way
that doesn't leak information and fits into the desired name buffer.
-Dan
^ permalink raw reply
* Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device
From: Michael S. Tsirkin @ 2010-11-02 18:42 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: kaber, Arnd Bergmann, netdev, kvm@vger.kernel.org
In-Reply-To: <4CD05621.6000706@us.ibm.com>
On Tue, Nov 02, 2010 at 11:19:13AM -0700, Sridhar Samudrala wrote:
> On Mon, 2010-11-01 at 10:28 +0200, Michael S. Tsirkin wrote:
>
> On Tue, Oct 26, 2010 at 03:19:38PM -0700, Sridhar Samudrala wrote:
> > With the current default macvtap mode, a KVM guest using virtio with
> > macvtap backend has the following limitations.
> > - cannot change/add a mac address on the guest virtio-net
> > - cannot create a vlan device on the guest virtio-net
> > - cannot enable promiscuous mode on guest virtio-net
> >
> > This patch introduces a new mode called 'passthru' when creating a
> > macvlan device which allows takeover of the underlying device and
> > passing it to a guest using virtio with macvtap backend.
> >
> > Only one macvlan device is allowed in passthru mode and it inherits
> > the mac address from the underlying device and sets it in promiscuous
> > mode to receive and forward all the packets.
> >
> > Thanks
> > Sridhar
>
> One concern with promisc mode is that for the common case,
> which is a single mac and no vlans, we will be getting
> extra packets that will get dropped in userspace/guest
> as compared to the case where same mac is programmed
> in hardware and by guest.
>
> In the tap/bridge model also, the external i/f is put in promiscuous mode and
> the
> bridge does the filtering of extra packets.
Yes but
1. that is much cheaper than passing them all the way up to the guest.
2. it's pretty painful for management to have to decide between
features and speed. Better give them both :)
> We could let userspace supply a list of mac/vlan addresses through
> an ioctl on macvtap, and then
> 1. for a single mac, program it in hardware
> 2. for other configurations, set promisc mode
>
> tun already has TUNSETTXFILTER which might come in handy here.
> We don't pass in vlans with the filter now but maybe we should.
> How does this sound?
>
> I guess this can be done. But i am not sure if we can extend the existing
> TUNSETTXFILTER
> to support vlans too. we may need a new ioctl.
>
> Thanks
> Sridhar
OK. Maybe add it to tap too.
--
MST
^ permalink raw reply
* Re: Routing over multiple interfaces
From: Bandan Das @ 2010-11-02 18:47 UTC (permalink / raw)
To: David Miller; +Cc: dwmw2, netdev, uweber
In-Reply-To: <20101101.141638.116372747.davem@davemloft.net>
On 0, David Miller <davem@davemloft.net> wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Mon, 01 Nov 2010 17:12:02 -0400
>
> > But when I do a large upload, I find that the kernel is only ever using
> > a *single* link at a time, rather than both. How can I make it use
> > *both* links? It's fine to confine each flow to a single link if it
> > doesn't saturate that link... but once the queue is full, it should
> > overflow onto the other device.
>
> Once a TCP socket gets a routing cache entry, that's what it uses
> for the rest of the life of the connection.
>
> The multi-pathing decision happens at the time the routing
> cache entry is created.
>
> What you want is multi-path routing support in the routing cache.
>
> We used to have that, but the guy who implemented it (after bugging
> me to integrate it for 4 months straight, non-stop) just did a code
> dump and then disappeared and fixed none of the serious fundamental
> problems which existed in his code.
You are talking about the equalize patch, right ?
I had a similar requirement once a long time back and I didn't
know of any other way to do it, so, I just "forced" this patch
on a 2.6.23 kernel.
David W, may be you can take a look just to get an idea..
http://th.oughts.org/equalize_2.6_0.3.patch
Bandan
^ permalink raw reply
* Re: [SECURITY] CAN info leak/minor heap overflow
From: Oliver Hartkopp @ 2010-11-02 19:43 UTC (permalink / raw)
To: Dan Rosenberg; +Cc: urs.thuermann, netdev, security
In-Reply-To: <1288722503.2504.14.camel@dan>
Hello Dan,
On 02.11.2010 19:28, Dan Rosenberg wrote:
> In bcm_connect() (in net/can/bcm.c), I noticed the following code:
>
> sprintf(bo->procname, "%p", sock);
>
> "procname" is a 9-byte char array. This code is wrong on two levels.
> First, leaking a kernel address via a /proc filename is bad.
Why is this bad? Can the addresses of CAN-BCM sock structs be used for
anything from userspace?
For me they are just intented to be unique numbers ...
> Secondly,
> on 64-bit platforms, up to 17 bytes may be copied into the buffer.
Hm - that's indeed not wanted. Will send a patch at least for this issue.
> Fortunately, structure padding will most likely prevent this from being
> a problem, except for the trailing NULL byte, which may overwrite the
> first byte of the next heap object. Please name your procfile in a way
> that doesn't leak information and fits into the desired name buffer.
>
> -Dan
>
Regards,
Oliver
^ permalink raw reply
* Re: Routing over multiple interfaces
From: Pascal Hambourg @ 2010-11-02 19:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dwmw2, netdev
In-Reply-To: <1288647330.2660.116.camel@edumazet-laptop>
Hello,
Eric Dumazet a écrit :
>
> David W. probably wants to use teql or some bonding ?
I doubt that (ethernet) bonding works with PPP links.
> # tc qdisc add dev ppp0 root teql0
> # tc qdisc add dev ppp1 root teql0
> # ip link set dev teql0 up
> # ip route add default src 90.155.92.214 dev teql0
What about using iptables + routing rules ?
Mark every other packet going through the default PPP link with
iptables, and reroute marked packets through the other PPP link.
^ permalink raw reply
* Re: [SECURITY] CAN info leak/minor heap overflow
From: Dan Rosenberg @ 2010-11-02 19:53 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: netdev, security
In-Reply-To: <4CD069D4.7010801@hartkopp.net>
> Why is this bad? Can the addresses of CAN-BCM sock structs be used for
> anything from userspace?
>
> For me they are just intented to be unique numbers ...
>
This is a bad idea because it makes exploiting other kernel
vulnerabilities easier. Exposing the address of an object in a slab
cache, especially an object that unprivileged users have some level of
control of, is just an invitation to use that structure when writing
exploits, for heap overflows or otherwise.
-Dan
> > Secondly,
> > on 64-bit platforms, up to 17 bytes may be copied into the buffer.
>
> Hm - that's indeed not wanted. Will send a patch at least for this issue.
>
> > Fortunately, structure padding will most likely prevent this from being
> > a problem, except for the trailing NULL byte, which may overwrite the
> > first byte of the next heap object. Please name your procfile in a way
> > that doesn't leak information and fits into the desired name buffer.
> >
> > -Dan
> >
>
> Regards,
> Oliver
^ permalink raw reply
* Re: [Security] [SECURITY] CAN info leak/minor heap overflow
From: Linus Torvalds @ 2010-11-02 19:57 UTC (permalink / raw)
To: Dan Rosenberg; +Cc: Oliver Hartkopp, netdev, security
In-Reply-To: <1288727605.2504.21.camel@dan>
On Tue, Nov 2, 2010 at 3:53 PM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
>
>> Why is this bad? Can the addresses of CAN-BCM sock structs be used for
>> anything from userspace?
>>
>> For me they are just intented to be unique numbers ...
>>
>
> This is a bad idea because it makes exploiting other kernel
> vulnerabilities easier. Exposing the address of an object in a slab
> cache, especially an object that unprivileged users have some level of
> control of, is just an invitation to use that structure when writing
> exploits, for heap overflows or otherwise.
Indeed. At the very least, hash them and truncate them with some
secret per-boot value or something. Even better, use something like a
socket number so that maybe they can be associated with
/proc/<xyz>/fd/<x> or other system info if somebody were to care.
Linus
^ permalink raw reply
* VERY IMPORTANT( WILL) CONTACT BROWNE JACOBSON Esq!!!
From: Vohra, Jitendra K @ 2010-11-02 19:36 UTC (permalink / raw)
Late Mr. Christopher Friedrich bequeathed US$20, 500,000.00 USD, to you in his will. More info,contact your attorney(Browne Jacobson Esq.) via email address; brownejacobson8002@yahoo.com.hk<mailto:brownejacobson8002@yahoo.com.hk>
^ permalink raw reply
* Re: Routing over multiple interfaces
From: Eric Dumazet @ 2010-11-02 20:04 UTC (permalink / raw)
To: Pascal Hambourg; +Cc: dwmw2, netdev
In-Reply-To: <4CD06AA4.6090005@plouf.fr.eu.org>
Le mardi 02 novembre 2010 à 20:46 +0100, Pascal Hambourg a écrit :
> Hello,
>
> Eric Dumazet a écrit :
> >
> > David W. probably wants to use teql or some bonding ?
>
> I doubt that (ethernet) bonding works with PPP links.
>
Well, I was asking if some ppp bonding was possible. I am not a ppp
user.
> > # tc qdisc add dev ppp0 root teql0
> > # tc qdisc add dev ppp1 root teql0
> > # ip link set dev teql0 up
> > # ip route add default src 90.155.92.214 dev teql0
>
> What about using iptables + routing rules ?
> Mark every other packet going through the default PPP link with
> iptables, and reroute marked packets through the other PPP link.
OK. I provided a working setup, maybe you also could provide one based
on iptables as well ?
^ permalink raw reply
* Re: [SECURITY] CAN info leak/minor heap overflow
From: Oliver Hartkopp @ 2010-11-02 20:16 UTC (permalink / raw)
To: Dan Rosenberg; +Cc: netdev, security
In-Reply-To: <1288727605.2504.21.camel@dan>
On 02.11.2010 20:53, Dan Rosenberg wrote:
>
>> Why is this bad? Can the addresses of CAN-BCM sock structs be used for
>> anything from userspace?
>>
>> For me they are just intended to be unique numbers ...
>>
>
> This is a bad idea because it makes exploiting other kernel
> vulnerabilities easier. Exposing the address of an object in a slab
> cache, especially an object that unprivileged users have some level of
> control of, is just an invitation to use that structure when writing
> exploits, for heap overflows or otherwise.
The "level of control of" is just creating a socket or not. None of the data
in the created struct can be influenced by an unprivileged user.
Btw. i can generally follow your concerns after this explanation.
I'm going to check the kernel src for other approaches to display unique
numbers in procfs and will send a patch that takes care.
Thanks,
Oliver
^ permalink raw reply
* Re: [Security] [SECURITY] CAN info leak/minor heap overflow
From: Oliver Hartkopp @ 2010-11-02 20:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dan Rosenberg, netdev, security
In-Reply-To: <AANLkTi=EcAQ0u_wYAnVkvV_Ve9in4z2Es5h1pBbyMeXe@mail.gmail.com>
On 02.11.2010 20:57, Linus Torvalds wrote:
> On Tue, Nov 2, 2010 at 3:53 PM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
>>
>>> Why is this bad? Can the addresses of CAN-BCM sock structs be used for
>>> anything from userspace?
>>>
>>> For me they are just intented to be unique numbers ...
>>>
>>
>> This is a bad idea because it makes exploiting other kernel
>> vulnerabilities easier. Exposing the address of an object in a slab
>> cache, especially an object that unprivileged users have some level of
>> control of, is just an invitation to use that structure when writing
>> exploits, for heap overflows or otherwise.
>
> Indeed. At the very least, hash them and truncate them with some
> secret per-boot value or something. Even better, use something like a
> socket number so that maybe they can be associated with
> /proc/<xyz>/fd/<x> or other system info if somebody were to care.
Good hint!
Will pick this idea.
Thanks,
Oliver
^ permalink raw reply
* Re: Routing over multiple interfaces
From: Arnd Hannemann @ 2010-11-02 22:10 UTC (permalink / raw)
To: David Miller; +Cc: dwmw2, netdev, uweber
In-Reply-To: <20101101.141638.116372747.davem@davemloft.net>
Am 01.11.2010 22:16, schrieb David Miller:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Mon, 01 Nov 2010 17:12:02 -0400
>
>> But when I do a large upload, I find that the kernel is only ever using
>> a *single* link at a time, rather than both. How can I make it use
>> *both* links? It's fine to confine each flow to a single link if it
>> doesn't saturate that link... but once the queue is full, it should
>> overflow onto the other device.
>
> Once a TCP socket gets a routing cache entry, that's what it uses
> for the rest of the life of the connection.
>
> The multi-pathing decision happens at the time the routing
> cache entry is created.
You should be able to come a solution with netfilter (probably not so efficient):
iptables -t mangle -A PREROUTING -d $EXTERNAL -m statistic --mode nth --every 2 -j MARK --set-mark 6
ip rule add fwmark 6 table ppp1
ip route replace $EXTERNAL via $PPP0GW
ip route replace $EXTERNAL via $PPP1GW table ppp1
Regards,
Arnd
^ permalink raw reply
* MS_L2009
From: (ms-world) @ 2010-11-02 23:11 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: YOU HAVE WON A PRIZE-1 (Recovered).docx --]
[-- Type: application/octet-stream, Size: 159614 bytes --]
^ permalink raw reply
* Re: Routing over multiple interfaces
From: Pascal Hambourg @ 2010-11-02 22:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dwmw2, netdev
In-Reply-To: <1288728267.2467.4.camel@edumazet-laptop>
Eric Dumazet a écrit :
> Le mardi 02 novembre 2010 à 20:46 +0100, Pascal Hambourg a écrit :
>
>> What about using iptables + routing rules ?
>> Mark every other packet going through the default PPP link with
>> iptables, and reroute marked packets through the other PPP link.
>
> OK. I provided a working setup, maybe you also could provide one based
> on iptables as well ?
Arnd Hannemann provided something quite close to what I was thinking
about. I would just make a few adjustments. I added a rule for locally
generated traffic if needed. Also, using the PPP peer as gateway could
be troublesome if both links have the same peer address, so I used the
device instead.
iptables -t mangle -N mark6
iptables -t mangle -A mark6 -m statistic --mode nth --every 2 -j MARK
--set-mark 6
# forwarded traffic, $LANDEV is the interface connected to the LAN
iptables -t mangle -A PREROUTING -i $LANDEV -j mark6
# locally generated traffic to the PPP link
iptables -t mangle -A OUTPUT -o ppp0 -j mark6
ip rule add fwmark 6 table ppp1
ip route replace default dev ppp0
ip route replace default dev ppp1 table ppp1
It still needs some refinements such as excluding non-external
destinations from the PREROUTING rule. Your setup seems much simpler and
efficient.
^ 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