On 10/17/17 at 03:33pm, Michal Hocko wrote:
> On Tue 17-10-17 21:22:46, Baoquan He wrote:
> [...]
> > And as I said before, then we will still have the
> > ungraceful 'mapping total'|'unmapping the rest' method.
>
> yes I haven't touched this part and I guess you are right it can be
> removed now,
On Tue 17-10-17 21:22:46, Baoquan He wrote:
[...]
> And as I said before, then we will still have the
> ungraceful 'mapping total'|'unmapping the rest' method.
yes I haven't touched this part and I guess you are right it can be
removed now, but this was not my primary concern to adddress so there
On 10/17/17 at 02:56pm, Michal Hocko wrote:
> On Tue 17-10-17 20:26:14, Baoquan He wrote:
> > Hi Michal,
> >
> > Earlier I posted a patchset to clean up these in a different way, but
> > patches sent to your below mail address are all rejected.
> >
> > : host mail.kerne.org[104.131.33.237] said:
On Tue 17-10-17 20:26:14, Baoquan He wrote:
> Hi Michal,
>
> Earlier I posted a patchset to clean up these in a different way, but
> patches sent to your below mail address are all rejected.
>
> : host mail.kerne.org[104.131.33.237] said: 454 4.1.1
> : Recipient address rejected: User unknown
Hi Michal,
Earlier I posted a patchset to clean up these in a different way, but
patches sent to your below mail address are all rejected.
: host mail.kerne.org[104.131.33.237] said: 454 4.1.1
: Recipient address rejected: User unknown in virtual
mailbox table (in reply to RCPT TO command
On Tue 17-10-17 09:35:57, James Hogan wrote:
> On Tue, Oct 17, 2017 at 09:37:48AM +0200, Michal Hocko wrote:
[...]
> > This would be something like. I wanted to share elf_vm_mmap but didn't
> > find a proper place to not cause include dependency hell so I balied out
> > to c&p.
> > ---
> > diff --g
On Tue, Oct 17, 2017 at 09:37:48AM +0200, Michal Hocko wrote:
> On Mon 16-10-17 21:02:09, James Hogan wrote:
> > On Mon, Oct 16, 2017 at 09:00:47PM +0200, Michal Hocko wrote:
> > > [CCing metag people for the metag elf_map implementation specific. The
> > > thread
> > > starts here
> > > http://l
On Mon 16-10-17 21:02:09, James Hogan wrote:
> On Mon, Oct 16, 2017 at 09:00:47PM +0200, Michal Hocko wrote:
> > [CCing metag people for the metag elf_map implementation specific. The
> > thread
> > starts here
> > http://lkml.kernel.org/r/20171016134446.19910-1-mho...@kernel.org]
> >
> > On Mon
On Mon, Oct 16, 2017 at 09:00:47PM +0200, Michal Hocko wrote:
> [CCing metag people for the metag elf_map implementation specific. The thread
> starts here http://lkml.kernel.org/r/20171016134446.19910-1-mho...@kernel.org]
>
> On Mon 16-10-17 09:39:14, Kees Cook wrote:
> > On Mon, Oct 16, 2017 at
[CCing metag people for the metag elf_map implementation specific. The thread
starts here http://lkml.kernel.org/r/20171016134446.19910-1-mho...@kernel.org]
On Mon 16-10-17 09:39:14, Kees Cook wrote:
> On Mon, Oct 16, 2017 at 6:44 AM, Michal Hocko wrote:
[...]
> > +static unsigned long elf_vm_mma
On Mon, Oct 16, 2017 at 6:44 AM, Michal Hocko wrote:
> From: Michal Hocko
>
> Both load_elf_interp and load_elf_binary rely on elf_map to map segments
> on a controlled address and they use MAP_FIXED to enforce that. This is
> however dangerous thing prone to silent data corruption which can be
>
From: Michal Hocko
Both load_elf_interp and load_elf_binary rely on elf_map to map segments
on a controlled address and they use MAP_FIXED to enforce that. This is
however dangerous thing prone to silent data corruption which can be
even exploitable. Let's take CVE-2017-1000253 as an example. At
12 matches
Mail list logo
