Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
0 authors
  1. Oct 29, 2020
  3. Oct 27, 2020
  5. Oct 26, 2020
  7. Oct 19, 2020
  9. Oct 16, 2020
    • Jiri Olsa's avatar
      perf/core: Fix race in the perf_mmap_close() function · 9fcf6ece
      Jiri Olsa authored 
      mainline inclusion
from mainline-v5.10
commit f91072ed
category: bugfix
bugzilla: NA
CVE: CVE-2020-14351

--------------------------------

There's a possible race in perf_mmap_close() when checking ring buffer's
mmap_count refcount value. The problem is that the mmap_count check is
not atomic because we call atomic_dec() and atomic_read() separately.

  perf_mmap_close:
  ...
   atomic_dec(&rb->mmap_count);
   ...
   if (atomic_read(&rb->mmap_count))
      goto out_put;

   <ring buffer detach>
   free_uid

out_put:
  ring_buffer_put(rb); /* could be last */

The race can happen when we have two (or more) events sharing same ring
buffer and they go through atomic_dec() and then they both see 0 as refcount
value later in atomic_read(). Then both will go on and execute code which
is meant to be run just once.

The code that detaches ring buffer is probably fine to be executed more
than once, but the problem is in calling ...
      9fcf6ece
    • Mark Gray's avatar
      geneve: add transport ports in route lookup for geneve · fe5ff185
      Mark Gray authored 
      
stable inclusion
from linux-4.19.148
commit c797110d97c48054d1491251fd713900ff51615c
CVE: CVE-2020-25645

--------------------------------

[ Upstream commit 34beb215 ]

This patch adds transport ports information for route lookup so that
IPsec can select Geneve tunnel traffic to do encryption. This is
needed for OVS/OVN IPsec with encrypted Geneve tunnels.

This can be tested by configuring a host-host VPN using an IKE
daemon and specifying port numbers. For example, for an
Openswan-type configuration, the following parameters should be
configured on both hosts and IPsec set up as-per normal:

$ cat /etc/ipsec.conf

conn in
...
left=$IP1
right=$IP2
...
leftprotoport=udp/6081
rightprotoport=udp
...
conn out
...
left=$IP1
right=$IP2
...
leftprotoport=udp
rightprotoport=udp/6081
...

The tunnel can then be setup using "ip" on both hosts (but
changing the relevant IP addresses):

$ ip link add tun type geneve id 1000 remote $IP2
$ ip addr add 192.168.0.1/24 dev tun
$ ip link set tun up

This can then be tested by pinging from $IP1:

$ ping 192.168.0.2

Without this patch the traffic is unencrypted on the wire.

Fixes: 2d07dc79 ("geneve: add initial netdev driver for GENEVE tunnels")
Signed-off-by: default avatarQiuyu Xiao <qiuyu.xiao.qyx@gmail.com>
Signed-off-by: default avatarMark Gray <mark.d.gray@redhat.com>
Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: default avatarJason Yan <yanaijie@huawei.com>
Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      fe5ff185
  11. Oct 15, 2020
    • Luo Meng's avatar
      ext4: only set last error block when check system zone failed · 49b0e114
      Luo Meng authored 
      hulk inclusion
category: bugfix
bugzilla: 39268
CVE: NA

-------------------------------------------------

Since the code of commit c03b42efb1c4 ("ext4: Fold ext4_data_block_valid_rcu()
into the caller") when check valid the inode blocks, we set the last error
block before final determination the block is invalid, which confuses with
linux master.

The block should be invalid only when the block is belong to the system zone.
The system zone was initialized when mount, and the entry->ino just should be
0 or journal_ino, and it never changed in his lifetime. Only when check the
inode with ino=0/journal_ino will cause set the wrong last error block.
But the ino=0/journal_ino never call ext4_inode_block_valid, so it never case
any problem.

In order to keep the same logic with linux master and dispel the confuse,
add explicit judgment for invalid block before set the last error block.

Fixes: c03b42efb1c4 ("ext4: Fold ext4_data_block_valid_rcu() i...
      49b0e114
    • Max Reitz's avatar
      xfs: Fix tail rounding in xfs_alloc_file_space() · f2eef525
      Max Reitz authored 
      
mainline inclusion
from mainline-v5.4-rc3
commit e093c4be
category: bugfix
bugzilla: NA
CVE: NA

---------------------------

To ensure that all blocks touched by the range [offset, offset + count)
are allocated, we need to calculate the block count from the difference
of the range end (rounded up) and the range start (rounded down).

Before this patch, we just round up the byte count, which may lead to
unaligned ranges not being fully allocated:

$ touch test_file
$ block_size=$(stat -fc '%S' test_file)
$ fallocate -o $((block_size / 2)) -l $block_size test_file
$ xfs_bmap test_file
test_file:
        0: [0..7]: 1396264..1396271
        1: [8..15]: hole

There should not be a hole there.  Instead, the first two blocks should
be fully allocated.

With this patch applied, the result is something like this:

$ touch test_file
$ block_size=$(stat -fc '%S' test_file)
$ fallocate -o $((block_size / 2)) -l $block_size test_file
$ xfs_bmap test_file
test_file:
        0: [0..15]: 11024..11039

Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
Reviewed-by: default avatarCarlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: default avatarzhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      f2eef525
    • Yang Xu's avatar
      KEYS: reaching the keys quotas correctly · ac2dca59
      Yang Xu authored 
      stable inclusion
from linux-4.19.116
commit 14b96359440421c4d84033933a2a5de73de1510d

--------------------------------

commit 2e356101 upstream.

Currently, when we add a new user key, the calltrace as below:

add_key()
  key_create_or_update()
    key_alloc()
    __key_instantiate_and_link
      generic_key_instantiate
        key_payload_reserve
          ......

Since commit a08bf91c ("KEYS: allow reaching the keys quotas exactly"),
we can reach max bytes/keys in key_alloc, but we forget to remove this
limit when we reserver space for payload in key_payload_reserve. So we
can only reach max keys but not max bytes when having delta between plen
and type->def_datalen. Remove this limit when instantiating the key, so we
can keep consistent with key_alloc.

Also, fix the similar problem in keyctl_chown_key().

Fixes: 0b77f5bf ("keys: make the keyring quotas controllable through /proc/sys")
Fixes: a08bf91c ("KEYS: allow re...
      ac2dca59
    • Lukas Wunner's avatar
      serial: 8250: Avoid error message on reprobe · 311f10fa
      Lukas Wunner authored 
      stable inclusion
from linux-4.19.148
commit 8b4846ac1af4b0c99817aee7304e9f5dd6ffcb56

--------------------------------

commit e0a851fe upstream.

If the call to uart_add_one_port() in serial8250_register_8250_port()
fails, a half-initialized entry in the serial_8250ports[] array is left
behind.

A subsequent reprobe of the same serial port causes that entry to be
reused.  Because uart->port.dev is set, uart_remove_one_port() is called
for the half-initialized entry and bails out with an error message:

bcm2835-aux-uart 3f215040.serial: Removing wrong port: (null) != (ptrval)

The same happens on failure of mctrl_gpio_init() since commit
4a96895f ("tty/serial/8250: use mctrl_gpio helpers").

Fix by zeroing the uart->port.dev pointer in the probe error path.

The bug was introduced in v2.6.10 by historical commit befff6f5bf5f
("[SERIAL] Add new port registration/unregistration functions."):
https://git.kernel.org/tglx/history/c/befff6f5bf5f



The commit added an unconditional call to uart_remove_one_port() in
serial8250_register_port().  In v3.7, commit 835d844d ("8250_pnp:
do pnp probe before legacy probe") made that call conditional on
uart->port.dev which allows me to fix the issue by zeroing that pointer
in the error path.  Thus, the present commit will fix the problem as far
back as v3.7 whereas still older versions need to also cherry-pick
835d844d.

Fixes: 835d844d ("8250_pnp: do pnp probe before legacy probe")
Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v2.6.10
Cc: stable@vger.kernel.org # v2.6.10: 835d844d: 8250_pnp: do pnp probe before legacy
Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/b4a072013ee1a1d13ee06b4325afb19bda57ca1b.1589285873.git.lukas@wunner.de


[iwamatsu: Backported to 4.14, 4.19: adjust context]
Signed-off-by: default avatarNobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      311f10fa