From: Alexey Gladkov <[email protected]>
[ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
We need to increment the ucounts reference counter befor security_prepare_creds()
because this function may fail and abort_creds() will try to decrement
this reference.
[ 96.465056][ T8641] FAULT_INJECTION: forcing a failure.
[ 96.465056][ T8641] name fail_page_alloc, interval 1, probability 0, space 0, times 0
[ 96.478453][ T8641] CPU: 1 PID: 8641 Comm: syz-executor668 Not tainted 5.14.0-rc6-syzkaller #0
[ 96.487215][ T8641] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 96.497254][ T8641] Call Trace:
[ 96.500517][ T8641] dump_stack_lvl+0x1d3/0x29f
[ 96.505758][ T8641] ? show_regs_print_info+0x12/0x12
[ 96.510944][ T8641] ? log_buf_vmcoreinfo_setup+0x498/0x498
[ 96.516652][ T8641] should_fail+0x384/0x4b0
[ 96.521141][ T8641] prepare_alloc_pages+0x1d1/0x5a0
[ 96.526236][ T8641] __alloc_pages+0x14d/0x5f0
[ 96.530808][ T8641] ? __rmqueue_pcplist+0x2030/0x2030
[ 96.536073][ T8641] ? lockdep_hardirqs_on_prepare+0x3e2/0x750
[ 96.542056][ T8641] ? alloc_pages+0x3f3/0x500
[ 96.546635][ T8641] allocate_slab+0xf1/0x540
[ 96.551120][ T8641] ___slab_alloc+0x1cf/0x350
[ 96.555689][ T8641] ? kzalloc+0x1d/0x30
[ 96.559740][ T8641] __kmalloc+0x2e7/0x390
[ 96.563980][ T8641] ? kzalloc+0x1d/0x30
[ 96.568029][ T8641] kzalloc+0x1d/0x30
[ 96.571903][ T8641] security_prepare_creds+0x46/0x220
[ 96.577174][ T8641] prepare_creds+0x411/0x640
[ 96.581747][ T8641] __sys_setfsuid+0xe2/0x3a0
[ 96.586333][ T8641] do_syscall_64+0x3d/0xb0
[ 96.590739][ T8641] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 96.596611][ T8641] RIP: 0033:0x445a69
[ 96.600483][ T8641] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
[ 96.620152][ T8641] RSP: 002b:00007f1054173318 EFLAGS: 00000246 ORIG_RAX: 000000000000007a
[ 96.628543][ T8641] RAX: ffffffffffffffda RBX: 00000000004ca4c8 RCX: 0000000000445a69
[ 96.636600][ T8641] RDX: 0000000000000010 RSI: 00007f10541732f0 RDI: 0000000000000000
[ 96.644550][ T8641] RBP: 00000000004ca4c0 R08: 0000000000000001 R09: 0000000000000000
[ 96.652500][ T8641] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004ca4cc
[ 96.660631][ T8641] R13: 00007fffffe0b62f R14: 00007f1054173400 R15: 0000000000022000
Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred")
Reported-by: [email protected]
Signed-off-by: Alexey Gladkov <[email protected]>
Link: https://lkml.kernel.org/r/97433b1742c3331f02ad92de5a4f07d673c90613.1629735352.git.legion@kernel.org
Signed-off-by: Eric W. Biederman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
kernel/cred.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/cred.c b/kernel/cred.c
index 098213d4a39c..8c0983fa794a 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -286,13 +286,13 @@ struct cred *prepare_creds(void)
new->security = NULL;
#endif
- if (security_prepare_creds(new, old, GFP_KERNEL_ACCOUNT) < 0)
- goto error;
-
new->ucounts = get_ucounts(new->ucounts);
if (!new->ucounts)
goto error;
+ if (security_prepare_creds(new, old, GFP_KERNEL_ACCOUNT) < 0)
+ goto error;
+
validate_creds(new);
return new;
@@ -753,13 +753,13 @@ struct cred *prepare_kernel_cred(struct task_struct *daemon)
#ifdef CONFIG_SECURITY
new->security = NULL;
#endif
- if (security_prepare_creds(new, old, GFP_KERNEL_ACCOUNT) < 0)
- goto error;
-
new->ucounts = get_ucounts(new->ucounts);
if (!new->ucounts)
goto error;
+ if (security_prepare_creds(new, old, GFP_KERNEL_ACCOUNT) < 0)
+ goto error;
+
put_cred(old);
validate_creds(new);
return new;
--
2.30.2
Greg Kroah-Hartman <[email protected]> writes:
> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
>> Greg Kroah-Hartman <[email protected]> writes:
>>
>> > From: Alexey Gladkov <[email protected]>
>> >
>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
>> >
>> > We need to increment the ucounts reference counter befor security_prepare_creds()
>> > because this function may fail and abort_creds() will try to decrement
>> > this reference.
>>
>> Has the conversion of the rlimits to ucounts been backported?
>>
>> Semantically the code is an improvement but I don't know of any cases
>> where it makes enough of a real-world difference to make it worth
>> backporting the code.
>>
>> Certainly the ucount/rlimit conversions do not meet the historical
>> criteria for backports. AKA simple obviously correct patches.
>>
>> The fact we have been applying fixes for the entire v5.14 stabilization
>> period is a testament to the code not quite being obviously correct.
>>
>> Without backports the code only affects v5.14 so I have not been
>> including a Cc stable on any of the commits.
>>
>> So color me very puzzled about what is going on here.
>
> Sasha picked this for some reason, but if you think it should be
> dropped, we can easily do so.
My question is what is the reason Sasha picked this up?
If this patch even applies to v5.10 the earlier patches have been
backported. So we can't just drop this patch. Either the earlier
backports need to be reverted, or we need to make certain all of the
patches are backported.
I really am trying to understand what is going on and why.
I work on a lot of stuff that has been imperfect for years. Generally I
clean up the code and the semantics so the old imperfect code does not
impede new development (user or kernel). Updating a couple of rlimits
to the ucount infrastructure was one of those improvements to imperfect
code.
As I expect this situation to come up again and again, I am asking what
is going on? What are the rules under which code is backported?
I am hoping to get a clear answer on why what looks to me like feature
development has been backported into v5.10, and v5.13.
If the answer is going to be random commits are going to be backported
whenever the stable reviewers think it is a good idea, with no
explanation of why they think so, can I please not be Cc'd during stable
review as I have no basis on which to perform a review.
Eric
On Thu, Sep 02, 2021 at 09:04:09AM -0400, Sasha Levin wrote:
> On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
> > Greg Kroah-Hartman <[email protected]> writes:
> >
> > > On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
> > > > Greg Kroah-Hartman <[email protected]> writes:
> > > >
> > > > > From: Alexey Gladkov <[email protected]>
> > > > >
> > > > > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
> > > > >
> > > > > We need to increment the ucounts reference counter befor security_prepare_creds()
> > > > > because this function may fail and abort_creds() will try to decrement
> > > > > this reference.
> > > >
> > > > Has the conversion of the rlimits to ucounts been backported?
> > > >
> > > > Semantically the code is an improvement but I don't know of any cases
> > > > where it makes enough of a real-world difference to make it worth
> > > > backporting the code.
> > > >
> > > > Certainly the ucount/rlimit conversions do not meet the historical
> > > > criteria for backports. AKA simple obviously correct patches.
> > > >
> > > > The fact we have been applying fixes for the entire v5.14 stabilization
> > > > period is a testament to the code not quite being obviously correct.
> > > >
> > > > Without backports the code only affects v5.14 so I have not been
> > > > including a Cc stable on any of the commits.
> > > >
> > > > So color me very puzzled about what is going on here.
> > >
> > > Sasha picked this for some reason, but if you think it should be
> > > dropped, we can easily do so.
> >
> > My question is what is the reason Sasha picked this up?
> >
> > If this patch even applies to v5.10 the earlier patches have been
> > backported. So we can't just drop this patch. Either the earlier
> > backports need to be reverted, or we need to make certain all of the
> > patches are backported.
> >
> > I really am trying to understand what is going on and why.
>
> I'll happily explain. The commit message is telling us that:
>
> 1. There is an issue uncovered by syzbot which this patch fixes:
>
> "Reported-by: syzbot"
>
> 2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
> for each cred"):
>
> "Fixes: 905ae01c4ae2"
>
> Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
> I've queued it up.
I think Eric's question was about why this commit got into 5.10 because
the whole c54b245d0118 patchset was not a bug fix ?
Personally, I don't see anything wrong with moving this patchset to 5.10,
but it's not clear why it was decided to backport it.
> In general, if we're missing backports, backported something only
> partially and should revert it, or anything else that might cause an
> issue, we'd be more than happy to work with you to fix it up.
>
> All the patches we queue up get multiple rounds of emails and reviews,
> if there is a better way to solicit reviews so that we won't up in a
> place where you haven't noticed something going in earlier we'd be more
> than happy to improve that process too.
>
> --
> Thanks,
> Sasha
>
--
Rgrds, legion
On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
>Greg Kroah-Hartman <[email protected]> writes:
>
>> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
>>> Greg Kroah-Hartman <[email protected]> writes:
>>>
>>> > From: Alexey Gladkov <[email protected]>
>>> >
>>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
>>> >
>>> > We need to increment the ucounts reference counter befor security_prepare_creds()
>>> > because this function may fail and abort_creds() will try to decrement
>>> > this reference.
>>>
>>> Has the conversion of the rlimits to ucounts been backported?
>>>
>>> Semantically the code is an improvement but I don't know of any cases
>>> where it makes enough of a real-world difference to make it worth
>>> backporting the code.
>>>
>>> Certainly the ucount/rlimit conversions do not meet the historical
>>> criteria for backports. AKA simple obviously correct patches.
>>>
>>> The fact we have been applying fixes for the entire v5.14 stabilization
>>> period is a testament to the code not quite being obviously correct.
>>>
>>> Without backports the code only affects v5.14 so I have not been
>>> including a Cc stable on any of the commits.
>>>
>>> So color me very puzzled about what is going on here.
>>
>> Sasha picked this for some reason, but if you think it should be
>> dropped, we can easily do so.
>
>My question is what is the reason Sasha picked this up?
>
>If this patch even applies to v5.10 the earlier patches have been
>backported. So we can't just drop this patch. Either the earlier
>backports need to be reverted, or we need to make certain all of the
>patches are backported.
>
>I really am trying to understand what is going on and why.
I'll happily explain. The commit message is telling us that:
1. There is an issue uncovered by syzbot which this patch fixes:
"Reported-by: syzbot"
2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
for each cred"):
"Fixes: 905ae01c4ae2"
Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
I've queued it up.
In general, if we're missing backports, backported something only
partially and should revert it, or anything else that might cause an
issue, we'd be more than happy to work with you to fix it up.
All the patches we queue up get multiple rounds of emails and reviews,
if there is a better way to solicit reviews so that we won't up in a
place where you haven't noticed something going in earlier we'd be more
than happy to improve that process too.
--
Thanks,
Sasha
Sasha Levin <[email protected]> writes:
> On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
>>Greg Kroah-Hartman <[email protected]> writes:
>>
>>> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
>>>> Greg Kroah-Hartman <[email protected]> writes:
>>>>
>>>> > From: Alexey Gladkov <[email protected]>
>>>> >
>>>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
>>>> >
>>>> > We need to increment the ucounts reference counter befor security_prepare_creds()
>>>> > because this function may fail and abort_creds() will try to decrement
>>>> > this reference.
>>>>
>>>> Has the conversion of the rlimits to ucounts been backported?
>>>>
>>>> Semantically the code is an improvement but I don't know of any cases
>>>> where it makes enough of a real-world difference to make it worth
>>>> backporting the code.
>>>>
>>>> Certainly the ucount/rlimit conversions do not meet the historical
>>>> criteria for backports. AKA simple obviously correct patches.
>>>>
>>>> The fact we have been applying fixes for the entire v5.14 stabilization
>>>> period is a testament to the code not quite being obviously correct.
>>>>
>>>> Without backports the code only affects v5.14 so I have not been
>>>> including a Cc stable on any of the commits.
>>>>
>>>> So color me very puzzled about what is going on here.
>>>
>>> Sasha picked this for some reason, but if you think it should be
>>> dropped, we can easily do so.
>>
>>My question is what is the reason Sasha picked this up?
>>
>>If this patch even applies to v5.10 the earlier patches have been
>>backported. So we can't just drop this patch. Either the earlier
>>backports need to be reverted, or we need to make certain all of the
>>patches are backported.
>>
>>I really am trying to understand what is going on and why.
>
> I'll happily explain. The commit message is telling us that:
>
> 1. There is an issue uncovered by syzbot which this patch fixes:
>
> "Reported-by: syzbot"
>
> 2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
> for each cred"):
>
> "Fixes: 905ae01c4ae2"
>
> Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
> I've queued it up.
Which begs the question as Alex mentioned how did 905ae01c4ae2 get into
5.10, as it was merged to Linus's tree in the merge window for 5.14.
> In general, if we're missing backports, backported something only
> partially and should revert it, or anything else that might cause an
> issue, we'd be more than happy to work with you to fix it up.
>
> All the patches we queue up get multiple rounds of emails and reviews,
> if there is a better way to solicit reviews so that we won't up in a
> place where you haven't noticed something going in earlier we'd be more
> than happy to improve that process too.
I have the bad feeling that 905ae01c4ae2 was backported because it was a
prerequisite to something with a Fixes tag.
Fixes tags especially in this instance don't mean code needs to go to
stable Fixes tags mean that a bug was fixed. Since I thought the code
only existed in Linus's tree, I haven't been adding Cc stable or even
thinking about earlier kernels with respect to this code.
I honestly can't keep up with the level of review needed for patches
targeting Linus's tree. So I occasionally glance at patches destined
for the stable tree.
Most of the time it is something being backported without a stable tag,
but with a fixes tag, that is unnecessary but generally harmless so I
ignore it.
In this instance it looks like a whole new feature that has had a rocky
history and a lot of time to stablize is somehow backported to 5.10 and
5.13. I think all of the known issues are addressed but I won't know
if all of the issues syzkaller can find are found for another couple of
weeks.
Because this code was not obviously correct, because this code did not
have a stable tag, because I am not even certain it is stable yet,
I am asking do you know how this code that feels to me like feature work
wound up being backported? AKA why is 905ae01c4ae2 in 5.10 and 5.13.
Eric
On Thu, Sep 02, 2021 at 01:06:34PM -0500, Eric W. Biederman wrote:
> Sasha Levin <[email protected]> writes:
>
> > On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
> >>Greg Kroah-Hartman <[email protected]> writes:
> >>
> >>> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
> >>>> Greg Kroah-Hartman <[email protected]> writes:
> >>>>
> >>>> > From: Alexey Gladkov <[email protected]>
> >>>> >
> >>>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
> >>>> >
> >>>> > We need to increment the ucounts reference counter befor security_prepare_creds()
> >>>> > because this function may fail and abort_creds() will try to decrement
> >>>> > this reference.
> >>>>
> >>>> Has the conversion of the rlimits to ucounts been backported?
> >>>>
> >>>> Semantically the code is an improvement but I don't know of any cases
> >>>> where it makes enough of a real-world difference to make it worth
> >>>> backporting the code.
> >>>>
> >>>> Certainly the ucount/rlimit conversions do not meet the historical
> >>>> criteria for backports. AKA simple obviously correct patches.
> >>>>
> >>>> The fact we have been applying fixes for the entire v5.14 stabilization
> >>>> period is a testament to the code not quite being obviously correct.
> >>>>
> >>>> Without backports the code only affects v5.14 so I have not been
> >>>> including a Cc stable on any of the commits.
> >>>>
> >>>> So color me very puzzled about what is going on here.
> >>>
> >>> Sasha picked this for some reason, but if you think it should be
> >>> dropped, we can easily do so.
> >>
> >>My question is what is the reason Sasha picked this up?
> >>
> >>If this patch even applies to v5.10 the earlier patches have been
> >>backported. So we can't just drop this patch. Either the earlier
> >>backports need to be reverted, or we need to make certain all of the
> >>patches are backported.
> >>
> >>I really am trying to understand what is going on and why.
> >
> > I'll happily explain. The commit message is telling us that:
> >
> > 1. There is an issue uncovered by syzbot which this patch fixes:
> >
> > "Reported-by: syzbot"
> >
> > 2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
> > for each cred"):
> >
> > "Fixes: 905ae01c4ae2"
> >
> > Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
> > I've queued it up.
>
> Which begs the question as Alex mentioned how did 905ae01c4ae2 get into
> 5.10, as it was merged to Linus's tree in the merge window for 5.14.
>
> > In general, if we're missing backports, backported something only
> > partially and should revert it, or anything else that might cause an
> > issue, we'd be more than happy to work with you to fix it up.
> >
> > All the patches we queue up get multiple rounds of emails and reviews,
> > if there is a better way to solicit reviews so that we won't up in a
> > place where you haven't noticed something going in earlier we'd be more
> > than happy to improve that process too.
>
> I have the bad feeling that 905ae01c4ae2 was backported because it was a
> prerequisite to something with a Fixes tag.
>
> Fixes tags especially in this instance don't mean code needs to go to
> stable Fixes tags mean that a bug was fixed. Since I thought the code
> only existed in Linus's tree, I haven't been adding Cc stable or even
> thinking about earlier kernels with respect to this code.
>
> I honestly can't keep up with the level of review needed for patches
> targeting Linus's tree. So I occasionally glance at patches destined
> for the stable tree.
>
> Most of the time it is something being backported without a stable tag,
> but with a fixes tag, that is unnecessary but generally harmless so I
> ignore it.
>
> In this instance it looks like a whole new feature that has had a rocky
> history and a lot of time to stablize is somehow backported to 5.10 and
> 5.13. I think all of the known issues are addressed but I won't know
> if all of the issues syzkaller can find are found for another couple of
> weeks.
>
> Because this code was not obviously correct, because this code did not
> have a stable tag, because I am not even certain it is stable yet,
> I am asking do you know how this code that feels to me like feature work
> wound up being backported? AKA why is 905ae01c4ae2 in 5.10 and 5.13.
Looks like Sasha added it to the tree last week and it went out in the
last set of releases. Sasha, why was this added? Let me see if it was
a requirement of some other patch...
thanks,
greg k-h
On Fri, Sep 03, 2021 at 06:57:39AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 02, 2021 at 01:06:34PM -0500, Eric W. Biederman wrote:
> > Sasha Levin <[email protected]> writes:
> >
> > > On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
> > >>Greg Kroah-Hartman <[email protected]> writes:
> > >>
> > >>> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
> > >>>> Greg Kroah-Hartman <[email protected]> writes:
> > >>>>
> > >>>> > From: Alexey Gladkov <[email protected]>
> > >>>> >
> > >>>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
> > >>>> >
> > >>>> > We need to increment the ucounts reference counter befor security_prepare_creds()
> > >>>> > because this function may fail and abort_creds() will try to decrement
> > >>>> > this reference.
> > >>>>
> > >>>> Has the conversion of the rlimits to ucounts been backported?
> > >>>>
> > >>>> Semantically the code is an improvement but I don't know of any cases
> > >>>> where it makes enough of a real-world difference to make it worth
> > >>>> backporting the code.
> > >>>>
> > >>>> Certainly the ucount/rlimit conversions do not meet the historical
> > >>>> criteria for backports. AKA simple obviously correct patches.
> > >>>>
> > >>>> The fact we have been applying fixes for the entire v5.14 stabilization
> > >>>> period is a testament to the code not quite being obviously correct.
> > >>>>
> > >>>> Without backports the code only affects v5.14 so I have not been
> > >>>> including a Cc stable on any of the commits.
> > >>>>
> > >>>> So color me very puzzled about what is going on here.
> > >>>
> > >>> Sasha picked this for some reason, but if you think it should be
> > >>> dropped, we can easily do so.
> > >>
> > >>My question is what is the reason Sasha picked this up?
> > >>
> > >>If this patch even applies to v5.10 the earlier patches have been
> > >>backported. So we can't just drop this patch. Either the earlier
> > >>backports need to be reverted, or we need to make certain all of the
> > >>patches are backported.
> > >>
> > >>I really am trying to understand what is going on and why.
> > >
> > > I'll happily explain. The commit message is telling us that:
> > >
> > > 1. There is an issue uncovered by syzbot which this patch fixes:
> > >
> > > "Reported-by: syzbot"
> > >
> > > 2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
> > > for each cred"):
> > >
> > > "Fixes: 905ae01c4ae2"
> > >
> > > Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
> > > I've queued it up.
> >
> > Which begs the question as Alex mentioned how did 905ae01c4ae2 get into
> > 5.10, as it was merged to Linus's tree in the merge window for 5.14.
> >
> > > In general, if we're missing backports, backported something only
> > > partially and should revert it, or anything else that might cause an
> > > issue, we'd be more than happy to work with you to fix it up.
> > >
> > > All the patches we queue up get multiple rounds of emails and reviews,
> > > if there is a better way to solicit reviews so that we won't up in a
> > > place where you haven't noticed something going in earlier we'd be more
> > > than happy to improve that process too.
> >
> > I have the bad feeling that 905ae01c4ae2 was backported because it was a
> > prerequisite to something with a Fixes tag.
> >
> > Fixes tags especially in this instance don't mean code needs to go to
> > stable Fixes tags mean that a bug was fixed. Since I thought the code
> > only existed in Linus's tree, I haven't been adding Cc stable or even
> > thinking about earlier kernels with respect to this code.
> >
> > I honestly can't keep up with the level of review needed for patches
> > targeting Linus's tree. So I occasionally glance at patches destined
> > for the stable tree.
> >
> > Most of the time it is something being backported without a stable tag,
> > but with a fixes tag, that is unnecessary but generally harmless so I
> > ignore it.
> >
> > In this instance it looks like a whole new feature that has had a rocky
> > history and a lot of time to stablize is somehow backported to 5.10 and
> > 5.13. I think all of the known issues are addressed but I won't know
> > if all of the issues syzkaller can find are found for another couple of
> > weeks.
> >
> > Because this code was not obviously correct, because this code did not
> > have a stable tag, because I am not even certain it is stable yet,
> > I am asking do you know how this code that feels to me like feature work
> > wound up being backported? AKA why is 905ae01c4ae2 in 5.10 and 5.13.
>
> Looks like Sasha added it to the tree last week and it went out in the
> last set of releases. Sasha, why was this added? Let me see if it was
> a requirement of some other patch...
Sorry, no, that was this patch, let me get my coffee before I dig into
this...
On Fri, Sep 03, 2021 at 07:00:09AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 03, 2021 at 06:57:39AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Sep 02, 2021 at 01:06:34PM -0500, Eric W. Biederman wrote:
> > > Sasha Levin <[email protected]> writes:
> > >
> > > > On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
> > > >>Greg Kroah-Hartman <[email protected]> writes:
> > > >>
> > > >>> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
> > > >>>> Greg Kroah-Hartman <[email protected]> writes:
> > > >>>>
> > > >>>> > From: Alexey Gladkov <[email protected]>
> > > >>>> >
> > > >>>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
> > > >>>> >
> > > >>>> > We need to increment the ucounts reference counter befor security_prepare_creds()
> > > >>>> > because this function may fail and abort_creds() will try to decrement
> > > >>>> > this reference.
> > > >>>>
> > > >>>> Has the conversion of the rlimits to ucounts been backported?
> > > >>>>
> > > >>>> Semantically the code is an improvement but I don't know of any cases
> > > >>>> where it makes enough of a real-world difference to make it worth
> > > >>>> backporting the code.
> > > >>>>
> > > >>>> Certainly the ucount/rlimit conversions do not meet the historical
> > > >>>> criteria for backports. AKA simple obviously correct patches.
> > > >>>>
> > > >>>> The fact we have been applying fixes for the entire v5.14 stabilization
> > > >>>> period is a testament to the code not quite being obviously correct.
> > > >>>>
> > > >>>> Without backports the code only affects v5.14 so I have not been
> > > >>>> including a Cc stable on any of the commits.
> > > >>>>
> > > >>>> So color me very puzzled about what is going on here.
> > > >>>
> > > >>> Sasha picked this for some reason, but if you think it should be
> > > >>> dropped, we can easily do so.
> > > >>
> > > >>My question is what is the reason Sasha picked this up?
> > > >>
> > > >>If this patch even applies to v5.10 the earlier patches have been
> > > >>backported. So we can't just drop this patch. Either the earlier
> > > >>backports need to be reverted, or we need to make certain all of the
> > > >>patches are backported.
> > > >>
> > > >>I really am trying to understand what is going on and why.
> > > >
> > > > I'll happily explain. The commit message is telling us that:
> > > >
> > > > 1. There is an issue uncovered by syzbot which this patch fixes:
> > > >
> > > > "Reported-by: syzbot"
> > > >
> > > > 2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
> > > > for each cred"):
> > > >
> > > > "Fixes: 905ae01c4ae2"
> > > >
> > > > Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
> > > > I've queued it up.
> > >
> > > Which begs the question as Alex mentioned how did 905ae01c4ae2 get into
> > > 5.10, as it was merged to Linus's tree in the merge window for 5.14.
> > >
> > > > In general, if we're missing backports, backported something only
> > > > partially and should revert it, or anything else that might cause an
> > > > issue, we'd be more than happy to work with you to fix it up.
> > > >
> > > > All the patches we queue up get multiple rounds of emails and reviews,
> > > > if there is a better way to solicit reviews so that we won't up in a
> > > > place where you haven't noticed something going in earlier we'd be more
> > > > than happy to improve that process too.
> > >
> > > I have the bad feeling that 905ae01c4ae2 was backported because it was a
> > > prerequisite to something with a Fixes tag.
> > >
> > > Fixes tags especially in this instance don't mean code needs to go to
> > > stable Fixes tags mean that a bug was fixed. Since I thought the code
> > > only existed in Linus's tree, I haven't been adding Cc stable or even
> > > thinking about earlier kernels with respect to this code.
> > >
> > > I honestly can't keep up with the level of review needed for patches
> > > targeting Linus's tree. So I occasionally glance at patches destined
> > > for the stable tree.
> > >
> > > Most of the time it is something being backported without a stable tag,
> > > but with a fixes tag, that is unnecessary but generally harmless so I
> > > ignore it.
> > >
> > > In this instance it looks like a whole new feature that has had a rocky
> > > history and a lot of time to stablize is somehow backported to 5.10 and
> > > 5.13. I think all of the known issues are addressed but I won't know
> > > if all of the issues syzkaller can find are found for another couple of
> > > weeks.
> > >
> > > Because this code was not obviously correct, because this code did not
> > > have a stable tag, because I am not even certain it is stable yet,
> > > I am asking do you know how this code that feels to me like feature work
> > > wound up being backported? AKA why is 905ae01c4ae2 in 5.10 and 5.13.
> >
> > Looks like Sasha added it to the tree last week and it went out in the
> > last set of releases. Sasha, why was this added? Let me see if it was
> > a requirement of some other patch...
>
> Sorry, no, that was this patch, let me get my coffee before I dig into
> this...
Ok, it looks like the original patch came in through the AUTOSEL
process, and you were cc:ed on it back on July 4, 2021:
https://lore.kernel.org/r/[email protected]
In reading the changelog of the commit, and looking briefly at the
patch, I can see why it was selected as a candidate for backporting to
stable kernels (fixes reported problem from kernel test robot, fixes
reference counting logic, etc.)
So given that it seemed like a normal candidate for a stable fix, and no
one complained, after one week, it was applied to the tree on July 11
(but Sasha's scripts did NOT email you about that for some reason,
hopefully he has fixed that by now).
Then on July 12, I added commit 5e6b8a50a7ce ("cred: add missing return
error code when set_cred_ucounts() failed") to the stable patch queue,
as it fixed a reported problem in the original commit, and you were
copied on that.
Then later that day, it was put out for review:
https://lore.kernel.org/r/[email protected]
and you were copied on that as well.
So you should have an email trail of when this patch was submitted for
inclusion, and then put out for review. Do you not see them in your
email system?
I just tested a local build, and yes, it can easily be reverted (along
with a follow-on patch that was applied to resolve a problem with this
commit), and I will queue them up after this release happens, but for
now, I'll let this patch stay so that we do not break anyone.
thanks,
greg k-h
On Fri, Sep 03, 2021 at 08:50:39AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 03, 2021 at 07:00:09AM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Sep 03, 2021 at 06:57:39AM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 02, 2021 at 01:06:34PM -0500, Eric W. Biederman wrote:
> > > > Sasha Levin <[email protected]> writes:
> > > >
> > > > > On Wed, Sep 01, 2021 at 12:26:10PM -0500, Eric W. Biederman wrote:
> > > > >>Greg Kroah-Hartman <[email protected]> writes:
> > > > >>
> > > > >>> On Wed, Sep 01, 2021 at 09:25:25AM -0500, Eric W. Biederman wrote:
> > > > >>>> Greg Kroah-Hartman <[email protected]> writes:
> > > > >>>>
> > > > >>>> > From: Alexey Gladkov <[email protected]>
> > > > >>>> >
> > > > >>>> > [ Upstream commit bbb6d0f3e1feb43d663af089c7dedb23be6a04fb ]
> > > > >>>> >
> > > > >>>> > We need to increment the ucounts reference counter befor security_prepare_creds()
> > > > >>>> > because this function may fail and abort_creds() will try to decrement
> > > > >>>> > this reference.
> > > > >>>>
> > > > >>>> Has the conversion of the rlimits to ucounts been backported?
> > > > >>>>
> > > > >>>> Semantically the code is an improvement but I don't know of any cases
> > > > >>>> where it makes enough of a real-world difference to make it worth
> > > > >>>> backporting the code.
> > > > >>>>
> > > > >>>> Certainly the ucount/rlimit conversions do not meet the historical
> > > > >>>> criteria for backports. AKA simple obviously correct patches.
> > > > >>>>
> > > > >>>> The fact we have been applying fixes for the entire v5.14 stabilization
> > > > >>>> period is a testament to the code not quite being obviously correct.
> > > > >>>>
> > > > >>>> Without backports the code only affects v5.14 so I have not been
> > > > >>>> including a Cc stable on any of the commits.
> > > > >>>>
> > > > >>>> So color me very puzzled about what is going on here.
> > > > >>>
> > > > >>> Sasha picked this for some reason, but if you think it should be
> > > > >>> dropped, we can easily do so.
> > > > >>
> > > > >>My question is what is the reason Sasha picked this up?
> > > > >>
> > > > >>If this patch even applies to v5.10 the earlier patches have been
> > > > >>backported. So we can't just drop this patch. Either the earlier
> > > > >>backports need to be reverted, or we need to make certain all of the
> > > > >>patches are backported.
> > > > >>
> > > > >>I really am trying to understand what is going on and why.
> > > > >
> > > > > I'll happily explain. The commit message is telling us that:
> > > > >
> > > > > 1. There is an issue uncovered by syzbot which this patch fixes:
> > > > >
> > > > > "Reported-by: syzbot"
> > > > >
> > > > > 2. The issue was introduced in 905ae01c4ae2 ("Add a reference to ucounts
> > > > > for each cred"):
> > > > >
> > > > > "Fixes: 905ae01c4ae2"
> > > > >
> > > > > Since 905ae01c4ae2 exist in 5.10, and this patch seemed to fix an issue,
> > > > > I've queued it up.
> > > >
> > > > Which begs the question as Alex mentioned how did 905ae01c4ae2 get into
> > > > 5.10, as it was merged to Linus's tree in the merge window for 5.14.
> > > >
> > > > > In general, if we're missing backports, backported something only
> > > > > partially and should revert it, or anything else that might cause an
> > > > > issue, we'd be more than happy to work with you to fix it up.
> > > > >
> > > > > All the patches we queue up get multiple rounds of emails and reviews,
> > > > > if there is a better way to solicit reviews so that we won't up in a
> > > > > place where you haven't noticed something going in earlier we'd be more
> > > > > than happy to improve that process too.
> > > >
> > > > I have the bad feeling that 905ae01c4ae2 was backported because it was a
> > > > prerequisite to something with a Fixes tag.
> > > >
> > > > Fixes tags especially in this instance don't mean code needs to go to
> > > > stable Fixes tags mean that a bug was fixed. Since I thought the code
> > > > only existed in Linus's tree, I haven't been adding Cc stable or even
> > > > thinking about earlier kernels with respect to this code.
> > > >
> > > > I honestly can't keep up with the level of review needed for patches
> > > > targeting Linus's tree. So I occasionally glance at patches destined
> > > > for the stable tree.
> > > >
> > > > Most of the time it is something being backported without a stable tag,
> > > > but with a fixes tag, that is unnecessary but generally harmless so I
> > > > ignore it.
> > > >
> > > > In this instance it looks like a whole new feature that has had a rocky
> > > > history and a lot of time to stablize is somehow backported to 5.10 and
> > > > 5.13. I think all of the known issues are addressed but I won't know
> > > > if all of the issues syzkaller can find are found for another couple of
> > > > weeks.
> > > >
> > > > Because this code was not obviously correct, because this code did not
> > > > have a stable tag, because I am not even certain it is stable yet,
> > > > I am asking do you know how this code that feels to me like feature work
> > > > wound up being backported? AKA why is 905ae01c4ae2 in 5.10 and 5.13.
> > >
> > > Looks like Sasha added it to the tree last week and it went out in the
> > > last set of releases. Sasha, why was this added? Let me see if it was
> > > a requirement of some other patch...
> >
> > Sorry, no, that was this patch, let me get my coffee before I dig into
> > this...
>
> Ok, it looks like the original patch came in through the AUTOSEL
> process, and you were cc:ed on it back on July 4, 2021:
> https://lore.kernel.org/r/[email protected]
>
> In reading the changelog of the commit, and looking briefly at the
> patch, I can see why it was selected as a candidate for backporting to
> stable kernels (fixes reported problem from kernel test robot, fixes
> reference counting logic, etc.)
>
> So given that it seemed like a normal candidate for a stable fix, and no
> one complained, after one week, it was applied to the tree on July 11
> (but Sasha's scripts did NOT email you about that for some reason,
> hopefully he has fixed that by now).
>
> Then on July 12, I added commit 5e6b8a50a7ce ("cred: add missing return
> error code when set_cred_ucounts() failed") to the stable patch queue,
> as it fixed a reported problem in the original commit, and you were
> copied on that.
>
> Then later that day, it was put out for review:
> https://lore.kernel.org/r/[email protected]
> and you were copied on that as well.
>
> So you should have an email trail of when this patch was submitted for
> inclusion, and then put out for review. Do you not see them in your
> email system?
>
>
> I just tested a local build, and yes, it can easily be reverted (along
> with a follow-on patch that was applied to resolve a problem with this
> commit), and I will queue them up after this release happens, but for
> now, I'll let this patch stay so that we do not break anyone.
>
All now reverted.
thanks,
greg k-h