RE: [PATCH] audit: always follow va_copy() with va_end()

RE: [PATCH] audit: always follow va_copy() with va_end()

[Eric Paris]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

This one was committed to my audit tree which al promised to pull all of my audit tree into the vfs tree for 3.3, so if you want to take it Linus, you can add my ack as the maintainer. I'd expect to see it from Al early this week. Can't say anything about SCSI though...


-----Original Message-----
From: Jesper Juhl [jj@chaosbits.net]
Received: Sunday, 08 Jan 2012, 4:44pm
To: Linus Torvalds [torvalds@linux-foundation.org]
CC: Linux Kernel Mailing List [linux-kernel@vger.kernel.org]; Andrew Morton [akpm@linux-foundation.org]; Al Viro [viro@zeniv.linux.org.uk]; Eric Paris [eparis@redhat.com]
Subject: [PATCH] audit: always follow va_copy() with va_end()


A call to va_copy() should always be followed by a call to va_end() in the
same function.  In kernel/autit.c::audit_log_vformat() this is not always
done.  This patch makes sure va_end() is always called.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 kernel/audit.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 09fae26..2c1d6ab 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1260,12 +1260,13 @@ static void audit_log_vformat(struct audit_buffer *ab, const char *fmt,
 		avail = audit_expand(ab,
 			max_t(unsigned, AUDIT_BUFSIZ, 1+len-avail));
 		if (!avail)
-			goto out;
+			goto out_va_end;
 		len = vsnprintf(skb_tail_pointer(skb), avail, fmt, args2);
 	}
-	va_end(args2);
 	if (len > 0)
 		skb_put(skb, len);
+out_va_end:
+	va_end(args2);
 out:
 	return;
 }
-- 
1.7.8.1


-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: [PATCH] audit: always follow va_copy() with va_end()

[Al Viro]

On Sun, Jan 08, 2012 at 07:53:51PM -0500, Eric Paris wrote:
> This one was committed to my audit tree which al promised to pull all of my audit tree into the vfs tree for 3.3, so if you want to take it Linus, you can add my ack as the maintainer. I'd expect to see it from Al early this week. Can't say anything about SCSI though...

s/vfs/recreated audit/; should've done that a month or so ago.  Will do
tonight...

Re: [PATCH] audit: always follow va_copy() with va_end()

[Xi Wang]

On Jan 8, 2012, at 7:53 PM, Eric Paris wrote:
> This one was committed to my audit tree which al promised to pull all of my audit tree into the vfs tree for 3.3, so if you want to take it Linus, you can add my ack as the maintainer. I'd expect to see it from Al early this week. Can't say anything about SCSI though...

Could you please also take a look at another simple audit fix or
should I resend the patch again?  Thanks a lot.

https://lkml.org/lkml/2011/12/20/379

Please merge two small bug fix patches from linux-next

[Jesper Juhl]

Hi Linus

Below are two patches that have been in linux-next for ages (via akpm's 
tree). They are prette simple, straight-up, bug fixes. They have been 
submitted to maintainers multiple times over (IIRC at least the past 
year), but for some reason the maintainers seem uninterested in picking 
them up (or even responding to them).
There has been no negative comments at all to them while they have been in 
-next.
I'd really appreciate it if they could get merged.

I've just pulled them out of the current linux-next and applied them on 
top of your tree - that's what is below.



From: Jesper Juhl <jj@chaosbits.net>
Date: Thu, 22 Dec 2011 16:03:46 +1100
Subject: drivers/scsi/aacraid/commctrl.c: fix mem leak in aac_send_raw_srb()

We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :

We allocate memory:
        ...
                        struct user_sgmap* usg;
                        usg = kmalloc(actual_fibsize - sizeof(struct aac_srb)
                          + sizeof(struct sgmap), GFP_KERNEL);
and then neglect to free it:
        ...
                        for (i = 0; i < usg->count; i++) {
                                u64 addr;
                                void* p;
                                if (usg->sg[i].count >
                                    ((dev->adapter_info.options &
                                     AAC_OPT_NEW_COMM) ?
                                      (dev->scsi_host_ptr->max_sectors << 9) :
                                      65536)) {
                                        rcode = -EINVAL;
                                        goto cleanup;
        ... this 'goto' makes 'usg' go out of scope and leak the memory we
            allocated.
            Other exits properly kfree(usg), it's just here it is neglected.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
 drivers/scsi/aacraid/commctrl.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 8a0b330..0bd38da 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -650,6 +650,7 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg)
 				     AAC_OPT_NEW_COMM) ?
 				      (dev->scsi_host_ptr->max_sectors << 9) :
 				      65536)) {
+					kfree(usg);
 					rcode = -EINVAL;
 					goto cleanup;
 				}
-- 
1.7.8.1



