1. 12 Feb, 2019 2 commits
    • Bart Van Assche's avatar
      lib/test_rhashtable: Make test_insert_dup() allocate its hash table dynamically · 5dd31dbc
      Bart Van Assche authored
      [ Upstream commit fc42a689 ]
      
      The test_insert_dup() function from lib/test_rhashtable.c passes a
      pointer to a stack object to rhltable_init(). Allocate the hash table
      dynamically to avoid that the following is reported with object
      debugging enabled:
      
      ODEBUG: object (ptrval) is on stack (ptrval), but NOT annotated.
      WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:368 __debug_object_init+0x312/0x480
      Modules linked in:
      EIP: __debug_object_init+0x312/0x480
      Call Trace:
       ? debug_object_init+0x1a/0x20
       ? __init_work+0x16/0x30
       ? rhashtable_init+0x1e1/0x460
       ? sched_clock_cpu+0x57/0xe0
       ? rhltable_init+0xb/0x20
       ? test_insert_dup+0x32/0x20f
       ? trace_hardirqs_on+0x38/0xf0
       ? ida_dump+0x10/0x10
       ? jhash+0x130/0x130
       ? my_hashfn+0x30/0x30
       ? test_rht_init+0x6aa/0xab4
       ? ida_dump+0x10/0x10
       ? test_rhltable+0xc5c/0xc5c
       ? do_one_initcall+0x67/0x28e
       ? trace_hardirqs_off+0x22/0xe0
       ? restore_all_kernel+0xf/0x70
       ? trace_hardirqs_on_thunk+0xc/0x10
       ? restore_all_kernel+0xf/0x70
       ? kernel_init_freeable+0x142/0x213
       ? rest_init+0x230/0x230
       ? kernel_init+0x10/0x110
       ? schedule_tail_wrapper+0x9/0xc
       ? ret_from_fork+0x19/0x24
      
      Cc: Thomas Graf <tgraf@suug.ch>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: 's avatarBart Van Assche <bvanassche@acm.org>
      Acked-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dd31dbc
    • Michael Ellerman's avatar
      seq_buf: Make seq_buf_puts() null-terminate the buffer · 5f48eb89
      Michael Ellerman authored
      [ Upstream commit 0464ed24 ]
      
      Currently seq_buf_puts() will happily create a non null-terminated
      string for you in the buffer. This is particularly dangerous if the
      buffer is on the stack.
      
      For example:
      
        char buf[8];
        char secret = "secret";
        struct seq_buf s;
      
        seq_buf_init(&s, buf, sizeof(buf));
        seq_buf_puts(&s, "foo");
        printk("Message is %s\n", buf);
      
      Can result in:
      
        Message is fooªªªªªsecret
      
      We could require all users to memset() their buffer to zero before
      use. But that seems likely to be forgotten and lead to bugs.
      
      Instead we can change seq_buf_puts() to always leave the buffer in a
      null-terminated state.
      
      The only downside is that this makes the buffer 1 character smaller
      for seq_buf_puts(), but that seems like a good trade off.
      
      Link: http://lkml.kernel.org/r/20181019042109.8064-1-mpe@ellerman.id.auAcked-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      5f48eb89
  2. 22 Jan, 2019 1 commit
  3. 13 Jan, 2019 1 commit
  4. 13 Dec, 2018 1 commit
  5. 06 Dec, 2018 3 commits
  6. 30 Nov, 2018 3 commits
  7. 25 Nov, 2018 1 commit
  8. 19 Nov, 2018 1 commit
  9. 18 Nov, 2018 1 commit
  10. 16 Nov, 2018 2 commits
  11. 11 Nov, 2018 1 commit
  12. 06 Nov, 2018 1 commit
  13. 05 Nov, 2018 8 commits
  14. 31 Oct, 2018 14 commits