1. 08 Sep, 2019 1 commit
  2. 07 Sep, 2019 2 commits
    • Arnd Bergmann's avatar
      ipc: fix sparc64 ipc() wrapper · fb377eb8
      Arnd Bergmann authored
      
      
      Matt bisected a sparc64 specific issue with semctl, shmctl and msgctl
      to a commit from my y2038 series in linux-5.1, as I missed the custom
      sys_ipc() wrapper that sparc64 uses in place of the generic version that
      I patched.
      
      The problem is that the sys_{sem,shm,msg}ctl() functions in the kernel
      now do not allow being called with the IPC_64 flag any more, resulting
      in a -EINVAL error when they don't recognize the command.
      
      Instead, the correct way to do this now is to call the internal
      ksys_old_{sem,shm,msg}ctl() functions to select the API version.
      
      As we generally move towards these functions anyway, change all of
      sparc_ipc() to consistently use those in place of the sys_*() versions,
      and move the required ksys_*() declarations into linux/syscalls.h
      
      The IS_ENABLED(CONFIG_SYSVIPC) check is required to avoid link
      errors when ipc is disabled.
      
      Reported-by: default avatarMatt Turner <mattst88@gmail.com>
      Fixes: 275f2214
      
       ("ipc: rename old-style shmctl/semctl/msgctl syscalls")
      Cc: stable@vger.kernel.org
      Tested-by: default avatarMatt Turner <mattst88@gmail.com>
      Tested-by: default avatarAnatoly Pugachev <matorola@gmail.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      fb377eb8
    • Eric Biggers's avatar
      isdn/capi: check message length in capi_write() · fe163e53
      Eric Biggers authored
      
      
      syzbot reported:
      
          BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700
          CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2
          Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
          Call Trace:
            __dump_stack lib/dump_stack.c:77 [inline]
            dump_stack+0x173/0x1d0 lib/dump_stack.c:113
            kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
            __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
            capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700
            do_loop_readv_writev fs/read_write.c:703 [inline]
            do_iter_write+0x83e/0xd80 fs/read_write.c:961
            vfs_writev fs/read_write.c:1004 [inline]
            do_writev+0x397/0x840 fs/read_write.c:1039
            __do_sys_writev fs/read_write.c:1112 [inline]
            __se_sys_writev+0x9b/0xb0 fs/read_write.c:1109
            __x64_sys_writev+0x4a/0x70 fs/read_write.c:1109
            do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
            entry_SYSCALL_64_after_hwframe+0x63/0xe7
          [...]
      
      The problem is that capi_write() is reading past the end of the message.
      Fix it by checking the message's length in the needed places.
      
      Reported-and-tested-by: default avatar <syzbot+0849c524d9c634f5ae66@syzkaller.appspotmail.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe163e53
  3. 06 Sep, 2019 2 commits
    • Benjamin Tissoires's avatar
      Input: elan_i2c - remove Lenovo Legion Y7000 PnpID · 0c043d70
      Benjamin Tissoires authored
      Looks like the Bios of the Lenovo Legion Y7000 is using ELAN061B
      when the actual device is supposed to be used with hid-multitouch.
      
      Remove it from the list of the supported device, hoping that
      no one will complain about the loss in functionality.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=203467
      Fixes: 738c06d0
      
       ("Input: elan_i2c - add hardware ID for multiple Lenovo laptops")
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      0c043d70
    • Arnd Bergmann's avatar
      ipc: fix semtimedop for generic 32-bit architectures · 78e05972
      Arnd Bergmann authored
      As Vincent noticed, the y2038 conversion of semtimedop in linux-5.1
      broke when commit 00bf25d6
      
       ("y2038: use time32 syscall names on
      32-bit") changed all system calls on all architectures that take
      a 32-bit time_t to point to the _time32 implementation, but left out
      semtimedop in the asm-generic header.
      
      This affects all 32-bit architectures using asm-generic/unistd.h:
      h8300, unicore32, openrisc, nios2, hexagon, c6x, arc, nds32 and csky.
      
      The notable exception is riscv32, which has dropped support for the
      time32 system calls entirely.
      
      Reported-by: default avatarVincent Chen <deanbo422@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: Vincent Chen <deanbo422@gmail.com>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
      Cc: Guo Ren <guoren@kernel.org>
      Fixes: 00bf25d6
      
       ("y2038: use time32 syscall names on 32-bit")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      78e05972
  4. 05 Sep, 2019 2 commits
    • Donald Sharp's avatar
      net: Properly update v4 routes with v6 nexthop · 7bdf4de1
      Donald Sharp authored
      When creating a v4 route that uses a v6 nexthop from a nexthop group.
      Allow the kernel to properly send the nexthop as v6 via the RTA_VIA
      attribute.
      
      Broken behavior:
      
      $ ip nexthop add via fe80::9 dev eth0
      $ ip nexthop show
      id 1 via fe80::9 dev eth0 scope link
      $ ip route add 4.5.6.7/32 nhid 1
      $ ip route show
      default via 10.0.2.2 dev eth0
      4.5.6.7 nhid 1 via 254.128.0.0 dev eth0
      10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
      $
      
      Fixed behavior:
      
      $ ip nexthop add via fe80::9 dev eth0
      $ ip nexthop show
      id 1 via fe80::9 dev eth0 scope link
      $ ip route add 4.5.6.7/32 nhid 1
      $ ip route show
      default via 10.0.2.2 dev eth0
      4.5.6.7 nhid 1 via inet6 fe80::9 dev eth0
      10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
      $
      
      v2, v3: Addresses code review comments from David Ahern
      
      Fixes: dcb1ecb5
      
       (“ipv4: Prepare for fib6_nh from a nexthop object”)
      Signed-off-by: default avatarDonald Sharp <sharpd@cumulusnetworks.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7bdf4de1
    • Moritz Fischer's avatar
      net: fixed_phy: Add forward declaration for struct gpio_desc; · ebe26aca
      Moritz Fischer authored
      Add forward declaration for struct gpio_desc in order to address
      the following:
      
      ./include/linux/phy_fixed.h:48:17: error: 'struct gpio_desc' declared inside parameter list [-Werror]
      ./include/linux/phy_fixed.h:48:17: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
      
      Fixes: 71bd106d
      
       ("net: fixed-phy: Add fixed_phy_register_with_gpiod() API")
      Signed-off-by: default avatarMoritz Fischer <mdf@kernel.org>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebe26aca
  5. 03 Sep, 2019 4 commits
  6. 02 Sep, 2019 1 commit
  7. 31 Aug, 2019 2 commits
  8. 29 Aug, 2019 1 commit
    • Gustavo A. R. Silva's avatar
      nds32: Mark expected switch fall-throughs · 7c9eb2db
      Gustavo A. R. Silva authored
      
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warnings (Building: allmodconfig nds32):
      
      include/math-emu/soft-fp.h:124:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
      arch/nds32/kernel/signal.c:362:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
      arch/nds32/kernel/signal.c:315:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:417:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:430:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/soft-fp.h:124:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:417:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:430:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      7c9eb2db
  9. 28 Aug, 2019 3 commits
  10. 27 Aug, 2019 3 commits
    • Cong Wang's avatar
      net_sched: fix a NULL pointer deref in ipt action · 981471bd
      Cong Wang authored
      The net pointer in struct xt_tgdtor_param is not explicitly
      initialized therefore is still NULL when dereferencing it.
      So we have to find a way to pass the correct net pointer to
      ipt_destroy_target().
      
      The best way I find is just saving the net pointer inside the per
      netns struct tcf_idrinfo, which could make this patch smaller.
      
      Fixes: 0c66dc1e
      
       ("netfilter: conntrack: register hooks in netns when needed by ruleset")
      Reported-and-tested-by: default avatar <itugrok@yahoo.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      981471bd
    • David Howells's avatar
      rxrpc: Use skb_unshare() rather than skb_cow_data() · d0d5c0cd
      David Howells authored
      The in-place decryption routines in AF_RXRPC's rxkad security module
      currently call skb_cow_data() to make sure the data isn't shared and that
      the skb can be written over.  This has a problem, however, as the softirq
      handler may be still holding a ref or the Rx ring may be holding multiple
      refs when skb_cow_data() is called in rxkad_verify_packet() - and so
      skb_shared() returns true and __pskb_pull_tail() dislikes that.  If this
      occurs, something like the following report will be generated.
      
      	kernel BUG at net/core/skbuff.c:1463!
      	...
      	RIP: 0010:pskb_expand_head+0x253/0x2b0
      	...
      	Call Trace:
      	 __pskb_pull_tail+0x49/0x460
      	 skb_cow_data+0x6f/0x300
      	 rxkad_verify_packet+0x18b/0xb10 [rxrpc]
      	 rxrpc_recvmsg_data.isra.11+0x4a8/0xa10 [rxrpc]
      	 rxrpc_kernel_recv_data+0x126/0x240 [rxrpc]
      	 afs_extract_data+0x51/0x2d0 [kafs]
      	 afs_deliver_fs_fetch_data+0x188/0x400 [kafs]
      	 afs_deliver_to_call+0xac/0x430 [kafs]
      	 afs_wait_for_call_to_complete+0x22f/0x3d0 [kafs]
      	 afs_make_call+0x282/0x3f0 [kafs]
      	 afs_fs_fetch_data+0x164/0x300 [kafs]
      	 afs_fetch_data+0x54/0x130 [kafs]
      	 afs_readpages+0x20d/0x340 [kafs]
      	 read_pages+0x66/0x180
      	 __do_page_cache_readahead+0x188/0x1a0
      	 ondemand_readahead+0x17d/0x2e0
      	 generic_file_read_iter+0x740/0xc10
      	 __vfs_read+0x145/0x1a0
      	 vfs_read+0x8c/0x140
      	 ksys_read+0x4a/0xb0
      	 do_syscall_64+0x43/0xf0
      	 entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fix this by using skb_unshare() instead in the input path for DATA packets
      that have a security index != 0.  Non-DATA packets don't need in-place
      encryption and neither do unencrypted DATA packets.
      
      Fixes: 248f219c
      
       ("rxrpc: Rewrite the data and ack handling code")
      Reported-by: default avatarJulian Wollrath <jwollrath@web.de>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d0d5c0cd
    • David Howells's avatar
      rxrpc: Use the tx-phase skb flag to simplify tracing · 987db9f7
      David Howells authored
      
      
      Use the previously-added transmit-phase skbuff private flag to simplify the
      socket buffer tracing a bit.  Which phase the skbuff comes from can now be
      divined from the skb rather than having to be guessed from the call state.
      
      We can also reduce the number of rxrpc_skb_trace values by eliminating the
      difference between Tx and Rx in the symbols.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      987db9f7
  11. 26 Aug, 2019 2 commits
  12. 25 Aug, 2019 1 commit
    • David Ahern's avatar
      nexthop: Fix nexthop_num_path for blackhole nexthops · 9b5f6841
      David Ahern authored
      Donald reported this sequence:
        ip next add id 1 blackhole
        ip next add id 2 blackhole
        ip ro add 1.1.1.1/32 nhid 1
        ip ro add 1.1.1.2/32 nhid 2
      
      would cause a crash. Backtrace is:
      
      [  151.302790] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  151.304043] CPU: 1 PID: 277 Comm: ip Not tainted 5.3.0-rc5+ #37
      [  151.305078] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014
      [  151.306526] RIP: 0010:fib_add_nexthop+0x8b/0x2aa
      [  151.307343] Code: 35 f7 81 48 8d 14 01 c7 02 f1 f1 f1 f1 c7 42 04 01 f4 f4 f4 48 89 f2 48 c1 ea 03 65 48 8b 0c 25 28 00 00 00 48 89 4d d0 31 c9 <80> 3c 02 00 74 08 48 89 f7 e8 1a e8 53 ff be 08 00 00 00 4c 89 e7
      [  151.310549] RSP: 0018:ffff888116c27340 EFLAGS: 00010246
      [  151.311469] RAX: dffffc0000000000 RBX: ffff8881154ece00 RCX: 0000000000000000
      [  151.312713] RDX: 0000000000000004 RSI: 0000000000000020 RDI: ffff888115649b40
      [  151.313968] RBP: ffff888116c273d8 R08: ffffed10221e3757 R09: ffff888110f1bab8
      [  151.315212] R10: 0000000000000001 R11: ffff888110f1bab3 R12: ffff888115649b40
      [  151.316456] R13: 0000000000000020 R14: ffff888116c273b0 R15: ffff888115649b40
      [  151.317707] FS:  00007f60b4d8d800(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
      [  151.319113] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  151.320119] CR2: 0000555671ffdc00 CR3: 00000001136ba005 CR4: 0000000000020ee0
      [  151.321367] Call Trace:
      [  151.321820]  ? fib_nexthop_info+0x635/0x635
      [  151.322572]  fib_dump_info+0xaa4/0xde0
      [  151.323247]  ? fib_create_info+0x2431/0x2431
      [  151.324008]  ? napi_alloc_frag+0x2a/0x2a
      [  151.324711]  rtmsg_fib+0x2c4/0x3be
      [  151.325339]  fib_table_insert+0xe2f/0xeee
      ...
      
      fib_dump_info incorrectly has nhs = 0 for blackhole nexthops, so it
      believes the nexthop object is a multipath group (nhs != 1) and ends
      up down the nexthop_mpath_fill_node() path which is wrong for a
      blackhole.
      
      The blackhole check in nexthop_num_path is leftover from early days
      of the blackhole implementation which did not initialize the device.
      In the end the design was simpler (fewer special case checks) to set
      the device to loopback in nh_info, so the check in nexthop_num_path
      should have been removed.
      
      Fixes: 430a0491
      
       ("nexthop: Add support for nexthop groups")
      Reported-by: default avatarDonald Sharp <sharpd@cumulusnetworks.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b5f6841
  13. 24 Aug, 2019 2 commits
    • Zhu Yanjun's avatar
      net: rds: add service level support in rds-info · e0e6d062
      Zhu Yanjun authored
      >From IB specific 7.6.5 SERVICE LEVEL, Service Level (SL)
      is used to identify different flows within an IBA subnet.
      It is carried in the local route header of the packet.
      
      Before this commit, run "rds-info -I". The outputs are as
      below:
      "
      RDS IB Connections:
       LocalAddr  RemoteAddr Tos SL  LocalDev               RemoteDev
      192.2.95.3  192.2.95.1  2   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  1   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  0   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      "
      After this commit, the output is as below:
      "
      RDS IB Connections:
       LocalAddr  RemoteAddr Tos SL  LocalDev               RemoteDev
      192.2.95.3  192.2.95.1  2   2  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  1   1  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  0   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      "
      
      The commit fe3475af ("net: rds: add per rds connection cache
      statistics") adds cache_allocs in struct rds_info_rdma_connection
      as below:
      struct rds_info_rdma_connection {
      ...
              __u32           rdma_mr_max;
              __u32           rdma_mr_size;
              __u8            tos;
              __u32           cache_allocs;
       };
      The peer struct in rds-tools of struct rds_info_rdma_connection is as
      below:
      struct rds_info_rdma_connection {
      ...
              uint32_t        rdma_mr_max;
              uint32_t        rdma_mr_size;
              uint8_t         tos;
              uint8_t         sl;
              uint32_t        cache_allocs;
      };
      The difference between userspace and kernel is the member variable sl.
      In the kernel struct, the member variable sl is missing. This will
      introduce risks. So it is necessary to use this commit to avoid this risk.
      
      Fixes: fe3475af
      
       ("net: rds: add per rds connection cache statistics")
      CC: Joe Jin <joe.jin@oracle.com>
      CC: JUNXIAO_BI <junxiao.bi@oracle.com>
      Suggested-by: default avatarGerd Rausch <gerd.rausch@oracle.com>
      Signed-off-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0e6d062
    • John Fastabend's avatar
      net: route dump netlink NLM_F_MULTI flag missing · e93fb3e9
      John Fastabend authored
      An excerpt from netlink(7) man page,
      
        In multipart messages (multiple nlmsghdr headers with associated payload
        in one byte stream) the first and all following headers have the
        NLM_F_MULTI flag set, except for the last  header  which  has the type
        NLMSG_DONE.
      
      but, after (ee28906f) there is a missing NLM_F_MULTI flag in the middle of a
      FIB dump. The result is user space applications following above man page
      excerpt may get confused and may stop parsing msg believing something went
      wrong.
      
      In the golang netlink lib [0] the library logic stops parsing believing the
      message is not a multipart message. Found this running Cilium[1] against
      net-next while adding a feature to auto-detect routes. I noticed with
      multiple route tables we no longer could detect the default routes on net
      tree kernels because the library logic was not returning them.
      
      Fix this by handling the fib_dump_info_fnhe() case the same way the
      fib_dump_info() handles it by passing the flags argument through the
      call chain and adding a flags argument to rt_fill_info().
      
      Tested with Cilium stack and auto-detection of routes works again. Also
      annotated libs to dump netlink msgs and inspected NLM_F_MULTI and
      NLMSG_DONE flags look correct after this.
      
      Note: In inet_rtm_getroute() pass rt_fill_info() '0' for flags the same
      as is done for fib_dump_info() so this looks correct to me.
      
      [0] https://github.com/vishvananda/netlink/
      [1] https://github.com/cilium/
      
      Fixes: ee28906f
      
       ("ipv4: Dump route exceptions if requested")
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e93fb3e9
  14. 23 Aug, 2019 1 commit
  15. 22 Aug, 2019 2 commits
  16. 21 Aug, 2019 1 commit
  17. 20 Aug, 2019 3 commits
  18. 19 Aug, 2019 4 commits
    • David Howells's avatar
      keys: Fix description size · 555df336
      David Howells authored
      The maximum key description size is 4095.  Commit f771fde8 ("keys:
      Simplify key description management") inadvertantly reduced that to 255
      and made sizes between 256 and 4095 work weirdly, and any size whereby
      size & 255 == 0 would cause an assertion in __key_link_begin() at the
      following line:
      
      	BUG_ON(index_key->desc_len == 0);
      
      This can be fixed by simply increasing the size of desc_len in struct
      keyring_index_key to a u16.
      
      Note the argument length test in keyutils only checked empty
      descriptions and descriptions with a size around the limit (ie.  4095)
      and not for all the values in between, so it missed this.  This has been
      addressed and
      
      	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/commit/?id=066bf56807c26cd3045a25f355b34c1d8a20a5aa
      
      now exhaustively tests all possible lengths of type, description and
      payload and then some.
      
      The assertion failure looks something like:
      
       kernel BUG at security/keys/keyring.c:1245!
       ...
       RIP: 0010:__key_link_begin+0x88/0xa0
       ...
       Call Trace:
        key_create_or_update+0x211/0x4b0
        __x64_sys_add_key+0x101/0x200
        do_syscall_64+0x5b/0x1e0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It can be triggered by:
      
      	keyctl add user "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" a @s
      
      Fixes: f771fde8
      
       ("keys: Simplify key description management")
      Reported-by: default avatarkernel test robot <rong.a.chen@intel.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      555df336
    • Masahiro Yamada's avatar
      netfilter: add include guard to nf_conntrack_h323_types.h · 38a429c8
      Masahiro Yamada authored
      
      
      Add a header include guard just in case.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      38a429c8
    • Eric W. Biederman's avatar
      signal: Allow cifs and drbd to receive their terminating signals · 33da8e7c
      Eric W. Biederman authored
      
      
      My recent to change to only use force_sig for a synchronous events
      wound up breaking signal reception cifs and drbd.  I had overlooked
      the fact that by default kthreads start out with all signals set to
      SIG_IGN.  So a change I thought was safe turned out to have made it
      impossible for those kernel thread to catch their signals.
      
      Reverting the work on force_sig is a bad idea because what the code
      was doing was very much a misuse of force_sig.  As the way force_sig
      ultimately allowed the signal to happen was to change the signal
      handler to SIG_DFL.  Which after the first signal will allow userspace
      to send signals to these kernel threads.  At least for
      wake_ack_receiver in drbd that does not appear actively wrong.
      
      So correct this problem by adding allow_kernel_signal that will allow
      signals whose siginfo reports they were sent by the kernel through,
      but will not allow userspace generated signals, and update cifs and
      drbd to call allow_kernel_signal in an appropriate place so that their
      thread can receive this signal.
      
      Fixing things this way ensures that userspace won't be able to send
      signals and cause problems, that it is clear which signals the
      threads are expecting to receive, and it guarantees that nothing
      else in the system will be affected.
      
      This change was partly inspired by similar cifs and drbd patches that
      added allow_signal.
      
      Reported-by: default avatarronnie sahlberg <ronniesahlberg@gmail.com>
      Reported-by: default avatarChristoph Böhmwalder <christoph.boehmwalder@linbit.com>
      Tested-by: default avatarChristoph Böhmwalder <christoph.boehmwalder@linbit.com>
      Cc: Steve French <smfrench@gmail.com>
      Cc: Philipp Reisner <philipp.reisner@linbit.com>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Fixes: 247bc947 ("cifs: fix rmmod regression in cifs.ko caused by force_sig changes")
      Fixes: 72abe3bc ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig")
      Fixes: fee10990 ("signal/drbd: Use send_sig not force_sig")
      Fixes: 3cf5d076
      
       ("signal: Remove task parameter from force_sig")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      33da8e7c
    • Juliana Rodrigueiro's avatar
      netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info · 89a26cd4
      Juliana Rodrigueiro authored
      
      
      When running a 64-bit kernel with a 32-bit iptables binary, the size of
      the xt_nfacct_match_info struct diverges.
      
          kernel: sizeof(struct xt_nfacct_match_info) : 40
          iptables: sizeof(struct xt_nfacct_match_info)) : 36
      
      Trying to append nfacct related rules results in an unhelpful message.
      Although it is suggested to look for more information in dmesg, nothing
      can be found there.
      
          # iptables -A <chain> -m nfacct --nfacct-name <acct-object>
          iptables: Invalid argument. Run `dmesg' for more information.
      
      This patch fixes the memory misalignment by enforcing 8-byte alignment
      within the struct's first revision. This solution is often used in many
      other uapi netfilter headers.
      
      Signed-off-by: default avatarJuliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      89a26cd4
  19. 18 Aug, 2019 2 commits
  20. 17 Aug, 2019 1 commit