Message ID | 745ac819-f2ae-4525-1855-535daf783638@schaufler-ca.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] Smack patches for v5.4 - retry | expand |
On Mon, Sep 23, 2019 at 1:14 PM Casey Schaufler <casey@schaufler-ca.com> 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
On Mon, Sep 23, 2019 at 2:35 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Sep 23, 2019 at 1:14 PM Casey Schaufler <casey@schaufler-ca.com> 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.