Al Viro writes:
> OTTH, it's not really needed there - see vfs.git #work.audit
> for (untested) turning that sucker non-blocking. I hadn't tried
> a followup that would get rid of the entire AVC_NONBLOCKING thing yet,
> but I suspect that it should simplify the things in there nicely...
I went a
On Tue, Jan 5, 2021 at 7:38 PM Al Viro wrote:
> On Tue, Jan 05, 2021 at 07:00:59PM -0500, Paul Moore wrote:
...
> > I would expect the problem here to be the currently allocated audit
> > buffer isn't large enough to hold the full audit record, in which case
> > it will attempt to expand the buf
Al Viro writes:
> On Mon, Jan 04, 2021 at 03:21:22PM -0800, Stephen Brennan wrote:
>> The pid_revalidate() function drops from RCU into REF lookup mode. When
>> many threads are resolving paths within /proc in parallel, this can
>> result in heavy spinlock contention on d_lockref as each thread t
On Tue, Jan 05, 2021 at 07:00:59PM -0500, Paul Moore wrote:
> > > Incidentally, LSM_AUDIT_DATA_DENTRY in mainline is *not* safe wrt
> > > rename() - for long-named dentries it is possible to get preempted
> > > in the middle of
> > > audit_log_untrustedstring(ab, a->u.dentry->d_nam
On Tue, Jan 5, 2021 at 6:27 PM Stephen Brennan
wrote:
> Al Viro writes:
>
> > On Tue, Jan 05, 2021 at 04:50:05PM +, Al Viro wrote:
> >
> >> LSM_AUDIT_DATA_DENTRY is easy to handle - wrap
> >> audit_log_untrustedstring(ab, a->u.dentry->d_name.name);
> >> into grabbing/dropping
Al Viro writes:
> On Tue, Jan 05, 2021 at 04:50:05PM +, Al Viro wrote:
>
>> LSM_AUDIT_DATA_DENTRY is easy to handle - wrap
>> audit_log_untrustedstring(ab, a->u.dentry->d_name.name);
>> into grabbing/dropping a->u.dentry->d_lock and we are done.
>
> Incidentally, LSM_AUDIT_DAT
On Tue, Jan 05, 2021 at 12:38:31PM -0800, Linus Torvalds wrote:
> This whole thing isn't important enough to get the dentry lock. It's
> more of a hint than anything else.
>
> Why isn't the fix to just use READ_ONCE() of the name pointer, and do
> it under RCU?
Umm... Take a look at audit_log_u
On Tue, Jan 5, 2021 at 12:00 PM Al Viro wrote:
>
> We are not guaranteed the locking environment that would prevent
> dentry getting renamed right under us. And it's possible for
> old long name to be freed after rename, leading to UAF here.
This whole thing isn't important enough to get the den
On Tue, Jan 05, 2021 at 04:50:05PM +, Al Viro wrote:
> LSM_AUDIT_DATA_DENTRY is easy to handle - wrap
> audit_log_untrustedstring(ab, a->u.dentry->d_name.name);
> into grabbing/dropping a->u.dentry->d_lock and we are done.
Incidentally, LSM_AUDIT_DATA_DENTRY in mainline is *no
On Tue, Jan 05, 2021 at 04:50:05PM +, Al Viro wrote:
> struct dentry *d_find_alias_rcu(struct inode *inode)
> {
> struct hlist_head *l = &inode->i_dentry;
> struct dentry *de = NULL;
>
> spin_lock(&inode->i_lock);
> // ->i_dentry and ->i_rcu are colocated, but the la
On Tue, Jan 05, 2021 at 05:59:35AM +, Al Viro wrote:
> Umm... I'm rather worried about the side effect you are removing here -
> you are suddenly exposing a bunch of methods in there to RCU mode.
> E.g. is proc_pid_permission() safe with MAY_NOT_BLOCK in the mask?
> generic_permission() call
On Mon, Jan 04, 2021 at 03:21:22PM -0800, Stephen Brennan wrote:
> The pid_revalidate() function drops from RCU into REF lookup mode. When
> many threads are resolving paths within /proc in parallel, this can
> result in heavy spinlock contention on d_lockref as each thread tries to
> grab a refere
12 matches
Mail list logo
