Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1299898 > unrolled thread

[PATCH] s390: fix normalization bug in exception table sorting

Back to article view | Back to linux.kernel

Contents

  [PATCH] s390: fix normalization bug in exception table sorting Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-01-01 13:40 +0100
    Re: [PATCH] s390: fix normalization bug in exception table sorting Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-01-04 10:50 +0100
    Re: [PATCH] s390: fix normalization bug in exception table sorting Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-01-04 10:50 +0100

#1299898 — [PATCH] s390: fix normalization bug in exception table sorting

The normalization pass in the sorting routine of the relative exception
table serves two purposes:
- it ensures that the address fields of the exception table entries are
  fully ordered, so that no ambiguities arise between entries with
  identical instruction offsets (i.e., when two instructions that are
  exactly 8 bytes apart each have an exception table entry associated with
  them)
- it ensures that the offsets of both the instruction and the fixup fields
  of each entry are relative to their final location after sorting.

Commit eb608fb366de ("s390/exceptions: switch to relative exception table
entries") ported the relative exception table format from x86, but modified
the sorting routine to only normalize the instruction offset field and not
the fixup offset field. The result is that the fixup offset of each entry
will be relative to the original location of the entry before sorting,
likely leading to crashes when those entries are dereferenced.

Fixes: eb608fb366de ("s390/exceptions: switch to relative exception table entries")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/s390/mm/extable.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/s390/mm/extable.c b/arch/s390/mm/extable.c
index 4d1ee88864e8..18c8b819b0aa 100644
--- a/arch/s390/mm/extable.c
+++ b/arch/s390/mm/extable.c
@@ -52,12 +52,16 @@ void sort_extable(struct exception_table_entry *start,
 	int i;
 
 	/* Normalize entries to being relative to the start of the section */
-	for (p = start, i = 0; p < finish; p++, i += 8)
+	for (p = start, i = 0; p < finish; p++, i += 8) {
 		p->insn += i;
+		p->fixup += i + 4;
+	}
 	sort(start, finish - start, sizeof(*start), cmp_ex, NULL);
 	/* Denormalize all entries */
-	for (p = start, i = 0; p < finish; p++, i += 8)
+	for (p = start, i = 0; p < finish; p++, i += 8) {
 		p->insn -= i;
+		p->fixup -= i + 4;
+	}
 }
 
 #ifdef CONFIG_MODULES
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1300578

On 4 January 2016 at 10:42, Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Fri, Jan 01, 2016 at 01:39:22PM +0100, Ard Biesheuvel wrote:
>> The normalization pass in the sorting routine of the relative exception
>> table serves two purposes:
>> - it ensures that the address fields of the exception table entries are
>>   fully ordered, so that no ambiguities arise between entries with
>>   identical instruction offsets (i.e., when two instructions that are
>>   exactly 8 bytes apart each have an exception table entry associated with
>>   them)
>> - it ensures that the offsets of both the instruction and the fixup fields
>>   of each entry are relative to their final location after sorting.
>>
>> Commit eb608fb366de ("s390/exceptions: switch to relative exception table
>> entries") ported the relative exception table format from x86, but modified
>> the sorting routine to only normalize the instruction offset field and not
>> the fixup offset field. The result is that the fixup offset of each entry
>> will be relative to the original location of the entry before sorting,
>> likely leading to crashes when those entries are dereferenced.
>
> Applied, thanks a lot!
>
> I was wondering why this never was observed on s390 during the last three
> years.
>
> The kernel text extable entries will be sorted during build time and I
> verified that for the majority of modules the extable entries are already
> sorted. And even if they are not sorted there isn't any major shuffling.
> So it looks like we were simply lucky...
>

Indeed. I guess most modules only have a single .text section so the
entries are emitted in order.

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300579

On Fri, Jan 01, 2016 at 01:39:22PM +0100, Ard Biesheuvel wrote:
> The normalization pass in the sorting routine of the relative exception
> table serves two purposes:
> - it ensures that the address fields of the exception table entries are
>   fully ordered, so that no ambiguities arise between entries with
>   identical instruction offsets (i.e., when two instructions that are
>   exactly 8 bytes apart each have an exception table entry associated with
>   them)
> - it ensures that the offsets of both the instruction and the fixup fields
>   of each entry are relative to their final location after sorting.
> 
> Commit eb608fb366de ("s390/exceptions: switch to relative exception table
> entries") ported the relative exception table format from x86, but modified
> the sorting routine to only normalize the instruction offset field and not
> the fixup offset field. The result is that the fixup offset of each entry
> will be relative to the original location of the entry before sorting,
> likely leading to crashes when those entries are dereferenced.

Applied, thanks a lot!

I was wondering why this never was observed on s390 during the last three
years.

The kernel text extable entries will be sorted during build time and I
verified that for the majority of modules the extable entries are already
sorted. And even if they are not sorted there isn't any major shuffling.
So it looks like we were simply lucky...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web