Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 24 7月, 2013 1 次提交
  3. 10 7月, 2013 1 次提交
  5. 04 7月, 2013 3 次提交
  7. 25 6月, 2013 1 次提交
    • H
      crypto: algboss - Hold ref count on larval · 939e1779
      由 Herbert Xu 提交于 
      On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote:
> After having fixed a NULL pointer dereference in SCTP 1abd165e ("net:
> sctp: fix NULL pointer dereference in socket destruction"), I ran into
> the following NULL pointer dereference in the crypto subsystem with
> the same reproducer, easily hit each time:
> 
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [<ffffffff81070321>] __wake_up_common+0x31/0x90
> PGD 0
> Oops: 0000 [#1] SMP
> Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
> CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF            3.10.0-rc5+ #1
> Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
> task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000
> RIP: 0010:[<ffffffff81070321>]  [<ffffffff81070321>] __wake_up_common+0x31/0x90
> RSP: 0018:ffff88007b7cde08  EFLAGS: 00010082
> RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130
> RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282
> R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Stack:
>  ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130
>  0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000
>  ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540
> Call Trace:
>  [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20
>  [<ffffffff810722b7>] complete_all+0x47/0x60
>  [<ffffffff81227708>] cryptomgr_probe+0x98/0xc0
>  [<ffffffff81227670>] ? crypto_alloc_pcomp+0x20/0x20
>  [<ffffffff8106760e>] kthread+0xce/0xe0
>  [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70
>  [<ffffffff815450dc>] ret_from_fork+0x7c/0xb0
>  [<ffffffff81067540>] ? kthread_freezable_should_stop+0x70/0x70
> Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
>       4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
> RIP  [<ffffffff81070321>] __wake_up_common+0x31/0x90
>  RSP <ffff88007b7cde08>
> CR2: 0000000000000000
> ---[ end trace b495b19270a4d37e ]---
> 
> My assumption is that the following is happening: the minimal SCTP
> tool runs under ``echo 1 > /proc/sys/net/sctp/auth_enable'', hence
> it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
> It forks itself, heavily allocates, binds, listens and waits in
> accept on sctp sockets, and then randomly kills some of them (no
> need for an actual client in this case to hit this). Then, again,
> allocating, binding, etc, and then killing child processes.
> 
> The problem that might be happening here is that cryptomgr requests
> the module to probe/load through cryptomgr_schedule_probe(), but
> before the thread handler cryptomgr_probe() returns, we return from
> the wait_for_completion_interruptible() function and probably already
> have cleared up larval, thus we run into a NULL pointer dereference
> when in cryptomgr_probe() complete_all() is being called.
> 
> If we wait with wait_for_completion() instead, this panic will not
> occur anymore. This is valid, because in case a signal is pending,
> cryptomgr_probe() returns from probing anyway with properly calling
> complete_all().

The use of wait_for_completion_interruptible is intentional so that
we don't lock up the thread if a bug causes us to never wake up.

This bug is caused by the helper thread using the larval without
holding a reference count on it.  If the helper thread completes
after the original thread requesting for help has gone away and
destroyed the larval, then we get the crash above.

So the fix is to hold a reference count on the larval.

Cc: <stable@vger.kernel.org> # 3.6+
Reported-by: NDaniel Borkmann <dborkman@redhat.com>
Tested-by: NDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      939e1779
  9. 21 6月, 2013 6 次提交
  11. 05 6月, 2013 2 次提交
  13. 28 5月, 2013 1 次提交
  15. 24 5月, 2013 2 次提交
  17. 20 5月, 2013 1 次提交
  19. 30 4月, 2013 1 次提交
  21. 25 4月, 2013 16 次提交
  23. 22 4月, 2013 1 次提交
    • C
      X.509: Support parse long form of length octets in Authority Key Identifier · 04b00bdb
      由 Chun-Yi Lee 提交于 
      Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
   The example certificate demos/tunala/A-server.pem in openssl source:

X509v3 Authority Key Identifier:
    keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
    DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
    serial:00

Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:

[   12.061147] X.509: Extension: 47
[   12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)

So, this patch add the parsing rule for support long form format against
Authority Key Identifier.

v3:
Changed the size check in "Short Form length" case, we allow v[3] smaller
then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
are also possible attach in AuthorityKeyIdentifier sequence.

v2:
 - Removed comma from author's name.
 - Moved 'Short Form length' comment inside the if-body.
 - Changed the type of sub to size_t.
 - Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
 - Moved the key_len's value assignment before alter v.
 - Fixed the typo of octets.
 - Add 2 to v before entering the loop for calculate the length.
 - Removed the comment of check vlen.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NChun-Yi Lee <jlee@suse.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      04b00bdb
  25. 10 4月, 2013 1 次提交
  27. 03 4月, 2013 1 次提交
  29. 02 4月, 2013 1 次提交
  31. 10 3月, 2013 1 次提交