xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.
Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner <[email protected]>
---
drivers/usb/host/xhci-mem.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 487bc08..420ba37 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -205,7 +205,11 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
next = xhci_segment_alloc(xhci, cycle_state, flags);
if (!next) {
- xhci_free_segments_for_ring(xhci, *first);
+ prev = *first;
+ do {
+ next = prev->next;
+ xhci_segment_free(xhci, prev);
+ } while ((prev = next));
return -ENOMEM;
}
xhci_link_segments(xhci, prev, next, type);
@@ -258,7 +262,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
return ring;
fail:
- xhci_ring_free(xhci, ring);
+ kfree(ring);
return NULL;
}
--
1.7.8.6
Hello.
On 10/29/2012 08:00 PM, Julius Werner wrote:
> xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
> the tail to head at the end (forming a ring). When it bails out for OOM
> reasons half-way through, it tries to destroy its half-built list with
> xhci_free_segments_for_ring(), even though it is not a ring yet. This
> causes a null-pointer dereference upon hitting the last element.
> Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
> the output parameters to be valid upon this kind of OOM failure, and
> calls xhci_ring_free() on them. Since the (incomplete) list/ring should
> already be destroyed in that case, this would lead to a use after free.
> This patch fixes those issues by having xhci_alloc_segments_for_ring()
> destroy its half-built, non-circular list manually and destroying the
> invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
> Signed-off-by: Julius Werner <[email protected]>
> ---
> drivers/usb/host/xhci-mem.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 487bc08..420ba37 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -205,7 +205,11 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
>
> next = xhci_segment_alloc(xhci, cycle_state, flags);
> if (!next) {
> - xhci_free_segments_for_ring(xhci, *first);
> + prev = *first;
> + do {
> + next = prev->next;
> + xhci_segment_free(xhci, prev);
> + } while ((prev = next));
It's preferred that the assignments are done outside the *if* and *while*
statements. In fact, at least for the *if* statements scripts/checkpatch.pl
gives a warning (it was silent in this case).
> return -ENOMEM;
> }
> xhci_link_segments(xhci, prev, next, type);
> @@ -258,7 +262,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
> return ring;
>
> fail:
> - xhci_ring_free(xhci, ring);
> + kfree(ring);
> return NULL;
> }
[headless@wasted linux]$ scripts/checkpatch.pl
patches/xhci-fix-null-pointer-dereference-when-destroying-half-built-segment-rings.patch
ERROR: DOS line endings
#30: FILE: drivers/usb/host/xhci-mem.c:208:
+^I^I^Iprev = *first;^M$
ERROR: DOS line endings
#31: FILE: drivers/usb/host/xhci-mem.c:209:
+^I^I^Ido {^M$
ERROR: DOS line endings
#32: FILE: drivers/usb/host/xhci-mem.c:210:
+^I^I^I^Inext = prev->next;^M$
ERROR: DOS line endings
#33: FILE: drivers/usb/host/xhci-mem.c:211:
+^I^I^I^Ixhci_segment_free(xhci, prev);^M$
ERROR: DOS line endings
#34: FILE: drivers/usb/host/xhci-mem.c:212:
+^I^I^I} while ((prev = next));^M$
ERROR: DOS line endings
#43: FILE: drivers/usb/host/xhci-mem.c:265:
+^Ikfree(ring);^M$
total: 6 errors, 0 warnings, 20 lines checked
patches/xhci-fix-null-pointer-dereference-when-destroying-half-built-segment-rings.patch
has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
I have noticed that the patch description has DOS line endings as well.
WBR, Sergei
> I have noticed that the patch description has DOS line endings as well.
Sorry about those, Gmail adds them automatically. According to RFC
2046 (section 4.1.1), text/plain content must use CRLFs to encode line
breaks, so I guess this is the right thing. Your MUA should be
responsible for converting them to native endings upon retrieval (and
if it doesn't, git-am will).
On Mon, Oct 29, 2012 at 09:35:15PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 10/29/2012 08:00 PM, Julius Werner wrote:
> > next = xhci_segment_alloc(xhci, cycle_state, flags);
> > if (!next) {
> > - xhci_free_segments_for_ring(xhci, *first);
> > + prev = *first;
> > + do {
> > + next = prev->next;
> > + xhci_segment_free(xhci, prev);
> > + } while ((prev = next));
>
> It's preferred that the assignments are done outside the *if* and *while*
> statements. In fact, at least for the *if* statements scripts/checkpatch.pl
> gives a warning (it was silent in this case).
Hi Julius,
I agree with Sergei (for once). The assignment in the while conditional
is confusing, and everyone reading the code will wonder if you meant
(prev == next). Putting extra parenthesis around it to avoid static
type checker warnings is kind of missing the point.
Your patch does apply fine with git-am, so don't worry about the line
endings. Can you please move the assignment into the loop and resubmit
this patch?
Sarah Sharp
xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
the tail to head at the end (forming a ring). When it bails out for OOM
reasons half-way through, it tries to destroy its half-built list with
xhci_free_segments_for_ring(), even though it is not a ring yet. This
causes a null-pointer dereference upon hitting the last element.
Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
the output parameters to be valid upon this kind of OOM failure, and
calls xhci_ring_free() on them. Since the (incomplete) list/ring should
already be destroyed in that case, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring()
destroy its half-built, non-circular list manually and destroying the
invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
Signed-off-by: Julius Werner <[email protected]>
---
drivers/usb/host/xhci-mem.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 487bc08..fb51c70 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -205,7 +205,12 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
next = xhci_segment_alloc(xhci, cycle_state, flags);
if (!next) {
- xhci_free_segments_for_ring(xhci, *first);
+ prev = *first;
+ while (prev) {
+ next = prev->next;
+ xhci_segment_free(xhci, prev);
+ prev = next;
+ }
return -ENOMEM;
}
xhci_link_segments(xhci, prev, next, type);
@@ -258,7 +263,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
return ring;
fail:
- xhci_ring_free(xhci, ring);
+ kfree(ring);
return NULL;
}
--
1.7.8.6
On Thu, Nov 1, 2012 at 9:47 PM, Julius Werner <[email protected]> wrote:
> xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
> the tail to head at the end (forming a ring). When it bails out for OOM
> reasons half-way through, it tries to destroy its half-built list with
> xhci_free_segments_for_ring(), even though it is not a ring yet. This
> causes a null-pointer dereference upon hitting the last element.
>
> Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
> the output parameters to be valid upon this kind of OOM failure, and
> calls xhci_ring_free() on them. Since the (incomplete) list/ring should
> already be destroyed in that case, this would lead to a use after free.
>
> This patch fixes those issues by having xhci_alloc_segments_for_ring()
> destroy its half-built, non-circular list manually and destroying the
> invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
>
> Signed-off-by: Julius Werner <[email protected]>
> ---
> drivers/usb/host/xhci-mem.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 487bc08..fb51c70 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -205,7 +205,12 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
>
> next = xhci_segment_alloc(xhci, cycle_state, flags);
> if (!next) {
> - xhci_free_segments_for_ring(xhci, *first);
> + prev = *first;
> + while (prev) {
> + next = prev->next;
> + xhci_segment_free(xhci, prev);
> + prev = next;
> + }
Is it just
for (prev = *first; prev; prev = prev->next)
xhci_segment_free(xhci, prev);
?
> return -ENOMEM;
> }
> xhci_link_segments(xhci, prev, next, type);
> @@ -258,7 +263,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
> return ring;
>
> fail:
> - xhci_ring_free(xhci, ring);
> + kfree(ring);
> return NULL;
> }
>
> --
> 1.7.8.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With Best Regards,
Andy Shevchenko
On Thu, Nov 01, 2012 at 10:13:00PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 1, 2012 at 9:47 PM, Julius Werner <[email protected]> wrote:
> > xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
> > the tail to head at the end (forming a ring). When it bails out for OOM
> > reasons half-way through, it tries to destroy its half-built list with
> > xhci_free_segments_for_ring(), even though it is not a ring yet. This
> > causes a null-pointer dereference upon hitting the last element.
> >
> > Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
> > the output parameters to be valid upon this kind of OOM failure, and
> > calls xhci_ring_free() on them. Since the (incomplete) list/ring should
> > already be destroyed in that case, this would lead to a use after free.
> >
> > This patch fixes those issues by having xhci_alloc_segments_for_ring()
> > destroy its half-built, non-circular list manually and destroying the
> > invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
> >
> > Signed-off-by: Julius Werner <[email protected]>
> > ---
> > drivers/usb/host/xhci-mem.c | 9 +++++++--
> > 1 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> > index 487bc08..fb51c70 100644
> > --- a/drivers/usb/host/xhci-mem.c
> > +++ b/drivers/usb/host/xhci-mem.c
> > @@ -205,7 +205,12 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
> >
> > next = xhci_segment_alloc(xhci, cycle_state, flags);
> > if (!next) {
> > - xhci_free_segments_for_ring(xhci, *first);
> > + prev = *first;
> > + while (prev) {
> > + next = prev->next;
> > + xhci_segment_free(xhci, prev);
> > + prev = next;
> > + }
>
> Is it just
> for (prev = *first; prev; prev = prev->next)
> xhci_segment_free(xhci, prev);
>
> ?
Yeah, that seems cleaner.
Sarah Sharp
>> Is it just
>> for (prev = *first; prev; prev = prev->next)
>> xhci_segment_free(xhci, prev);
>>
>> ?
>
> Yeah, that seems cleaner.
>
> Sarah Sharp
I can submit it that way if you want, but I would advise against it. This way you access the prev pointer after it has been freed already? that's probably not a problem in the current kernel, but it depends on how the underlying memory is managed and is generally just not a good idea in my opinion.-
On Thu, Nov 01, 2012 at 01:28:46PM -0700, Julius Werner wrote:
> >> Is it just
> >> for (prev = *first; prev; prev = prev->next)
> >> xhci_segment_free(xhci, prev);
> >>
> >> ?
> >
> > Yeah, that seems cleaner.
> >
> > Sarah Sharp
>
> I can submit it that way if you want, but I would advise against it. This way you access the prev pointer after it has been freed already… that's probably not a problem in the current kernel, but it depends on how the underlying memory is managed and is generally just not a good idea in my opinion.
Yep, you're right. I'll take the second patch you submitted, thanks.
Sarah Sharp