Re: [GIT PULL] Smack patches for v5.4

2019-09-23 Thread pr-tracker-bot
The pull request you sent on Mon, 23 Sep 2019 10:24:21 -0700:

> https://github.com/cschaufler/smack-next.git smack-for-5.4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e94f8ccde4710f9a3e51dd3bc6134c96e33f29b3

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] Smack patches for v5.4 - retry

2019-09-23 Thread Linus Torvalds
On Mon, Sep 23, 2019 at 2:35 PM Linus Torvalds
 wrote:
>
> On Mon, Sep 23, 2019 at 1:14 PM Casey Schaufler  
> wrote:
> >
> > Thank for the instruction. I think this is correct.
>
> Looks fine, pulled.

Oh, btw, can you get more signatures on your pgp key? I actually care
more about having a key than having a key with lots of signatures (*),
but signatures and a chain of trust would be good too.

   Linus

(*) To me, keys are more of a "yeah, I'm the same person that usually
sends these pull requests" than some kind of hard identity.


Re: [GIT PULL] Smack patches for v5.4 - retry

2019-09-23 Thread Linus Torvalds
On Mon, Sep 23, 2019 at 1:14 PM Casey Schaufler  wrote:
>
> Thank for the instruction. I think this is correct.

Looks fine, pulled.

That said, when I look closer:

> Jia-Ju Bai (1):
>   security: smack: Fix possible null-pointer dereferences in 
> smack_socket_sock_rcv_skb()

This one seems wrong.

Not seriously so, but the quoting the logic from the commit:

In smack_socket_sock_rcv_skb(), there is an if statement
on line 3920 to check whether skb is NULL:

if (skb && skb->secmark != 0)

This check indicates skb can be NULL in some cases.

and the fact is, skb _cannot_ be NULL, because when you test the
security of receiving an skb, you by definition always have an skb.

There is one single place that calls security_sock_rcv_skb(), and it
very much has a real skb.

So instead of adding a _new_ test for skb being NULL, the old test for
a NULL skb should just have been removed. It really doesn't make any
sense to have a NULL skb in that path - if some memory allocation had
failed on the receive path, that just means that the receive is never
done, it doesn't mean that you'd test a NULL skb for security policy
violations.

Anyway, it's pulled, but I think somebody should have checked and
thought about the automated tool reports a bit more..

   Linus


[GIT PULL] Smack patches for v5.4 - retry

2019-09-23 Thread Casey Schaufler
Hello Linus

Thank for the instruction. I think this is correct.
I have four patches for v5.4. Nothing is major. All but one are in
response to mechanically detected potential issues. The remaining
patch cleans up kernel-doc notations.


The following changes since commit 0ecfebd2b52404ae0c54a878c872bb93363ada36:

  Linux 5.2 (2019-07-07 15:41:56 -0700)

are available in the Git repository at:

  https://github.com/cschaufler/smack-next.git tags/smack-for-5.4-rc1

for you to fetch changes up to e5bfad3d7acc5702f32aafeb388362994f4d7bd0:

  smack: use GFP_NOFS while holding inode_smack::smk_lock (2019-09-04 09:37:07 
-0700)


I have four patches for v5.4. Nothing is major. All but one are in
response to mechanically detected potential issues. The remaining
patch cleans up kernel-doc notations.


Eric Biggers (1):
  smack: use GFP_NOFS while holding inode_smack::smk_lock

Jann Horn (1):
  Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set

Jia-Ju Bai (1):
  security: smack: Fix possible null-pointer dereferences in 
smack_socket_sock_rcv_skb()

luanshi (1):
  smack: fix some kernel-doc notations

 security/smack/smack_access.c |  6 +++---
 security/smack/smack_lsm.c| 40 
 2 files changed, 23 insertions(+), 23 deletions(-)




Re: [GIT PULL] Smack patches for v5.4

2019-09-23 Thread Linus Torvalds
On Mon, Sep 23, 2019 at 10:24 AM Casey Schaufler  wrote:
>
> This is my first direct pull request. I think I have followed process
> correctly, but if not I will attend to my error as required.

The contents look fine.

However, it's from an open hosting site - github. Which is fine, I
take pull requests from github all the time.  But I require that they
be sent using a signed tag, so that I can verify that yes, it's really
from you.

And no, I don't do pgp email, even t hough I see that there's a
signature on your email itself.

git uses pgp too, but unlike pgp email signatures, the git support for
pgp signing is useful and user-friendly and just _works_, rather than
the complete and useless disaster that is pgp email [1].

So please make it a signed tag with "git tag -s" and ask me to pull
that tag instead.

Linus

[1] 
https://www.vice.com/en_us/article/vvbw9a/even-the-inventor-of-pgp-doesnt-use-pgp


[GIT PULL] Smack patches for v5.4

2019-09-23 Thread Casey Schaufler
Hello Linus

I have four patches for v5.4. Nothing is major. All but one are in
response to mechanically detected potential issues. The remaining
patch cleans up kernel-doc notations.

This is my first direct pull request. I think I have followed process
correctly, but if not I will attend to my error as required.

The following changes since commit 0ecfebd2b52404ae0c54a878c872bb93363ada36:

  Linux 5.2 (2019-07-07 15:41:56 -0700)

are available in the Git repository at:

  https://github.com/cschaufler/smack-next.git smack-for-5.4

for you to fetch changes up to e5bfad3d7acc5702f32aafeb388362994f4d7bd0:

  smack: use GFP_NOFS while holding inode_smack::smk_lock (2019-09-04 09:37:07 
-0700)


Eric Biggers (1):
  smack: use GFP_NOFS while holding inode_smack::smk_lock

Jann Horn (1):
  Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set

Jia-Ju Bai (1):
  security: smack: Fix possible null-pointer dereferences in 
smack_socket_sock_rcv_skb()

luanshi (1):
  smack: fix some kernel-doc notations

 security/smack/smack_access.c |  6 +++---
 security/smack/smack_lsm.c| 40 
 2 files changed, 23 insertions(+), 23 deletions(-)




signature.asc
Description: OpenPGP digital signature