Hi all,
On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifr...@redhat.com wrote:
> This issue occurs post stackguard patches correct? Fixing it sounds like
> this might go beyond hardening and into CVE territory.
Since this thread is public on LKML, as it should be, it's no longer
valid to be CC'ed
Hi all,
On Tue, Jul 04, 2017 at 07:16:06PM -0600, kseifr...@redhat.com wrote:
> This issue occurs post stackguard patches correct? Fixing it sounds like
> this might go beyond hardening and into CVE territory.
Since this thread is public on LKML, as it should be, it's no longer
valid to be CC'ed
This issue occurs post stackguard patches correct? Fixing it sounds like
this might go beyond hardening and into CVE territory.
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secal...@redhat.com
This issue occurs post stackguard patches correct? Fixing it sounds like
this might go beyond hardening and into CVE territory.
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secal...@redhat.com
On 04/07/17 00:55, Ben Hutchings wrote:
> Unfortunately these regressions have not been completely fixed by
> switching to Hugh's fix.
>
> Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> Apparently Rust maps its own guard page at the lower limit of the stack
>
On 04/07/17 00:55, Ben Hutchings wrote:
> Unfortunately these regressions have not been completely fixed by
> switching to Hugh's fix.
>
> Firstly, some Rust programs are crashing on ppc64el with 64 KiB pages.
> Apparently Rust maps its own guard page at the lower limit of the stack
>
On Thu, Jun 22, 2017 at 8:10 PM, Andy Lutomirski wrote:
>
> Has anyone checked how grsecurity deals with this? I think they have
> a large stack guard gap.
Don't bother with grsecurity.
Their approach has always been "we don't care if we break anything,
we'll just claim it's
On Thu, Jun 22, 2017 at 8:10 PM, Andy Lutomirski wrote:
>
> Has anyone checked how grsecurity deals with this? I think they have
> a large stack guard gap.
Don't bother with grsecurity.
Their approach has always been "we don't care if we break anything,
we'll just claim it's because we're
On Thu, Jun 22, 2017 at 7:34 AM, Willy Tarreau wrote:
> On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote:
>> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
>> > but I think Ben is currently looking
>> > for feedback on the validity of his backport which was a
On Thu, Jun 22, 2017 at 7:34 AM, Willy Tarreau wrote:
> On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote:
>> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
>> > but I think Ben is currently looking
>> > for feedback on the validity of his backport which was a difficult
>> >
On 22.06.2017 16:14, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
>>> -- Allow stack to grow up to address space limit
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>> commit/?id=bd726c90b6b8ce87602208701b208a208e6d5600
>>
>> This one
On 22.06.2017 16:14, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
>>> -- Allow stack to grow up to address space limit
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>> commit/?id=bd726c90b6b8ce87602208701b208a208e6d5600
>>
>> This one
On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
> > but I think Ben is currently looking
> > for feedback on the validity of his backport which was a difficult
> > task.
>
> Right.
Ben, barring more feedback, I think your
On Thu, Jun 22, 2017 at 03:14:00PM +0100, Ben Hutchings wrote:
> On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
> > but I think Ben is currently looking
> > for feedback on the validity of his backport which was a difficult
> > task.
>
> Right.
Ben, barring more feedback, I think your
On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
> Hi,
>
> On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote:
> > Just a side note, but i think its worth mentioning to also have
> > look at
> > these fixup patches:
> >
> >
> > -- mm: fix new crash in unmapped_area_topdown()
On Thu, 2017-06-22 at 15:59 +0200, Willy Tarreau wrote:
> Hi,
>
> On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote:
> > Just a side note, but i think its worth mentioning to also have
> > look at
> > these fixup patches:
> >
> >
> > -- mm: fix new crash in unmapped_area_topdown()
Hi,
On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote:
> Just a side note, but i think its worth mentioning to also have look at
> these fixup patches:
>
>
> -- mm: fix new crash in unmapped_area_topdown()
>
Hi,
On Thu, Jun 22, 2017 at 03:15:51PM +0200, Levente Polyak wrote:
> Just a side note, but i think its worth mentioning to also have look at
> these fixup patches:
>
>
> -- mm: fix new crash in unmapped_area_topdown()
>
binnqgCLRXfKN.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
binnqgCLRXfKN.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
20 matches
Mail list logo