On Thu, Sep 26, 2019 at 04:09:39PM +0200, Borislav Petkov wrote:
> On Thu, Sep 26, 2019 at 09:58:25AM +, Arthur Gautier wrote:
> > I think Andy submitted a patch Feb 25 2019, but I was not copied on it
> > (I believe it was sent to x...@kernel.org) and I don't know which fate it
> > had.
>
> I
On Thu, Sep 26, 2019 at 09:58:25AM +, Arthur Gautier wrote:
> I think Andy submitted a patch Feb 25 2019, but I was not copied on it
> (I believe it was sent to x...@kernel.org) and I don't know which fate it
> had.
I guess we're still waiting for Andy to do v2 with feedback incorporated
and p
On Mon, Feb 18, 2019 at 11:15:44AM -0800, Andy Lutomirski wrote:
> diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
> index 58eacd41526c..709d6efe0d42 100644
> --- a/lib/strncpy_from_user.c
> +++ b/lib/strncpy_from_user.c
> @@ -10,12 +10,7 @@
> #include
> #include
>
> -#ifdef CO
On Mon, Feb 18, 2019 at 09:51:50PM +, Arthur Gautier wrote:
> On Mon, Feb 18, 2019 at 11:15:44AM -0800, Andy Lutomirski wrote:
> > This seems like it's just papering over the underlying problem: with
> > Jann's new checks in place, strncpy_from_user() is simply buggy. Does
> > the patch below
On Mon, Feb 18, 2019 at 11:15:44AM -0800, Andy Lutomirski wrote:
> This seems like it's just papering over the underlying problem: with
> Jann's new checks in place, strncpy_from_user() is simply buggy. Does
> the patch below look decent? It's only compile-tested, but it's
> conceptually straight
On Mon, Feb 18, 2019 at 8:15 PM Andy Lutomirski wrote:
> On Mon, Feb 18, 2019 at 5:04 AM Thomas Gleixner wrote:
> > > Another would be to have the buffer passed to flush_buffer() (i.e.
> > > the callback of decompress_fn) allocated with 4 bytes of padding
> > > past the part where the unpacked pi
On Mon, Feb 18, 2019 at 5:04 AM Thomas Gleixner wrote:
> > Another would be to have the buffer passed to flush_buffer() (i.e.
> > the callback of decompress_fn) allocated with 4 bytes of padding
> > past the part where the unpacked piece of data is placed for the
> > callback to find. As in,
> >
On Sun, 17 Feb 2019, Al Viro wrote:
> On Sun, Feb 17, 2019 at 03:41:21AM +, Arthur Gautier wrote:
> Who says anything about changing the format of the file? At least
> one trivial way to handle that would be this:
>
> diff --git a/init/initramfs.c b/init/initramfs.c
> index 7cea802d00ef..edbd
On Sun, Feb 17, 2019 at 03:41:21AM +, Arthur Gautier wrote:
> On Sat, Feb 16, 2019 at 11:47:02PM +, Al Viro wrote:
> > On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote:
> >
> > > What is the actual problem? We’re not actually demand-faulting this
> > > data, are we? Are w
On Sat, Feb 16, 2019 at 11:47:02PM +, Al Viro wrote:
> On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote:
>
> > What is the actual problem? We’re not actually demand-faulting this data,
> > are we? Are we just overrunning the buffer because the from_user helpers
> > are too c
> On Feb 16, 2019, at 3:47 PM, Al Viro wrote:
>
>> On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote:
>>
>> What is the actual problem? We’re not actually demand-faulting this data,
>> are we? Are we just overrunning the buffer because the from_user helpers
>> are too clever
On Sat, Feb 16, 2019 at 11:47:02PM +, Al Viro wrote:
> On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote:
>
> > What is the actual problem? We’re not actually demand-faulting this data,
> > are we? Are we just overrunning the buffer because the from_user helpers
> > are too c
On Sat, Feb 16, 2019 at 02:50:15PM -0800, Andy Lutomirski wrote:
> What is the actual problem? We’re not actually demand-faulting this data,
> are we? Are we just overrunning the buffer because the from_user helpers are
> too clever? Can we fix it for real by having the fancy helpers do *alig
> On Feb 16, 2019, at 2:50 PM, Andy Lutomirski wrote:
>
>
>
>>> On Feb 16, 2019, at 12:18 PM, Thomas Gleixner wrote:
>>>
On Sat, 16 Feb 2019, Jann Horn wrote:
On Sat, Feb 16, 2019 at 12:59 AM wrote:
When extracting an initramfs, a filename may be near an allocation
bou
> On Feb 16, 2019, at 12:18 PM, Thomas Gleixner wrote:
>
>> On Sat, 16 Feb 2019, Jann Horn wrote:
>>> On Sat, Feb 16, 2019 at 12:59 AM wrote:
>>> When extracting an initramfs, a filename may be near an allocation boundary.
>>> Should that happen, strncopy_from_user will invoke unsafe_get_user
On Sat, 16 Feb 2019, Thomas Gleixner wrote:
> On Sat, 16 Feb 2019, Jann Horn wrote:
> > On Sat, Feb 16, 2019 at 12:59 AM wrote:
> > > When extracting an initramfs, a filename may be near an allocation
> > > boundary.
> > > Should that happen, strncopy_from_user will invoke unsafe_get_user which
On Sat, 16 Feb 2019, Jann Horn wrote:
> On Sat, Feb 16, 2019 at 12:59 AM wrote:
> > When extracting an initramfs, a filename may be near an allocation boundary.
> > Should that happen, strncopy_from_user will invoke unsafe_get_user which
> > may cross the allocation boundary. Should that happen, u
+Andy Lutomirski
On Sat, Feb 16, 2019 at 12:59 AM wrote:
>
> From: Arthur Gautier
>
> When extracting an initramfs, a filename may be near an allocation boundary.
> Should that happen, strncopy_from_user will invoke unsafe_get_user which
> may cross the allocation boundary. Should that happen, u
From: Arthur Gautier
When extracting an initramfs, a filename may be near an allocation boundary.
Should that happen, strncopy_from_user will invoke unsafe_get_user which
may cross the allocation boundary. Should that happen, unsafe_get_user will
trigger a page fault, and strncopy_from_user would
19 matches
Mail list logo
