[GIT PULL] Keys: fix C++ reserved word issue

Please pull this revert and update, from David Howells:

"Here's a pair of fixes that need to go upstream asap, please:

 (1) Revert an incorrect fix to the keyrings UAPI for a C++ reserved word
     used as a struct member name.  This change being reverted breaks
     existing userspace code and is thus incorrect.

     Further, *neither* name is consistent with the one in the keyutils
     package public header.

 (2) Fix the problem by using a union to make the name from keyutils
     available in parallel and make the 'private' name unavailable in C++
     with cpp-conditionals."

---
The following changes since commit 02214bfc89c71bcc5167f653994cfa5c57f10ff1:

  Merge tag 'media/v4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2018-09-24 15:16:41 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v4.19-rc5

for you to fetch changes up to cae081e4d49ac9be127c4e1b876bb685c2c04159:

  keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h (2018-09-24 13:51:12 -0700)

----------------------------------------------------------------
David Howells (1):
      keys: Fix the use of the C++ keyword "private" in uapi/linux/keyctl.h

Lubomir Rintel (1):
      Revert "uapi/linux/keyctl.h: don't use C++ reserved keyword as a struct member name"

 include/uapi/linux/keyctl.h | 7 ++++++-
 security/keys/dh.c          | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 910cc4334b21..0f3cb13db8e9 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h

@@ -65,7 +65,12 @@
 
 /* keyctl structures */
 struct keyctl_dh_params {
-	__s32 dh_private;
+	union {
+#ifndef __cplusplus
+		__s32 private;
+#endif
+		__s32 priv;
+	};
 	__s32 prime;
 	__s32 base;
 };

diff --git a/security/keys/dh.c b/security/keys/dh.c
index 3b602a1e27fa..711e89d8c415 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c

@@ -300,7 +300,7 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user *params,
 	}
 	dh_inputs.g_size = dlen;
 
-	dlen = dh_data_from_key(pcopy.dh_private, &dh_inputs.key);
+	dlen = dh_data_from_key(pcopy.private, &dh_inputs.key);
 	if (dlen < 0) {
 		ret = dlen;
 		goto out2;

On Tue, Sep 25, 2018 at 07:40:06AM +1000, James Morris wrote:

Please pull this revert and update, from David Howells:

"Here's a pair of fixes that need to go upstream asap, please:

 (1) Revert an incorrect fix to the keyrings UAPI for a C++ reserved word
     used as a struct member name.  This change being reverted breaks
     existing userspace code and is thus incorrect.

     Further, *neither* name is consistent with the one in the keyutils
     package public header.

 (2) Fix the problem by using a union to make the name from keyutils
     available in parallel and make the 'private' name unavailable in C++
     with cpp-conditionals."

---
The following changes since commit 02214bfc89c71bcc5167f653994cfa5c57f10ff1:

  Merge tag 'media/v4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2018-09-24 15:16:41 +0200)

{sigh}

$ date --date="2018-09-25 07:40:06 +1000" +%s
1537825206
$ date --date="2018-09-24 15:16:41 +0200" +%s
1537795001
$ bc <<< "1537825206-1537795001"
30205
$ date -ud "@30205" +'%H hours %M minutes %S seconds'
08 hours 23 minutes 25 seconds

8.5 hours seems like a short amount of time for something to sit in a
tree before asking for it to be merged.  Wait, it's actually less than
that, I just took into account the longest possible time it could have
been in your tree.

I'll wait a few days on this one...

thanks,

greg k-h

Greg KH [off-list ref] wrote:

I'll wait a few days on this one...

Can you at least apply the reversion patch?  UAPI is currently broken by the
change that needs reverting.

David

On Tue, Sep 25, 2018 at 11:17:00AM +0100, David Howells wrote:

Greg KH [off-list ref] wrote:

quoted

I'll wait a few days on this one...

Can you at least apply the reversion patch?  UAPI is currently broken by the
change that needs reverting.

Yes, as that's obviously correct.  I think you should wait for your
patch 2 here until 4.20-rc1, as this isn't a "fix" that is required at
this point in time.

I'll just go cherry-pick that one patch, thanks.

greg k-h

On Tue, 25 Sep 2018, Greg KH wrote:

On Tue, Sep 25, 2018 at 11:17:00AM +0100, David Howells wrote:

quoted

Greg KH [off-list ref] wrote:

quoted

I'll wait a few days on this one...

Can you at least apply the reversion patch?  UAPI is currently broken by the
change that needs reverting.

Yes, as that's obviously correct.  I think you should wait for your
patch 2 here until 4.20-rc1, as this isn't a "fix" that is required at
this point in time.

Ok, I'll queue this for the merge window.


-- 
James Morris
[off-list ref]