Skip to content
Snippets Groups Projects
  1. Nov 04, 2019
  2. Oct 04, 2019
  3. Jun 12, 2019
  4. May 31, 2019
  5. Mar 04, 2019
    • Todd Kjos's avatar
      FROMGIT: binder: create node flag to request sender's security context · b2d0d9c6
      Todd Kjos authored
      
      To allow servers to verify client identity, allow a node
      flag to be set that causes the sender's security context
      to be delivered with the transaction. The BR_TRANSACTION
      command is extended in BR_TRANSACTION_SEC_CTX to
      contain a pointer to the security context string.
      
      Signed-off-by: default avatarTodd Kjos <tkjos@google.com>
      Reviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      (cherry picked from commit ec74136d
       https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
      
      
       master)
      Change-Id: I44496546e2d0dc0022f818a45cd52feb1c1a92cb
      Signed-off-by: default avatarTodd Kjos <tkjos@google.com>
      3 tags
      b2d0d9c6
    • Todd Kjos's avatar
      UPSTREAM: binder: fix race that allows malicious free of live buffer · 008067dd
      Todd Kjos authored
      
      commit 7bada55a upstream
      
      Malicious code can attempt to free buffers using the BC_FREE_BUFFER
      ioctl to binder. There are protections against a user freeing a buffer
      while in use by the kernel, however there was a window where
      BC_FREE_BUFFER could be used to free a recently allocated buffer that
      was not completely initialized. This resulted in a use-after-free
      detected by KASAN with a malicious test program.
      
      This window is closed by setting the buffer's allow_user_free attribute
      to 0 when the buffer is allocated or when the user has previously freed
      it instead of waiting for the caller to set it. The problem was that
      when the struct buffer was recycled, allow_user_free was stale and set
      to 1 allowing a free to go through.
      
      Bug: 116855682
      Change-Id: I0b38089f6fdb1adbf7e1102747e4119c9a05b191
      Signed-off-by: default avatarTodd Kjos <tkjos@google.com>
      Acked-by: default avatarArve Hjønnevåg <arve@android.com>
      Cc: stable <stable@vger.kernel.org> # 4.14
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      008067dd
    • Matthias Schwarzott's avatar
      media: em28xx: Fix use-after-free when disconnecting · 1f77a8e1
      Matthias Schwarzott authored
      
      [ Upstream commit 910b0797 ]
      
      Fix bug by moving the i2c_unregister_device calls after deregistration
      of dvb frontend.
      
      The new style i2c drivers already destroys the frontend object at
      i2c_unregister_device time.
      When the dvb frontend is unregistered afterwards it leads to this oops:
      
        [ 6058.866459] BUG: unable to handle kernel NULL pointer dereference at 00000000000001f8
        [ 6058.866578] IP: dvb_frontend_stop+0x30/0xd0 [dvb_core]
        [ 6058.866644] PGD 0
        [ 6058.866646] P4D 0
      
        [ 6058.866726] Oops: 0000 [#1] SMP
        [ 6058.866768] Modules linked in: rc_pinnacle_pctv_hd(O) em28xx_rc(O) si2157(O) si2168(O) em28xx_dvb(O) em28xx(O) si2165(O) a8293(O) tda10071(O) tea5767(O) tuner(O) cx23885(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O) dvb_core(O) rc_core(O) videobuf2_memops(O) videobuf2_v4l2(O) videobuf2_core(O) videodev(O) media(O) bluetooth ecdh_generic ums_realtek uas rtl8192cu rtl_usb rtl8192c_common rtlwifi usb_storage snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic i2c_mux snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core kvm_intel kvm irqbypass [last unloaded: videobuf2_memops]
        [ 6058.867497] CPU: 2 PID: 7349 Comm: kworker/2:0 Tainted: G        W  O    4.13.9-gentoo #1
        [ 6058.867595] Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308 08/25/2014
        [ 6058.867692] Workqueue: usb_hub_wq hub_event
        [ 6058.867746] task: ffff88011a15e040 task.stack: ffffc90003074000
        [ 6058.867825] RIP: 0010:dvb_frontend_stop+0x30/0xd0 [dvb_core]
        [ 6058.867896] RSP: 0018:ffffc90003077b58 EFLAGS: 00010293
        [ 6058.867964] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000010040001f
        [ 6058.868056] RDX: ffff88011a15e040 RSI: ffffea000464e400 RDI: ffff88001cbe3028
        [ 6058.868150] RBP: ffffc90003077b68 R08: ffff880119390380 R09: 000000010040001f
        [ 6058.868241] R10: ffffc90003077b18 R11: 000000000001e200 R12: ffff88001cbe3028
        [ 6058.868330] R13: ffff88001cbe68d0 R14: ffff8800cf734000 R15: ffff8800cf734098
        [ 6058.868419] FS:  0000000000000000(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000
        [ 6058.868511] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [ 6058.868578] CR2: 00000000000001f8 CR3: 00000001113c5000 CR4: 00000000001406e0
        [ 6058.868662] Call Trace:
        [ 6058.868705]  dvb_unregister_frontend+0x2a/0x80 [dvb_core]
        [ 6058.868774]  em28xx_dvb_fini+0x132/0x220 [em28xx_dvb]
        [ 6058.868840]  em28xx_close_extension+0x34/0x90 [em28xx]
        [ 6058.868902]  em28xx_usb_disconnect+0x4e/0x70 [em28xx]
        [ 6058.868968]  usb_unbind_interface+0x6d/0x260
        [ 6058.869025]  device_release_driver_internal+0x150/0x210
        [ 6058.869094]  device_release_driver+0xd/0x10
        [ 6058.869150]  bus_remove_device+0xe4/0x160
        [ 6058.869204]  device_del+0x1ce/0x2f0
        [ 6058.869253]  usb_disable_device+0x99/0x270
        [ 6058.869306]  usb_disconnect+0x8d/0x260
        [ 6058.869359]  hub_event+0x93d/0x1520
        [ 6058.869408]  ? dequeue_task_fair+0xae5/0xd20
        [ 6058.869467]  process_one_work+0x1d9/0x3e0
        [ 6058.869522]  worker_thread+0x43/0x3e0
        [ 6058.869576]  kthread+0x104/0x140
        [ 6058.869602]  ? trace_event_raw_event_workqueue_work+0x80/0x80
        [ 6058.869640]  ? kthread_create_on_node+0x40/0x40
        [ 6058.869673]  ret_from_fork+0x22/0x30
        [ 6058.869698] Code: 54 49 89 fc 53 48 8b 9f 18 03 00 00 0f 1f 44 00 00 41 83 bc 24 04 05 00 00 02 74 0c 41 c7 84 24 04 05 00 00 01 00 00 00 0f ae f0 <48> 8b bb f8 01 00 00 48 85 ff 74 5c e8 df 40 f0 e0 48 8b 93 f8
        [ 6058.869850] RIP: dvb_frontend_stop+0x30/0xd0 [dvb_core] RSP: ffffc90003077b58
        [ 6058.869894] CR2: 00000000000001f8
        [ 6058.875880] ---[ end trace 717eecf7193b3fc6 ]---
      
      Signed-off-by: default avatarMatthias Schwarzott <zzam@gentoo.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f77a8e1
    • Theodore Ts'o's avatar
      jbd2: don't mark block as modified if the handle is out of credits · 5dfa69d6
      Theodore Ts'o authored
      commit e09463f2 upstream.
      
      Do not set the b_modified flag in block's journal head should not
      until after we're sure that jbd2_journal_dirty_metadat() will not
      abort with an error due to there not being enough space reserved in
      the jbd2 handle.
      
      Otherwise, future attempts to modify the buffer may lead a large
      number of spurious errors and warnings.
      
      This addresses CVE-2018-10883.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200071
      
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dfa69d6
    • Theodore Ts'o's avatar
      ext4: avoid running out of journal credits when appending to an inline file · 03f943c5
      Theodore Ts'o authored
      commit 8bc1379b upstream.
      
      Use a separate journal transaction if it turns out that we need to
      convert an inline file to use an data block.  Otherwise we could end
      up failing due to not having journal credits.
      
      This addresses CVE-2018-10883.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=200071
      
      
      
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      [fengc@google.com: 4.4 backport: adjust context]
      Signed-off-by: default avatarChenbo Feng <fengc@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03f943c5
  6. Feb 08, 2019
  7. Feb 01, 2019
  8. Jan 08, 2019
    • Kevin Hilman's avatar
      ARC: change defconfig defaults to ARCv2 · ac95974c
      Kevin Hilman authored
      
      commit b7cc40c3 upstream.
      
      Change the default defconfig (used with 'make defconfig') to the ARCv2
      nsim_hs_defconfig, and also switch the default Kconfig ISA selection to
      ARCv2.
      
      This allows several default defconfigs (e.g. make defconfig, make
      allnoconfig, make tinyconfig) to all work with ARCv2 by default.
      
      Note since we change default architecture from ARCompact to ARCv2
      it's required to explicitly mention architecture type in ARCompact
      defconfigs otherwise ARCv2 will be implied and binaries will be
      generated for ARCv2.
      
      Cc: <stable@vger.kernel.org> # 4.4.x
      Signed-off-by: default avatarKevin Hilman <khilman@baylibre.com>
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac95974c
    • Alexey Brodkin's avatar
      ARC: build: Get rid of toolchain check · 11b3bc4c
      Alexey Brodkin authored
      
      commit 615f6445 upstream.
      
      This check is very naive: we simply test if GCC invoked without
      "-mcpu=XXX" has ARC700 define set. In that case we think that GCC
      was built with "--with-cpu=arc700" and has libgcc built for ARC700.
      
      Otherwise if ARC700 is not defined we think that everythng was built
      for ARCv2.
      
      But in reality our life is much more interesting.
      
      1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
         it may generate code for any ARC core).
      
      2. libgcc might be built with explicitly specified "--mcpu=YYY"
      
      That's exactly what happens in case of multilibbed toolchains:
       - GCC is configured with default settings
       - All the libs built for many different CPU flavors
      
      I.e. that check gets in the way of usage of multilibbed
      toolchains. And even non-multilibbed toolchains are affected.
      OpenEmbedded also builds GCC without "--with-cpu" because
      each and every target component later is compiled with explicitly
      set "-mcpu=ZZZ".
      
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11b3bc4c
    • Alexey Brodkin's avatar
      ARC: Explicitly add -mmedium-calls to CFLAGS · 36f33e5a
      Alexey Brodkin authored
      
      [ Upstream commit 74c11e30 ]
      
      GCC built for arc*-*-linux has "-mmedium-calls" implicitly enabled by default
      thus we don't see any problems during Linux kernel compilation.
      ----------------------------->8------------------------
      arc-linux-gcc -mcpu=arc700 -Q --help=target | grep calls
        -mlong-calls                          [disabled]
        -mmedium-calls                        [enabled]
      ----------------------------->8------------------------
      
      But if we try to use so-called Elf32 toolchain with GCC configured for
      arc*-*-elf* then we'd see the following failure:
      ----------------------------->8------------------------
      init/do_mounts.o: In function 'init_rootfs':
      do_mounts.c:(.init.text+0x108): relocation truncated to fit: R_ARC_S21W_PCREL
      against symbol 'unregister_filesystem' defined in .text section in fs/filesystems.o
      
      arc-elf32-ld: final link failed: Symbol needs debug section which does not exist
      make: *** [vmlinux] Error 1
      ----------------------------->8------------------------
      
      That happens because neither "-mmedium-calls" nor "-mlong-calls" are enabled in
      Elf32 GCC:
      ----------------------------->8------------------------
      arc-elf32-gcc -mcpu=arc700 -Q --help=target | grep calls
        -mlong-calls                          [disabled]
        -mmedium-calls                        [disabled]
      ----------------------------->8------------------------
      
      Now to make it possible to use Elf32 toolchain for building Linux kernel
      we're explicitly add "-mmedium-calls" to CFLAGS.
      
      And since we add "-mmedium-calls" to the global CFLAGS there's no point in
      having per-file copies thus removing them.
      
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36f33e5a
  9. Jan 04, 2019
  10. Dec 10, 2018
    • Arnd Bergmann's avatar
      irda: fix overly long udelay() · 9f7d53dc
      Arnd Bergmann authored
      
      commit c9bd2823 upstream.
      
      irda_get_mtt() returns a hardcoded '10000' in some cases,
      and with gcc-7, we get a build error because this triggers a
      compile-time check in udelay():
      
      drivers/net/irda/w83977af_ir.o: In function `w83977af_hard_xmit':
      w83977af_ir.c:(.text.w83977af_hard_xmit+0x14c): undefined reference to `__bad_udelay'
      
      Older compilers did not run into this because they either did not
      completely inline the irda_get_mtt() or did not consider the
      10000 value a constant expression.
      
      The code has been wrong since the start of git history.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f7d53dc
  11. Dec 07, 2018
    • H.J. Lu's avatar
      x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 · f58d84a2
      H.J. Lu authored
      
      commit b21ebf2f upstream.
      
      On i386, there are 2 types of PLTs, PIC and non-PIC.  PIE and shared
      objects must use PIC PLT.  To use PIC PLT, you need to load
      _GLOBAL_OFFSET_TABLE_ into EBX first.  There is no need for that on
      x86-64 since x86-64 uses PC-relative PLT.
      
      On x86-64, for 32-bit PC-relative branches, we can generate PLT32
      relocation, instead of PC32 relocation, which can also be used as
      a marker for 32-bit PC-relative branches.  Linker can always reduce
      PLT32 relocation to PC32 if function is defined locally.   Local
      functions should use PC32 relocation.  As far as Linux kernel is
      concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32
      since Linux kernel doesn't use PLT.
      
      R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in
      binutils master branch which will become binutils 2.31.
      
      [ hjl is working on having better documentation on this all, but a few
        more notes from him:
      
         "PLT32 relocation is used as marker for PC-relative branches. Because
          of EBX, it looks odd to generate PLT32 relocation on i386 when EBX
          doesn't have GOT.
      
          As for symbol resolution, PLT32 and PC32 relocations are almost
          interchangeable. But when linker sees PLT32 relocation against a
          protected symbol, it can resolved locally at link-time since it is
          used on a branch instruction. Linker can't do that for PC32
          relocation"
      
        but for the kernel use, the two are basically the same, and this
        commit gets things building and working with the current binutils
        master   - Linus ]
      
      Change-Id: Ie7b893d04d6f9492350e65d82e499db1979d3b4b
      Signed-off-by: default avatarH.J. Lu <hjl.tools@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f58d84a2
  12. Dec 04, 2018
    • Christoph Paasch's avatar
      net: Set sk_prot_creator when cloning sockets to the right proto · 4af28d38
      Christoph Paasch authored
      
      
      [ Upstream commit 9d538fa6 ]
      
      sk->sk_prot and sk->sk_prot_creator can differ when the app uses
      IPV6_ADDRFORM (transforming an IPv6-socket to an IPv4-one).
      Which is why sk_prot_creator is there to make sure that sk_prot_free()
      does the kmem_cache_free() on the right kmem_cache slab.
      
      Now, if such a socket gets transformed back to a listening socket (using
      connect() with AF_UNSPEC) we will allocate an IPv4 tcp_sock through
      sk_clone_lock() when a new connection comes in. But sk_prot_creator will
      still point to the IPv6 kmem_cache (as everything got copied in
      sk_clone_lock()). When freeing, we will thus put this
      memory back into the IPv6 kmem_cache although it was allocated in the
      IPv4 cache. I have seen memory corruption happening because of this.
      
      With slub-debugging and MEMCG_KMEM enabled this gives the warning
      	"cache_from_obj: Wrong slab cache. TCPv6 but object is from TCP"
      
      A C-program to trigger this:
      
      void main(void)
      {
              int fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
              int new_fd, newest_fd, client_fd;
              struct sockaddr_in6 bind_addr;
              struct sockaddr_in bind_addr4, client_addr1, client_addr2;
              struct sockaddr unsp;
              int val;
      
              memset(&bind_addr, 0, sizeof(bind_addr));
              bind_addr.sin6_family = AF_INET6;
              bind_addr.sin6_port = ntohs(42424);
      
              memset(&client_addr1, 0, sizeof(client_addr1));
              client_addr1.sin_family = AF_INET;
              client_addr1.sin_port = ntohs(42424);
              client_addr1.sin_addr.s_addr = inet_addr("127.0.0.1");
      
              memset(&client_addr2, 0, sizeof(client_addr2));
              client_addr2.sin_family = AF_INET;
              client_addr2.sin_port = ntohs(42421);
              client_addr2.sin_addr.s_addr = inet_addr("127.0.0.1");
      
              memset(&unsp, 0, sizeof(unsp));
              unsp.sa_family = AF_UNSPEC;
      
              bind(fd, (struct sockaddr *)&bind_addr, sizeof(bind_addr));
      
              listen(fd, 5);
      
              client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
              connect(client_fd, (struct sockaddr *)&client_addr1, sizeof(client_addr1));
              new_fd = accept(fd, NULL, NULL);
              close(fd);
      
              val = AF_INET;
              setsockopt(new_fd, SOL_IPV6, IPV6_ADDRFORM, &val, sizeof(val));
      
              connect(new_fd, &unsp, sizeof(unsp));
      
              memset(&bind_addr4, 0, sizeof(bind_addr4));
              bind_addr4.sin_family = AF_INET;
              bind_addr4.sin_port = ntohs(42421);
              bind(new_fd, (struct sockaddr *)&bind_addr4, sizeof(bind_addr4));
      
              listen(new_fd, 5);
      
              client_fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
              connect(client_fd, (struct sockaddr *)&client_addr2, sizeof(client_addr2));
      
              newest_fd = accept(new_fd, NULL, NULL);
              close(new_fd);
      
              close(client_fd);
              close(new_fd);
      }
      
      As far as I can see, this bug has been there since the beginning of the
      git-days.
      
      Signed-off-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. Nov 02, 2018
  14. Oct 04, 2018
  15. Aug 30, 2018
Loading