On Wed, Jan 24, 2024 at 02:06:23PM -0800, Kees Cook wrote:
> Path-based LSMs will bypass uselib() "open" checks since commit
> 4759ff71f23e ("exec: Check __FMODE_EXEC instead of in_execve for LSMs"),
> so don't set __FMODE_EXEC during uselib(). The LSM "open" and eventual
> "mmap" hooks will be res
Path-based LSMs will bypass uselib() "open" checks since commit
4759ff71f23e ("exec: Check __FMODE_EXEC instead of in_execve for LSMs"),
so don't set __FMODE_EXEC during uselib(). The LSM "open" and eventual
"mmap" hooks will be restored. (uselib() never set current->in_execve.)
Other things that
On Wed, Jan 24, 2024 at 08:52:48PM +0100, Rafael J. Wysocki wrote:
> On Tue, Jan 23, 2024 at 2:03 AM Kees Cook wrote:
> >
> > In an effort to separate intentional arithmetic wrap-around from
> > unexpected wrap-around, we need to refactor places that depend on this
> > kind of math. One of the mos
On Tue, Jan 23, 2024 at 2:03 AM Kees Cook wrote:
>
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> Notably,
On Mon, Jan 22 2024 at 16:27, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> Notably, this
Just to help distinguish the fs->in_exec flag from the current->in_execve
flag, add comments in check_unsafe_exec() and copy_fs() for more
context. Also note that in_execve is only used by TOMOYO now.
Cc: Kentaro Takeda
Cc: Tetsuo Handa
Cc: Alexander Viro
Cc: Christian Brauner
Cc: Jan Kara
Cc
On Mon, Jan 22, 2024, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> Notable, this is cons
On Mon, Jan 22, 2024, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> Notably, this is cons
On Tue, Jan 23, 2024 at 05:04:22PM -0800, Yang Shi wrote:
> On Tue, Jan 23, 2024 at 2:37 PM Kees Cook wrote:
> >
> > On Tue, Jan 16, 2024 at 09:09:45AM +0100, Ard Biesheuvel wrote:
> > > (cc Kees, LAKML)
> > >
> > > https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com
> > >
> >
On 1/23/24 11:49, Marc Zyngier wrote:
> On Tue, 23 Jan 2024 00:26:59 +,
> Kees Cook wrote:
>> In an effort to separate intentional arithmetic wrap-around from
>> unexpected wrap-around, we need to refactor places that depend on this
>> kind of math. One of the most common code patterns of t
On 1/23/24 01:27, Kees Cook wrote:
> In an effort to separate intentional arithmetic wrap-around from
> unexpected wrap-around, we need to refactor places that depend on this
> kind of math. One of the most common code patterns of this is:
>
> VAR + value < VAR
>
> Notably, this is conside
On Mon, Jan 22, 2024 at 07:16:54PM +0100, Erick Archer wrote:
> Hi Dan,
>
> On Mon, Jan 22, 2024 at 09:55:11AM +0300, Dan Carpenter wrote:
> > On Fri, Jan 19, 2024 at 06:39:00PM +0100, Erick Archer wrote:
> > > As noted in the "Deprecated Interfaces, Language Features, Attributes,
> > > and Conven
12 matches
Mail list logo