* Re: [question] should 363b02dab09b3 be backported to stable 4.1+?
@ 2017-12-15 3:58 ` Eric Biggers
0 siblings, 0 replies; 9+ messages in thread
From: Eric Biggers @ 2017-12-15 3:58 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: David Howells, Eric Biggers, Serge E. Hallyn, keyrings,
linux-security-module, linux-kernel, Greg Kroah-Hartman,
Sergey Senozhatsky
Hi Sergey,
On Fri, Dec 15, 2017 at 11:47:06AM +0900, Sergey Senozhatsky wrote:
> Hello David, Eric,
>
> please help me out.
>
> I'm looking at 363b02dab09b ("KEYS: Fix race between updating and finding
> a negative key") right now. So, I see that it has been backported to stable
> 4.4+. My question is -- do we have those test_bit(KEY_FLAG_INSTANTIATED)
> and test_bit(KEY_FLAG_NEGATIVE) races in stable 4.1?
>
Before 4.4 (146aa8b1453), ->reject_error was in union with ->type_data rather
than ->payload, and no key types that used ->type_data implemented ->update().
Therefore it was not possible to reproduce the crash.
I do see there was another possible race, only theoretically a problem on
architectures with weaker memory ordering than x86, where a key being negatively
instantiated could be momentarily observed to be positively instantiated. But
even then I don't see where it could be a real problem. (Note that most users
wait for KEY_FLAG_USER_CONSTRUCT rather than checking KEY_FLAG_INSTANTIATED
directly.)
You're free to backport the commit if you want to be absolutely sure, though I'd
personally be more worried about other backports that might have been missed,
and the bugs that haven't been found yet.
Eric
^ permalink raw reply [flat|nested] 9+ messages in thread* [question] should 363b02dab09b3 be backported to stable 4.1+?
@ 2017-12-15 3:58 ` Eric Biggers
0 siblings, 0 replies; 9+ messages in thread
From: Eric Biggers @ 2017-12-15 3:58 UTC (permalink / raw)
To: linux-security-module
Hi Sergey,
On Fri, Dec 15, 2017 at 11:47:06AM +0900, Sergey Senozhatsky wrote:
> Hello David, Eric,
>
> please help me out.
>
> I'm looking at 363b02dab09b ("KEYS: Fix race between updating and finding
> a negative key") right now. So, I see that it has been backported to stable
> 4.4+. My question is -- do we have those test_bit(KEY_FLAG_INSTANTIATED)
> and test_bit(KEY_FLAG_NEGATIVE) races in stable 4.1?
>
Before 4.4 (146aa8b1453), ->reject_error was in union with ->type_data rather
than ->payload, and no key types that used ->type_data implemented ->update().
Therefore it was not possible to reproduce the crash.
I do see there was another possible race, only theoretically a problem on
architectures with weaker memory ordering than x86, where a key being negatively
instantiated could be momentarily observed to be positively instantiated. But
even then I don't see where it could be a real problem. (Note that most users
wait for KEY_FLAG_USER_CONSTRUCT rather than checking KEY_FLAG_INSTANTIATED
directly.)
You're free to backport the commit if you want to be absolutely sure, though I'd
personally be more worried about other backports that might have been missed,
and the bugs that haven't been found yet.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [question] should 363b02dab09b3 be backported to stable 4.1+?
2017-12-15 3:58 ` Eric Biggers
(?)
@ 2017-12-15 5:08 ` Sergey Senozhatsky
-1 siblings, 0 replies; 9+ messages in thread
From: Sergey Senozhatsky @ 2017-12-15 5:08 UTC (permalink / raw)
To: linux-security-module
Hello Eric,
On (12/14/17 19:58), Eric Biggers wrote:
> Hi Sergey,
>
> On Fri, Dec 15, 2017 at 11:47:06AM +0900, Sergey Senozhatsky wrote:
> > Hello David, Eric,
> >
> > please help me out.
> >
> > I'm looking at 363b02dab09b ("KEYS: Fix race between updating and finding
> > a negative key") right now. So, I see that it has been backported to stable
> > 4.4+. My question is -- do we have those test_bit(KEY_FLAG_INSTANTIATED)
> > and test_bit(KEY_FLAG_NEGATIVE) races in stable 4.1?
> >
>
> Before 4.4 (146aa8b1453), ->reject_error was in union with ->type_data rather
> than ->payload, and no key types that used ->type_data implemented ->update().
> Therefore it was not possible to reproduce the crash.
>
> I do see there was another possible race, only theoretically a problem on
> architectures with weaker memory ordering than x86, where a key being negatively
> instantiated could be momentarily observed to be positively instantiated. But
> even then I don't see where it could be a real problem. (Note that most users
> wait for KEY_FLAG_USER_CONSTRUCT rather than checking KEY_FLAG_INSTANTIATED
> directly.)
thanks a ton. appreciate your help!
> You're free to backport the commit if you want to be absolutely sure, though I'd
> personally be more worried about other backports that might have been missed,
> and the bugs that haven't been found yet.
agreed.
-ss
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [question] should 363b02dab09b3 be backported to stable 4.1+?
@ 2017-12-15 5:08 ` Sergey Senozhatsky
0 siblings, 0 replies; 9+ messages in thread
From: Sergey Senozhatsky @ 2017-12-15 5:08 UTC (permalink / raw)
To: Eric Biggers
Cc: Sergey Senozhatsky, David Howells, Eric Biggers, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel, Greg Kroah-Hartman,
Sergey Senozhatsky
Hello Eric,
On (12/14/17 19:58), Eric Biggers wrote:
> Hi Sergey,
>
> On Fri, Dec 15, 2017 at 11:47:06AM +0900, Sergey Senozhatsky wrote:
> > Hello David, Eric,
> >
> > please help me out.
> >
> > I'm looking at 363b02dab09b ("KEYS: Fix race between updating and finding
> > a negative key") right now. So, I see that it has been backported to stable
> > 4.4+. My question is -- do we have those test_bit(KEY_FLAG_INSTANTIATED)
> > and test_bit(KEY_FLAG_NEGATIVE) races in stable 4.1?
> >
>
> Before 4.4 (146aa8b1453), ->reject_error was in union with ->type_data rather
> than ->payload, and no key types that used ->type_data implemented ->update().
> Therefore it was not possible to reproduce the crash.
>
> I do see there was another possible race, only theoretically a problem on
> architectures with weaker memory ordering than x86, where a key being negatively
> instantiated could be momentarily observed to be positively instantiated. But
> even then I don't see where it could be a real problem. (Note that most users
> wait for KEY_FLAG_USER_CONSTRUCT rather than checking KEY_FLAG_INSTANTIATED
> directly.)
thanks a ton. appreciate your help!
> You're free to backport the commit if you want to be absolutely sure, though I'd
> personally be more worried about other backports that might have been missed,
> and the bugs that haven't been found yet.
agreed.
-ss
^ permalink raw reply [flat|nested] 9+ messages in thread* [question] should 363b02dab09b3 be backported to stable 4.1+?
@ 2017-12-15 5:08 ` Sergey Senozhatsky
0 siblings, 0 replies; 9+ messages in thread
From: Sergey Senozhatsky @ 2017-12-15 5:08 UTC (permalink / raw)
To: linux-security-module
Hello Eric,
On (12/14/17 19:58), Eric Biggers wrote:
> Hi Sergey,
>
> On Fri, Dec 15, 2017 at 11:47:06AM +0900, Sergey Senozhatsky wrote:
> > Hello David, Eric,
> >
> > please help me out.
> >
> > I'm looking at 363b02dab09b ("KEYS: Fix race between updating and finding
> > a negative key") right now. So, I see that it has been backported to stable
> > 4.4+. My question is -- do we have those test_bit(KEY_FLAG_INSTANTIATED)
> > and test_bit(KEY_FLAG_NEGATIVE) races in stable 4.1?
> >
>
> Before 4.4 (146aa8b1453), ->reject_error was in union with ->type_data rather
> than ->payload, and no key types that used ->type_data implemented ->update().
> Therefore it was not possible to reproduce the crash.
>
> I do see there was another possible race, only theoretically a problem on
> architectures with weaker memory ordering than x86, where a key being negatively
> instantiated could be momentarily observed to be positively instantiated. But
> even then I don't see where it could be a real problem. (Note that most users
> wait for KEY_FLAG_USER_CONSTRUCT rather than checking KEY_FLAG_INSTANTIATED
> directly.)
thanks a ton. appreciate your help!
> You're free to backport the commit if you want to be absolutely sure, though I'd
> personally be more worried about other backports that might have been missed,
> and the bugs that haven't been found yet.
agreed.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread