1. 25 11月, 2020 4 次提交
  2. 18 11月, 2020 1 次提交
  3. 09 11月, 2020 1 次提交
    • D
      vt: Disable KD_FONT_OP_COPY · 3c4e0dff
      Daniel Vetter 提交于
      It's buggy:
      
      On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote:
      > We recently discovered a slab-out-of-bounds read in fbcon in the latest
      > kernel ( v5.10-rc2 for now ).  The root cause of this vulnerability is that
      > "fbcon_do_set_font" did not handle "vc->vc_font.data" and
      > "vc->vc_font.height" correctly, and the patch
      > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this
      > issue.
      >
      > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and
      > use  KD_FONT_OP_SET again to set a large font.height for tty1. After that,
      > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data
      > in "fbcon_do_set_font", while tty1 retains the original larger
      > height. Obviously, this will cause an out-of-bounds read, because we can
      > access a smaller vc_font.data with a larger vc_font.height.
      
      Further there was only one user ever.
      - Android's loadfont, busybox and console-tools only ever use OP_GET
        and OP_SET
      - fbset documentation only mentions the kernel cmdline font: option,
        not anything else.
      - systemd used OP_COPY before release 232 published in Nov 2016
      
      Now unfortunately the crucial report seems to have gone down with
      gmane, and the commit message doesn't say much. But the pull request
      hints at OP_COPY being broken
      
      https://github.com/systemd/systemd/pull/3651
      
      So in other words, this never worked, and the only project which
      foolishly every tried to use it, realized that rather quickly too.
      
      Instead of trying to fix security issues here on dead code by adding
      missing checks, fix the entire thing by removing the functionality.
      
      Note that systemd code using the OP_COPY function ignored the return
      value, so it doesn't matter what we're doing here really - just in
      case a lone server somewhere happens to be extremely unlucky and
      running an affected old version of systemd. The relevant code from
      font_copy_to_all_vcs() in systemd was:
      
      	/* copy font from active VT, where the font was uploaded to */
      	cfo.op = KD_FONT_OP_COPY;
      	cfo.height = vcs.v_active-1; /* tty1 == index 0 */
      	(void) ioctl(vcfd, KDFONTOP, &cfo);
      
      Note this just disables the ioctl, garbage collecting the now unused
      callbacks is left for -next.
      
      v2: Tetsuo found the old mail, which allowed me to find it on another
      archive. Add the link too.
      Acked-by: NPeilin Ye <yepeilin.cs@gmail.com>
      Reported-by: NMinh Yuan <yuanmingbuaa@gmail.com>
      References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html
      References: https://github.com/systemd/systemd/pull/3651
      Cc: Greg KH <greg@kroah.com>
      Cc: Peilin Ye <yepeilin.cs@gmail.com>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://lore.kernel.org/r/20201108153806.3140315-1-daniel.vetter@ffwll.chSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c4e0dff
  4. 07 11月, 2020 7 次提交
    • D
      null_blk: Fix scheduling in atomic with zoned mode · e1777d09
      Damien Le Moal 提交于
      Commit aa1c09cb ("null_blk: Fix locking in zoned mode") changed
      zone locking to using the potentially sleeping wait_on_bit_io()
      function. This is acceptable when memory backing is enabled as the
      device queue is in that case marked as blocking, but this triggers a
      scheduling while in atomic context with memory backing disabled.
      
      Fix this by relying solely on the device zone spinlock for zone
      information protection without temporarily releasing this lock around
      null_process_cmd() execution in null_zone_write(). This is OK to do
      since when memory backing is disabled, command processing does not
      block and the memory backing lock nullb->lock is unused. This solution
      avoids the overhead of having to mark a zoned null_blk device queue as
      blocking when memory backing is unused.
      
      This patch also adds comments to the zone locking code to explain the
      unusual locking scheme.
      
      Fixes: aa1c09cb ("null_blk: Fix locking in zoned mode")
      Reported-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      e1777d09
    • M
      tty: fix crash in release_tty if tty->port is not set · 4466d6d2
      Matthias Reichl 提交于
      Commit 2ae0b31e ("tty: don't crash in tty_init_dev when missing
      tty_port") didn't fully prevent the crash as the cleanup path in
      tty_init_dev() calls release_tty() which dereferences tty->port
      without checking it for non-null.
      
      Add tty->port checks to release_tty to avoid the kernel crash.
      
      Fixes: 2ae0b31e ("tty: don't crash in tty_init_dev when missing tty_port")
      Signed-off-by: NMatthias Reichl <hias@horus.com>
      Link: https://lore.kernel.org/r/20201105123432.4448-1-hias@horus.com
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4466d6d2
    • Q
      serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init · 0c5fc926
      Qinglang Miao 提交于
      Add the missing platform_driver_unregister() before return
      from serial_txx9_init in the error handling case when failed
      to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI
      defined.
      
      Fixes: ab4382d2 ("tty: move drivers/serial/ to drivers/tty/serial/")
      Signed-off-by: NQinglang Miao <miaoqinglang@huawei.com>
      Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c5fc926
    • L
      tty: serial: imx: enable earlycon by default if IMX_SERIAL_CONSOLE is enabled · 427627a2
      Lucas Stach 提交于
      Since 699cc4df (tty: serial: imx: add imx earlycon driver), the earlycon
      part of imx serial is a separate driver and isn't necessarily enabled anymore
      when the console is enabled. This causes users to loose the earlycon
      functionality when upgrading their kenrel configuration via oldconfig.
      
      Enable earlycon by default when IMX_SERIAL_CONSOLE is enabled.
      
      Fixes: 699cc4df (tty: serial: imx: add imx earlycon driver)
      Reviewed-by: NFabio Estevam <festevam@gmail.com>
      Reviewed-by: NFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Link: https://lore.kernel.org/r/20201105204026.1818219-1-l.stach@pengutronix.de
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      427627a2
    • C
      serial: 8250_mtk: Fix uart_get_baud_rate warning · 912ab37c
      Claire Chang 提交于
      Mediatek 8250 port supports speed higher than uartclk / 16. If the baud
      rates in both the new and the old termios setting are higher than
      uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered.
      Passing NULL as the old termios so uart_get_baud_rate() will use
      uartclk / 16 - 1 as the new baud rate which will be replaced by the
      original baud rate later by tty_termios_encode_baud_rate() in
      mtk8250_set_termios().
      
      Fixes: 551e553f ("serial: 8250_mtk: Fix high-speed baud rates clamping")
      Signed-off-by: NClaire Chang <tientzu@chromium.org>
      Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      912ab37c
    • T
      tpm: efi: Don't create binary_bios_measurements file for an empty log · 8ffd778a
      Tyler Hicks 提交于
      Mimic the pre-existing ACPI and Device Tree event log behavior by not
      creating the binary_bios_measurements file when the EFI TPM event log is
      empty.
      
      This fixes the following NULL pointer dereference that can occur when
      reading /sys/kernel/security/tpm0/binary_bios_measurements after the
      kernel received an empty event log from the firmware:
      
       BUG: kernel NULL pointer dereference, address: 000000000000002c
       #PF: supervisor read access in kernel mode
       #PF: error_code(0x0000) - not-present page
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 2 PID: 3932 Comm: fwupdtpmevlog Not tainted 5.9.0-00003-g629990edad62 #17
       Hardware name: LENOVO 20LCS03L00/20LCS03L00, BIOS N27ET38W (1.24 ) 11/28/2019
       RIP: 0010:tpm2_bios_measurements_start+0x3a/0x550
       Code: 54 53 48 83 ec 68 48 8b 57 70 48 8b 1e 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 48 8b 82 c0 06 00 00 48 8b 8a c8 06 00 00 <44> 8b 60 1c 48 89 4d a0 4c 89 e2 49 83 c4 20 48 83 fb 00 75 2a 49
       RSP: 0018:ffffa9c901203db0 EFLAGS: 00010246
       RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000010
       RDX: ffff8ba1eb99c000 RSI: ffff8ba1e4ce8280 RDI: ffff8ba1e4ce8258
       RBP: ffffa9c901203e40 R08: ffffa9c901203dd8 R09: ffff8ba1ec443300
       R10: ffffa9c901203e50 R11: 0000000000000000 R12: ffff8ba1e4ce8280
       R13: ffffa9c901203ef0 R14: ffffa9c901203ef0 R15: ffff8ba1e4ce8258
       FS:  00007f6595460880(0000) GS:ffff8ba1ef880000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 000000000000002c CR3: 00000007d8d18003 CR4: 00000000003706e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        ? __kmalloc_node+0x113/0x320
        ? kvmalloc_node+0x31/0x80
        seq_read+0x94/0x420
        vfs_read+0xa7/0x190
        ksys_read+0xa7/0xe0
        __x64_sys_read+0x1a/0x20
        do_syscall_64+0x37/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      In this situation, the bios_event_log pointer in the tpm_bios_log struct
      was not NULL but was equal to the ZERO_SIZE_PTR (0x10) value. This was
      due to the following kmemdup() in tpm_read_log_efi():
      
      int tpm_read_log_efi(struct tpm_chip *chip)
      {
      ...
      	/* malloc EventLog space */
      	log->bios_event_log = kmemdup(log_tbl->log, log_size, GFP_KERNEL);
      	if (!log->bios_event_log) {
      		ret = -ENOMEM;
      		goto out;
      	}
      ...
      }
      
      When log_size is zero, due to an empty event log from firmware,
      ZERO_SIZE_PTR is returned from kmemdup(). Upon a read of the
      binary_bios_measurements file, the tpm2_bios_measurements_start()
      function does not perform a ZERO_OR_NULL_PTR() check on the
      bios_event_log pointer before dereferencing it.
      
      Rather than add a ZERO_OR_NULL_PTR() check in functions that make use of
      the bios_event_log pointer, simply avoid creating the
      binary_bios_measurements_file as is done in other event log retrieval
      backends.
      
      Explicitly ignore all of the events in the final event log when the main
      event log is empty. The list of events in the final event log cannot be
      accurately parsed without referring to the first event in the main event
      log (the event log header) so the final event log is useless in such a
      situation.
      
      Fixes: 58cc1e4f ("tpm: parse TPM event logs based on EFI table")
      Link: https://lore.kernel.org/linux-integrity/E1FDCCCB-CA51-4AEE-AC83-9CDE995EAE52@canonical.com/Reported-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Reported-by: NKenneth R. Crudup <kenny@panix.com>
      Reported-by: NMimi Zohar <zohar@linux.ibm.com>
      Cc: Thiébaud Weksteen <tweek@google.com>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com>
      Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org>
      8ffd778a
    • J
      tpm_tis: Disable interrupts on ThinkPad T490s · b154ce11
      Jerry Snitselaar 提交于
      There is a misconfiguration in the bios of the gpio pin used for the
      interrupt in the T490s. When interrupts are enabled in the tpm_tis
      driver code this results in an interrupt storm. This was initially
      reported when we attempted to enable the interrupt code in the tpm_tis
      driver, which previously wasn't setting a flag to enable it. Due to
      the reports of the interrupt storm that code was reverted and we went back
      to polling instead of using interrupts. Now that we know the T490s problem
      is a firmware issue, add code to check if the system is a T490s and
      disable interrupts if that is the case. This will allow us to enable
      interrupts for everyone else. If the user has a fixed bios they can
      force the enabling of interrupts with tpm_tis.interrupts=1 on the
      kernel command line.
      
      Cc: Peter Huewe <peterhuewe@gmx.de>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: NJerry Snitselaar <jsnitsel@redhat.com>
      Reviewed-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Reviewed-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NJarkko Sakkinen <jarkko@kernel.org>
      Signed-off-by: NJarkko Sakkinen <jarkko@kernel.org>
      b154ce11
  5. 06 11月, 2020 13 次提交
  6. 05 11月, 2020 6 次提交
  7. 04 11月, 2020 8 次提交