From: Jesper Juhl <jj@chaosbits.net>
Date: Thu, 22 Dec 2011 16:04:13 +1100
Subject: audit: always follow va_copy() with va_end()

A call to va_copy() should always be followed by a call to va_end() in the
same function.  In kernel/autit.c::audit_log_vformat() this is not always
done.  This patch makes sure va_end() is always called.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jesper Juhl <jj@codesealer.com>
---
 kernel/audit.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 09fae26..2c1d6ab 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1260,12 +1260,13 @@ static void audit_log_vformat(struct audit_buffer *ab, const char *fmt,
 		avail = audit_expand(ab,
 			max_t(unsigned, AUDIT_BUFSIZ, 1+len-avail));
 		if (!avail)
-			goto out;
+			goto out_va_end;
 		len = vsnprintf(skb_tail_pointer(skb), avail, fmt, args2);
 	}
-	va_end(args2);
 	if (len > 0)
 		skb_put(skb, len);
+out_va_end:
+	va_end(args2);
 out:
 	return;
 }
-- 
1.7.8.1



-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

Re: Please merge two small bug fix patches from linux-next

[Linus Torvalds]

On Sun, Jan 8, 2012 at 11:51 AM, Jesper Juhl <jj@chaosbits.net> wrote:
>
> Below are two patches that have been in linux-next for ages (via akpm's
> tree). They are prette simple, straight-up, bug fixes. They have been
> submitted to maintainers multiple times over (IIRC at least the past
> year), but for some reason the maintainers seem uninterested in picking
> them up (or even responding to them).
> There has been no negative comments at all to them while they have been in
> -next.
> I'd really appreciate it if they could get merged.
>
> I've just pulled them out of the current linux-next and applied them on
> top of your tree - that's what is below.

So where are they? Git tree or what?

And if you want me to apply them as patches, please send them as
proper individual patches instead of askng me to "merge" them.

And they seem to have Andrew's sign-off, so I'd have expected them to
come through Andew. What's up?

                      Linus

Re: Please merge two small bug fix patches from linux-next

[Jesper Juhl]

On Sun, 8 Jan 2012, Linus Torvalds wrote:

> On Sun, Jan 8, 2012 at 11:51 AM, Jesper Juhl <jj@chaosbits.net> wrote:
> >
> > Below are two patches that have been in linux-next for ages (via akpm's
> > tree). They are prette simple, straight-up, bug fixes. They have been
> > submitted to maintainers multiple times over (IIRC at least the past
> > year), but for some reason the maintainers seem uninterested in picking
> > them up (or even responding to them).
> > There has been no negative comments at all to them while they have been in
> > -next.
> > I'd really appreciate it if they could get merged.
> >
> > I've just pulled them out of the current linux-next and applied them on
> > top of your tree - that's what is below.
> 
> So where are they? Git tree or what?
> 
> And if you want me to apply them as patches, please send them as
> proper individual patches instead of askng me to "merge" them.
> 
> And they seem to have Andrew's sign-off, so I'd have expected them to
> come through Andew. What's up?
> 

What's up is this: I'd submitted them a few times to the mailing list and 
maintainers in the distant past. Andrew ended up picking them up when 
maintainers didn't. Through him they made it into the linux-next tree and 
have been living in Andrews queue and -next ever since. 

I simply got fed up with seeing them in -next and getting nowhere, and 
thought that if the maintainers won't pick them up maybe you would just 
take them directly now since it's been ages and they have not gotten any 
negative feedback and a merge window is open.

Andrew added his signed-off-by when he took them into his queue, I 
retained that when I grabbed the patches into a mainline git clone from 
-next, but I can just drop those if that's inappropriate.

I should not have said "merge" in the subject - my bad.

I'll send them as two individual patches by mail (unless you prefer a git 
tree, then I can easily set that up as well).


-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

[PATCH] audit: always follow va_copy() with va_end()

[Jesper Juhl]

A call to va_copy() should always be followed by a call to va_end() in the
same function.  In kernel/autit.c::audit_log_vformat() this is not always
done.  This patch makes sure va_end() is always called.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric Paris <eparis@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 kernel/audit.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 09fae26..2c1d6ab 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1260,12 +1260,13 @@ static void audit_log_vformat(struct audit_buffer *ab, const char *fmt,
 		avail = audit_expand(ab,
 			max_t(unsigned, AUDIT_BUFSIZ, 1+len-avail));
 		if (!avail)
-			goto out;
+			goto out_va_end;
 		len = vsnprintf(skb_tail_pointer(skb), avail, fmt, args2);
 	}
-	va_end(args2);
 	if (len > 0)
 		skb_put(skb, len);
+out_va_end:
+	va_end(args2);
 out:
 	return;
 }
-- 
1.7.8.1


-- 
Jesper Juhl <jj@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.