[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Sep 2011 09:39:21 +0200
From: Petr Matousek <pmatouse@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Marcus Meissner <meissner@...e.de>
Subject: Re: CVE Request: OFED 1.5.2 /proc/net/sdpstats
reading local denial of service/crash
On Tue, Sep 06, 2011 at 11:40:43PM +0200, Marcus Meissner wrote:
> One of our customers reported an issue in the "ib_sdp" module in the
> ofa_kernel package of the Open Fabrics OFED Infiband driverstack, version
> 1.5.2 (and potentially older, I did not check in detail, at least 1.4.2
> does not have it).
>
> Module is drivers/infiniband/ulp/sdp/ib_sdp.ko
>
> /proc/net/sdpstats is user readable (S_IRUGO | S_IWUGO), so it can be
> triggered by users on machines with infiniband stack.
>
> While there is report of stack corruption and overflow on process (cat
> /proc/net/sdpstats) exit ("Thread overran stack, or stack corrupted"),
> I can't see where it actually comes from but perhaps the per_cpu vs
> single variable printing does something to the stack and not just reads
> over arrays.
#define __sdpstats_seq_hist_pcpu(seq, msg, hist) ({ \
u32 h[NR_CPUS]; \
unsigned int __i; \
memset(h, 0, sizeof(h)); \
NR_CPUS can be big (4096 on RHEL6@..._64) and the array is located on
the stack.
> ofed 1.5.3.2 has a different stat printing algorith according to our developer,
> so it no longer is affected.
The array ^^^ is no longer allocated from the stack but via vmalloc().
> Patch below. Please assign a CVE.
Please use CVE-2011-3345.
Thanks,
--
Petr Matousek / Red Hat Security Response Team
>
> Ciao, Marcus
>
> From: Goldwyn Rodrigues <rgoldwyn@...e.de>
> Subject: [PATCH] Correct /proc/net/sdpstats variables
>
> A couple of variables are treated as arrays while printing
> /proc/net/sdpstats, while they are actually single variables.
> This leads to stack/memory corruption and a kernel crash.
> Correct dealing of these variables in sdpstats_seq_show()
>
> ---
> drivers/infiniband/ulp/sdp/sdp_proc.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> Index: ofa_kernel-1.5.2/drivers/infiniband/ulp/sdp/sdp_proc.c
> ===================================================================
> --- ofa_kernel-1.5.2.orig/drivers/infiniband/ulp/sdp/sdp_proc.c 2010-09-21 17:51:32.000000000 +0200
> +++ ofa_kernel-1.5.2/drivers/infiniband/ulp/sdp/sdp_proc.c 2011-07-22 15:09:14.000000000 +0200
> @@ -341,6 +341,7 @@ static int sdpstats_seq_show(struct seq_
> seq_printf(seq, "- RX int queue \t\t: %d\n", SDPSTATS_COUNTER_GET(rx_int_queue));
> seq_printf(seq, "- RX int no op \t\t: %d\n", SDPSTATS_COUNTER_GET(rx_int_no_op));
> seq_printf(seq, "- RX cq modified\t\t: %d\n", SDPSTATS_COUNTER_GET(rx_cq_modified));
> + seq_printf(seq, "- RX wq\t\t: %d\n", SDPSTATS_COUNTER_GET(rx_wq));
>
> seq_printf(seq, "- TX irq armed\t\t: %d\n", SDPSTATS_COUNTER_GET(tx_int_arm));
> seq_printf(seq, "- TX interrupts\t\t: %d\n", SDPSTATS_COUNTER_GET(tx_int_count));
> @@ -352,12 +353,6 @@ static int sdpstats_seq_show(struct seq_
> seq_printf(seq, "- TX error\t\t: %d\n", SDPSTATS_COUNTER_GET(zcopy_tx_error));
> seq_printf(seq, "- FMR alloc error\t: %d\n", SDPSTATS_COUNTER_GET(fmr_alloc_error));
>
> - __sdpstats_seq_hist_pcpu(seq, "CPU sendmsg", sendmsg);
> - __sdpstats_seq_hist_pcpu(seq, "CPU recvmsg", recvmsg);
> - __sdpstats_seq_hist_pcpu(seq, "CPU rx_irq", rx_int_count);
> - __sdpstats_seq_hist_pcpu(seq, "CPU rx_wq", rx_wq);
> - __sdpstats_seq_hist_pcpu(seq, "CPU tx_irq", tx_int_count);
> -
> return 0;
> }
>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
