- 06 Feb, 2019 6 commits
-
-
Stefano Brivio authored
BugLink: https://bugs.launchpad.net/bugs/1811080 [ Upstream commit 66033f47 ] Even if we send an IPv6 packet without options, MAX_HEADER might not be enough to account for the additional headroom required by alignment of hardware headers. On a configuration without HYPERV_NET, WLAN, AX25, and with IPV6_TUNNEL, sending short SCTP packets over IPv4 over L2TP over IPv6, we start with 100 bytes of allocated headroom in sctp_packet_transmit(), end up with 54 bytes after l2tp_xmit_skb(), and 14 bytes in ip6_finish_output2(). Those would be enough to append our 14 bytes header, but we're going to align that to 16 bytes, and write 2 bytes out of the allocated slab in neigh_hh_output(). KASan says: [ 264.967848] ================================================================== [ 264.967861] BUG: KASAN: slab-out-of-bounds in ip6_finish_output2+0x1aec/0x1c70 [ 264.967866] Write of size 16 at addr 000000006af1c7fe by task netperf/6201 [ 264.967870] [ 264.967876] CPU: 0 PID: 6201 Comm: netperf Not tainted 4.20.0-rc4+ #1 [ 264.967881] Hardware name: IBM 2827 H43 400 (z/VM 6.4.0) [ 264.967887] Call Trace: [ 264.967896] ([<00000000001347d6>] show_stack+0x56/0xa0) [ 264.967903] [<00000000017e379c>] dump_stack+0x23c/0x290 [ 264.967912] [<00000000007bc594>] print_address_description+0xf4/0x290 [ 264.967919] [<00000000007bc8fc>] kasan_report+0x13c/0x240 [ 264.967927] [<000000000162f5e4>] ip6_finish_output2+0x1aec/0x1c70 [ 264.967935] [<000000000163f890>] ip6_finish_output+0x430/0x7f0 [ 264.967943] [<000000000163fe44>] ip6_output+0x1f4/0x580 [ 264.967953] [<000000000163882a>] ip6_xmit+0xfea/0x1ce8 [ 264.967963] [<00000000017396e2>] inet6_csk_xmit+0x282/0x3f8 [ 264.968033] [<000003ff805fb0ba>] l2tp_xmit_skb+0xe02/0x13e0 [l2tp_core] [ 264.968037] [<000003ff80631192>] l2tp_eth_dev_xmit+0xda/0x150 [l2tp_eth] [ 264.968041] [<0000000001220020>] dev_hard_start_xmit+0x268/0x928 [ 264.968069] [<0000000001330e8e>] sch_direct_xmit+0x7ae/0x1350 [ 264.968071] [<000000000122359c>] __dev_queue_xmit+0x2b7c/0x3478 [ 264.968075] [<00000000013d2862>] ip_finish_output2+0xce2/0x11a0 [ 264.968078] [<00000000013d9b14>] ip_finish_output+0x56c/0x8c8 [ 264.968081] [<00000000013ddd1e>] ip_output+0x226/0x4c0 [ 264.968083] [<00000000013dbd6c>] __ip_queue_xmit+0x894/0x1938 [ 264.968100] [<000003ff80bc3a5c>] sctp_packet_transmit+0x29d4/0x3648 [sctp] [ 264.968116] [<000003ff80b7bf68>] sctp_outq_flush_ctrl.constprop.5+0x8d0/0xe50 [sctp] [ 264.968131] [<000003ff80b7c716>] sctp_outq_flush+0x22e/0x7d8 [sctp] [ 264.968146] [<000003ff80b35c68>] sctp_cmd_interpreter.isra.16+0x530/0x6800 [sctp] [ 264.968161] [<000003ff80b3410a>] sctp_do_sm+0x222/0x648 [sctp] [ 264.968177] [<000003ff80bbddac>] sctp_primitive_ASSOCIATE+0xbc/0xf8 [sctp] [ 264.968192] [<000003ff80b93328>] __sctp_connect+0x830/0xc20 [sctp] [ 264.968208] [<000003ff80bb11ce>] sctp_inet_connect+0x2e6/0x378 [sctp] [ 264.968212] [<0000000001197942>] __sys_connect+0x21a/0x450 [ 264.968215] [<000000000119aff8>] sys_socketcall+0x3d0/0xb08 [ 264.968218] [<000000000184ea7a>] system_call+0x2a2/0x2c0 [...] Just like ip_finish_output2() does for IPv4, check that we have enough headroom in ip6_xmit(), and reallocate it if we don't. This issue is older than git history. Reported-by:
Jianlin Shi <jishi@redhat.com> Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Daniel Axtens authored
BugLink: https://bugs.launchpad.net/bugs/1793901 Some users see panics like the following when performing fstrim on a bcached volume: [ 529.803060] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 530.183928] #PF error: [normal kernel read fault] [ 530.412392] PGD 8000001f42163067 P4D 8000001f42163067 PUD 1f42168067 PMD 0 [ 530.750887] Oops: 0000 [#1] SMP PTI [ 530.920869] CPU: 10 PID: 4167 Comm: fstrim Kdump: loaded Not tainted 5.0.0-rc1+ #3 [ 531.290204] Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 12/27/2015 [ 531.693137] RIP: 0010:blk_queue_split+0x148/0x620 [ 531.922205] Code: 60 38 89 55 a0 45 31 db 45 31 f6 45 31 c9 31 ff 89 4d 98 85 db 0f 84 7f 04 00 00 44 8b 6d 98 4c 89 ee 48 c1 e6 04 49 03 70 78 <8b> 46 08 44 8b 56 0c 48 8b 16 44 29 e0 39 d8 48 89 55 a8 0f 47 c3 [ 532.838634] RSP: 0018:ffffb9b708df39b0 EFLAGS: 00010246 [ 533.093571] RAX: 00000000ffffffff RBX: 0000000000046000 RCX: 0000000000000000 [ 533.441865] RDX: 0000000000000200 RSI: 0000000000000000 RDI: 0000000000000000 [ 533.789922] RBP: ffffb9b708df3a48 R08: ffff940d3b3fdd20 R09: 0000000000000000 [ 534.137512] R10: ffffb9b708df3958 R11: 0000000000000000 R12: 0000000000000000 [ 534.485329] R13: 0000000000000000 R14: 0000000000000000 R15: ffff940d39212020 [ 534.833319] FS: 00007efec26e3840(0000) GS:ffff940d1f480000(0000) knlGS:0000000000000000 [ 535.224098] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 535.504318] CR2: 0000000000000008 CR3: 0000001f4e256004 CR4: 00000000001606e0 [ 535.851759] Call Trace: [ 535.970308] ? mempool_alloc_slab+0x15/0x20 [ 536.174152] ? bch_data_insert+0x42/0xd0 [bcache] [ 536.403399] blk_mq_make_request+0x97/0x4f0 [ 536.607036] generic_make_request+0x1e2/0x410 [ 536.819164] submit_bio+0x73/0x150 [ 536.980168] ? submit_bio+0x73/0x150 [ 537.149731] ? bio_associate_blkg_from_css+0x3b/0x60 [ 537.391595] ? _cond_resched+0x1a/0x50 [ 537.573774] submit_bio_wait+0x59/0x90 [ 537.756105] blkdev_issue_discard+0x80/0xd0 [ 537.959590] ext4_trim_fs+0x4a9/0x9e0 [ 538.137636] ? ext4_trim_fs+0x4a9/0x9e0 [ 538.324087] ext4_ioctl+0xea4/0x1530 [ 538.497712] ? _copy_to_user+0x2a/0x40 [ 538.679632] do_vfs_ioctl+0xa6/0x600 [ 538.853127] ? __do_sys_newfstat+0x44/0x70 [ 539.051951] ksys_ioctl+0x6d/0x80 [ 539.212785] __x64_sys_ioctl+0x1a/0x20 [ 539.394918] do_syscall_64+0x5a/0x110 [ 539.568674] entry_SYSCALL_64_after_hwframe+0x44/0xa9 We have observed it where both: 1) LVM/devmapper is involved (bcache backing device is LVM volume) and 2) writeback cache is involved (bcache cache_mode is writeback) On one machine, we can reliably reproduce it with: # echo writeback > /sys/block/bcache0/bcache/cache_mode # not sure if this is required # mount /dev/bcache0 /test # for i in {0..10}; do file="$(mktemp /test/zero.XXX)"; dd if=/dev/zero of="$file" bs=1M count=256; sync; rm $file; done; fstrim -v /test Observing this with tracepoints on, we see the following writes: fstrim-18019 [022] .... 91107.302026: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4260112 + 196352 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302050: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4456464 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302075: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 4718608 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302094: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5324816 + 180224 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302121: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5505040 + 262144 hit 0 bypass 1 fstrim-18019 [022] .... 91107.302145: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 5767184 + 81920 hit 0 bypass 1 fstrim-18019 [022] .... 91107.308777: bcache_write: 73f95583-561c-408f-a93a-4cbd2498f5c8 inode 0 DS 6373392 + 180224 hit 1 bypass 0 <crash> Note the final one has different hit/bypass flags. This is because in should_writeback(), we were hitting a case where the partial stripe condition was returning true and so should_writeback() was returning true early. If that hadn't been the case, it would have hit the would_skip test, and as would_skip == s->iop.bypass == true, should_writeback() would have returned false. Looking at the git history from 72c27061 ("bcache: Write out full stripes"), it looks like the idea was to optimise for raid5/6: * If a stripe is already dirty, force writes to that stripe to writeback mode - to help build up full stripes of dirty data To fix this issue, make sure that should_writeback() on a discard op never returns true. More details of debugging: https://www.spinics.net/lists/linux-bcache/msg06996.html Previous reports: - https://bugzilla.kernel.org/show_bug.cgi?id=201051 - https://bugzilla.kernel.org/show_bug.cgi?id=196103 - https://www.spinics.net/lists/linux-bcache/msg06885.html Cc: Kent Overstreet <koverstreet@google.com> Fixes: 72c27061 ("bcache: Write out full stripes") Signed-off-by:
Daniel Axtens <dja@axtens.net> (backported from linux-bcache mailing list: https://www.spinics.net/lists/linux-bcache/msg06997.html Expected to land in v5.1: https://www.spinics.net/lists/linux-bcache/msg06998.html backport posted on-list at: https://www.spinics.net/lists/linux-bcache/msg07024.html) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com> Acked-by:
-
Dmitry Safonov authored
BugLink: https://bugs.launchpad.net/bugs/1813873 Try to get reference for ldisc during tty_reopen(). If ldisc present, we don't need to do tty_ldisc_reinit() and lock the write side for line discipline semaphore. Effectively, it optimizes fast-path for tty_reopen(), but more importantly it won't interrupt ongoing IO on the tty as no ldisc change is needed. Fixes user-visible issue when tty_reopen() interrupted login process for user with a long password, observed and reported by Lukas. Fixes: c96cf923 ("tty: Don't block on IO when ldisc change is pending") Fixes: 83d817f4 ("tty: Hold tty_ldisc_lock() during tty_reopen()") Cc: Jiri Slaby <jslaby@suse.com> Reported-by:
Lukas F. Hartmann <lukas@mntmn.com> Tested-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
David Herrmann authored
This changes the fork(2) syscall to record the process start_time after initializing the basic task structure but still before making the new process visible to user-space. Technically, we could record the start_time anytime during fork(2). But this might lead to scenarios where a start_time is recorded long before a process becomes visible to user-space. For instance, with userfaultfd(2) and TLS, user-space can delay the execution of fork(2) for an indefinite amount of time (and will, if this causes network access, or similar). By recording the start_time late, it much closer reflects the point in time where the process becomes live and can be observed by other processes. Lastly, this makes it much harder for user-space to predict and control the start_time they get assigned. Previously, user-space could fork a process and stall it in copy_thread_tls() before its pid is allocated, but after its start_time is recorded. This can be misused to later-on cycle through PIDs and resume the stalled fork(2) yielding a process that has the same pid and start_time as a process that existed before. This can be used to circumvent security systems that identify processes by their pid+start_time combination. Even though user-space was always aware that start_time recording is flaky (but several projects are known to still rely on start_time-based identification), changing the start_time to be recorded late will help mitigate existing attacks and make it much harder for user-space to control the start_time a process gets assigned. Reported-by:
Jann Horn <jannh@google.com> Signed-off-by:
Tom Gundersen <teg@jklm.no> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> CVE-2019-6133 (cherry picked from commit 7b558513) Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1811803 Fix a NULL pointer dereference in fan code that can easily be triggered by running: $ sudo ip link add foo type ipip Which leads to: [ 1.330067] BUG: unable to handle kernel NULL pointer dereference at 0000000000000108 [ 1.330792] IP: [<ffffffff817e8132>] ipip_netlink_fan.isra.7+0x12/0x280 [ 1.331399] PGD 800000003fb94067 PUD 3fb93067 PMD 0 [ 1.331882] Oops: 0000 [#1] SMP [ 1.332200] Modules linked in: [ 1.332492] CPU: 0 PID: 137 Comm: ip Not tainted 4.4.167+ #5 [ 1.333001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 1.333740] task: ffff88003c38a640 ti: ffff88003fb5c000 task.ti: ffff88003fb5c000 [ 1.334375] RIP: 0010:[<ffffffff817e8132>] [<ffffffff817e8132>] ipip_netlink_fan.isra.7+0x12/0x280 [ 1.335193] RSP: 0018:ffff88003fb5f778 EFLAGS: 00010246 [ 1.335671] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 1.336305] RDX: ffff88003fb5f7f0 RSI: ffff88003fa3f840 RDI: 0000000000000000 [ 1.336940] RBP: ffff88003fb5f7a0 R08: 000000000000000a R09: 0000000000000092 [ 1.337587] R10: 0000000000000000 R11: 00000000000001ad R12: ffff88003fa3f000 [ 1.338267] R13: ffff88003fb5f9d0 R14: ffff88003fa3f840 R15: ffffffff81f4b240 [ 1.338904] FS: 00007f535979b700(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000 [ 1.339590] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.340066] CR2: 0000000000000108 CR3: 000000003fb60000 CR4: 0000000000000670 [ 1.340750] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.341341] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.341909] Stack: [ 1.342080] 0000000000000000 ffff88003fa3f000 ffff88003fb5f9d0 ffff88003fa3f840 [ 1.342725] ffffffff81f4b240 ffff88003fb5f828 ffffffff817e8515 0000000381356f0e [ 1.343334] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 1.343943] Call Trace: [ 1.344141] [<ffffffff817e8515>] ipip_newlink+0xa5/0xc0 [ 1.344553] [<ffffffff81782f5b>] ? __netlink_ns_capable+0x3b/0x40 [ 1.345029] [<ffffffff817651fd>] rtnl_newlink+0x6fd/0x8b0 [ 1.345699] [<ffffffff811f92b1>] ? kmem_cache_alloc+0x1a1/0x1f0 [ 1.346165] [<ffffffff8119abd5>] ? mempool_alloc_slab+0x15/0x20 [ 1.346630] [<ffffffff81436463>] ? validate_nla+0x93/0x1a0 [ 1.347060] [<ffffffff81436680>] ? nla_parse+0xa0/0x100 [ 1.347474] [<ffffffff81436732>] ? nla_strlcpy+0x52/0x60 [ 1.347891] [<ffffffff81762099>] ? rtnl_link_ops_get+0x39/0x50 [ 1.348347] [<ffffffff81764c76>] ? rtnl_newlink+0x176/0x8b0 [ 1.348784] [<ffffffff8176373c>] rtnetlink_rcv_msg+0xec/0x230 [ 1.349237] [<ffffffff811fce3b>] ? __kmalloc_node_track_caller+0x24b/0x310 [ 1.349774] [<ffffffff8173e397>] ? __alloc_skb+0x87/0x1d0 [ 1.350198] [<ffffffff81763650>] ? rtnetlink_rcv+0x30/0x30 [ 1.350628] [<ffffffff81786da6>] netlink_rcv_skb+0xa6/0xc0 [ 1.351059] [<ffffffff81763648>] rtnetlink_rcv+0x28/0x30 [ 1.351476] [<ffffffff81786770>] netlink_unicast+0x190/0x240 [ 1.351919] [<ffffffff81786b5a>] netlink_sendmsg+0x33a/0x3b0 [ 1.352363] [<ffffffff813af211>] ? aa_sock_msg_perm+0x61/0x150 [ 1.352820] [<ffffffff81734bde>] sock_sendmsg+0x3e/0x50 [ 1.353235] [<ffffffff817356a7>] ___sys_sendmsg+0x287/0x2a0 [ 1.353672] [<ffffffff8120ed2b>] ? mem_cgroup_try_charge+0x6b/0x1e0 [ 1.354162] [<ffffffff811cb9ed>] ? handle_mm_fault+0xecd/0x1b80 [ 1.354625] [<ffffffff81239fc7>] ? __alloc_fd+0xc7/0x190 [ 1.355044] [<ffffffff81736021>] __sys_sendmsg+0x51/0x90 [ 1.355525] [<ffffffff81736072>] SyS_sendmsg+0x12/0x20 [ 1.355933] [<ffffffff81866e1b>] entry_SYSCALL_64_fastpath+0x22/0xcb [ 1.356426] Code: 50 01 00 00 01 eb d3 49 8d 94 24 b8 08 00 00 eb ac e8 83 cf 89 ff 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 9f 08 01 00 00 48 85 db 74 1e 8b 02 85 c0 75 25 44 0f b7 [ 1.358557] RIP [<ffffffff817e8132>] ipip_netlink_fan.isra.7+0x12/0x280 [ 1.359086] RSP <ffff88003fb5f778> [ 1.359359] CR2: 0000000000000108 [ 1.359637] ---[ end trace 7820fbc7ced5dd6e ]--- Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Juerg Haefliger authored
Ignore: yes Signed-off-by:
-
- 16 Jan, 2019 34 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by:Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Kleber Sacilotto de Souza authored
BugLink: https://bugs.launchpad.net/bugs/1811846Signed-off-by:
-
Kleber Sacilotto de Souza authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1811094 age is signed integer, so result can be negative when the timestamps have a large delta. In this case we want to discard the entry. Instead of using age >= 2 || age < 0, just make it unsigned. Fixes: b36e4523 ("netfilter: nf_conncount: fix garbage collection confirm race") Reviewed-by:
Shawn Bohrer <sbohrer@cloudflare.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> (backported from commit 4cd273bb) [mfo: backport: use older file name, nf_conncount.c -> xt_connlimit.c] Signed-off-by:
Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1811094 Yi-Hung Wei and Justin Pettit found a race in the garbage collection scheme used by nf_conncount. When doing list walk, we lookup the tuple in the conntrack table. If the lookup fails we remove this tuple from our list because the conntrack entry is gone. This is the common cause, but turns out its not the only one. The list entry could have been created just before by another cpu, i.e. the conntrack entry might not yet have been inserted into the global hash. The avoid this, we introduce a timestamp and the owning cpu. If the entry appears to be stale, evict only if: 1. The current cpu is the one that added the entry, or, 2. The timestamp is older than two jiffies The second constraint allows GC to be taken over by other cpu too (e.g. because a cpu was offlined or napi got moved to another cpu). We can't pretend the 'doubtful' entry wasn't in our list. Instead, when we don't find an entry indicate via IS_ERR that entry was removed ('did not exist' or withheld ('might-be-unconfirmed'). This most likely also fixes a xt_connlimit imbalance earlier reported by Dmitry Andrianov. Cc: Dmitry Andrianov <dmitry.andrianov@alertme.com> Reported-by:
Justin Pettit <jpettit@vmware.com> Reported-by:
Yi-Hung Wei <yihung.wei@gmail.com> Signed-off-by:
-
Yi-Hung Wei authored
BugLink: https://bugs.launchpad.net/bugs/1811094 Currently, we use check_hlist() for garbage colleciton. However, we use the ‘zone’ from the counted entry to query the existence of existing entries in the hlist. This could be wrong when they are in different zones, and this patch fixes this issue. Fixes: e59ea3df ("netfilter: xt_connlimit: honor conntrack zone if available") Signed-off-by:
-
Pablo Neira Ayuso authored
BugLink: https://bugs.launchpad.net/bugs/1811094 This patch provides an interface to maintain the list of connections and the lookup function to obtain the number of connections in the list. Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: https://bugs.launchpad.net/bugs/1811094 The previous commit made the 'addr' parameter in add_hlist() unused. So remove it with a SAUCE patch, to simplify the backport of the next patches, as it is removed anyway in upstream later (but before the next patches) through commit 625c5561 ("netfilter: connlimit: split xt_connlimit into front and backend"), in the rename from 'xt_connlimit.c' to 'nf_conncount.c', which is a large refactor we don't need. Signed-off-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1811094 Only stored, never read. This is a leftover from commit 7d084877 ("netfilter: connlimit: use rbtree for per-host conntrack obj storage"), which added the rbtree node struct that stores the address instead. Signed-off-by:
-
Juerg Haefliger authored
Move the RSB_CTXSW hunk further up in spectre_v2_select_mitigation() to match upstream. No functional changes. CVE-2017-5715 Signed-off-by:
-
Juerg Haefliger authored
Honor the value of x86_spec_ctrl_base when manipulating the MSR_IA32_SPEC_CTRL MSR in the entry/exit code. CVE-2017-5715 Signed-off-by:
-
Juerg Haefliger authored
In Ubuntu, we have runtime control for enabling/disabling IBRS via the commandline ("noibrs") and through the proc interface /proc/sys/kernel/ibrs_enabled. This commit simplifies the current (probably broken) implementation by merging it with all the IBRS-related upstream changes from previous commits. What we have now is the upstream implementation for detecting the presence of IBRS support. This commit adds a global state variable 'ibrs_enabled' which is set to 1 if the CPU supports IBRS but can be overridden via the commandline "noibrs" switch or by writting 0, 1 or 2 to /proc/sys/kernel/ibrs_enabled at runtime. Note that the runtime controls are disabled if the CPU runs in Enhanced IBRS mode. CVE-2017-5715 Signed-off-by: -
Juerg Haefliger authored
In Ubuntu, we have runtime control for enabling/disabling IBPB via the commandline ("noibpb") and through the proc interface /proc/sys/kernel/ibpb_enabled. This commit simplifies the current (broken) implementation by merging it with all the IBPB-related upstream changes from previous commits. What we have now is the upstream implementation for detecting the presence of IBPB support which is used in the alternative MSR write in indirect_branch_prediction_barrier() to enable IBPB. On top of that, this commit adds a global state variable 'ibpb_enabled' which is set to 1 if the CPU supports IBPB but can be overridden via the commandline "noibpb" switch or by writting 0 or 1 to /proc/sys/kernel/ibpb_enabled at runtime. If ibpb_enabled is 0, indirect_branch_prediction_barrier() is turned into a no-op, same as if the platform doesn't support IBPB. CVE-2017-5715 Signed-off-by: -
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1811077Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 990d7184 upstream. NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 CC: <stable@vger.kernel.org> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 9ec1190d upstream. If the buffered broadcast queue contains packets, letting new packets bypass that queue can lead to heavy reordering, since the driver is probably throttling transmission of buffered multicast packets after beacons. Keep buffering packets until the buffer has been cleared (and no client is in powersave mode). Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit a317e65f upstream. Make it behave like regular ieee80211_tx_status calls, except for the lack of filtered frame processing. This fixes spurious low-ack triggered disconnections with powersave clients connected to an AP. Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb") Cc: stable@vger.kernel.org Signed-off-by:
-
Ben Greear authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 5c21e810 upstream. This fixes stale beacon-int values that would keep a netdev from going up. To reproduce: Create two VAP on one radio. vap1 has beacon-int 100, start it. vap2 has beacon-int 240, start it (and it will fail because beacon-int mismatch). reconfigure vap2 to have beacon-int 100 and start it. It will fail because the stale beacon-int 240 will be used in the ifup path and hostapd never gets a chance to set the new beacon interval. Cc: stable@vger.kernel.org Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Vasyl Vavrychuk authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit a1881c9b upstream. Otherwise if network manager starts configuring Wi-Fi interface immidiatelly after getting notification of its creation, we will get NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50 ... Call Trace: [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110 [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20 [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim] Cc: stable@vger.kernel.org Signed-off-by:
Vasyl Vavrychuk <vasyl.vavrychuk@globallogic.com> Signed-off-by:
-
Macpaul Lin authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit dada6a43 upstream. This patch is trying to fix KE issue due to "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198" reported by Syzkaller scan." [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198 [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364 [26364:syz-executor0][name:report&] [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0 [26364:syz-executor0]Call trace: [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470 [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30 [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128 [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8 [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390 [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20 [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198 [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270 [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90 [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158 [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8 [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0 [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0 [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8 [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208 [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]The buggy address belongs to the variable: [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]Memory state around the buggy address: [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 [26364:syz-executor0][name:report&] ^ [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [26364:syz-executor0][name:report&] [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint [26364:syz-executor0]------------[cut here]------------ After checking the source code, we've found there might be an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero. Signed-off-by:
Macpaul Lin <macpaul@gmail.com> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Peter Shih authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 100bc3e2 upstream. serial8250_register_8250_port calls uart_config_port, which calls config_port on the port before it tries to power on the port. So we need the port to be on before calling serial8250_register_8250_port. Change the code to always do a runtime resume in probe before registering port, and always do a runtime suspend in remove. This basically reverts the change in commit 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling"), but still use pm_runtime callbacks. Fixes: 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling") Signed-off-by:
Peter Shih <pihsun@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Paulo Alcantara authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit c988de29 upstream. Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for prefixpath too. Fixes a bug with smb1 UNIX extensions. Fixes: a6b5058f ("fs/cifs: make share unaccessible at root level mountable") Signed-off-by:
Paulo Alcantara <palcantara@suse.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [for older kernels only, lustre has been removed from upstream] When someone writes: strncpy(dest, source, sizeof(source)); they really are just doing the same thing as: strcpy(dest, source); but somehow they feel better because they are now using the "safe" version of the string functions. Cargo-cult programming at its finest... gcc-8 rightfully warns you about doing foolish things like this. Now that the stable kernels are all starting to be built using gcc-8, let's get rid of this warning so that we do not have to gaze at this horror. To dropt the warning, just convert the code to using strcpy() so that if someone really wants to audit this code and find all of the obvious problems, it will be easier to do so. Signed-off-by:
-
Mathias Nyman authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 0472bf06 upstream. Don't allow USB3 U1 or U2 if the latency to wake up from the U-state reaches the service interval for a periodic endpoint. This is according to xhci 1.1 specification section 4.23.5.2 extra note: "Software shall ensure that a device is prevented from entering a U-state where its worst case exit latency approaches the ESIT." Allowing too long exit latencies for periodic endpoint confuses xHC internal scheduling, and new devices may fail to enumerate with a "Not enough bandwidth for new device state" error from the host. Cc: <stable@vger.kernel.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 8dae5398 upstream. call_encode can be invoked more than once per RPC call. Ensure that each call to gss_wrap_req_priv does not overwrite pointers to previously allocated memory. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Cc: stable@kernel.org Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Halil Pasic authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 78b1a52e upstream. While ccw_io_helper() seems like intended to be exclusive in a sense that it is supposed to facilitate I/O for at most one thread at any given time, there is actually nothing ensuring that threads won't pile up at vcdev->wait_q. If they do, all threads get woken up and see the status that belongs to some other request than their own. This can lead to bugs. For an example see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 This race normally does not cause any problems. The operations provided by struct virtio_config_ops are usually invoked in a well defined sequence, normally don't fail, and are normally used quite infrequent too. Yet, if some of the these operations are directly triggered via sysfs attributes, like in the case described by the referenced bug, userspace is given an opportunity to force races by increasing the frequency of the given operations. Let us fix the problem by ensuring, that for each device, we finish processing the previous request before starting with a new one. Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reported-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Halil Pasic authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 2448a299 upstream. Currently we have a race on vcdev->config in virtio_ccw_get_config() and in virtio_ccw_set_config(). This normally does not cause problems, as these are usually infrequent operations. However, for some devices writing to/reading from the config space can be triggered through sysfs attributes. For these, userspace can force the race by increasing the frequency. Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 5363857b upstream. As addressed in alsa-lib (commit b420056604f0), we need to fix the case where the evaluation of PCM interval "(x x+1]" leading to -EINVAL. After applying rules, such an interval may be translated as "(x x+1)". Fixes: ff2d6acd ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max") Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit b51abed8 upstream. Currently the PCM core calls snd_pcm_unlink() always unconditionally at closing a stream. However, since snd_pcm_unlink() invokes the global rwsem down, the lock can be easily contended. More badly, when a thread runs in a high priority RT-FIFO, it may stall at spinning. Basically the call of snd_pcm_unlink() is required only for the linked streams that are already rare occasion. For normal use cases, this code path is fairly superfluous. As an optimization (and also as a workaround for the RT problem above in normal situations without linked streams), this patch adds a check before calling snd_pcm_unlink() and calls it only when needed. Reported-by:
Chanho Min <chanho.min@lge.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Chanho Min authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit b888a5f7 upstream. Commit 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") fixes deadlock for non-atomic PCM stream. But, This patch causes antother stuck. If writer is RT thread and reader is a normal thread, the reader thread will be difficult to get scheduled. It may not give chance to release readlocks and writer gets stuck for a long time if they are pinned to single cpu. The deadlock described in the previous commit is because the linux rwsem queues like a FIFO. So, we might need non-FIFO writelock, not non-block one. My suggestion is that the writer gives reader a chance to be scheduled by using the minimum msleep() instaed of spinning without blocking by writer. Also, The *_nonblock may be changed to *_nonfifo appropriately to this concept. In terms of performance, when trylock is failed, this minimum periodic msleep will have the same performance as the tick-based schedule()/wake_up_q(). [ Although this has a fairly high performance penalty, the relevant code path became already rare due to the previous commit ("ALSA: pcm: Call snd_pcm_unlink() conditionally at closing"). That is, now this unconditional msleep appears only when using linked streams, and this must be a rare case. So we accept this as a quick workaround until finding a more suitable one -- tiwai ] Fixes: 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") Suggested-by:
Wonmin Jung <wonmin.jung@lge.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 3deef52c upstream. It's similar to other AMD audio devices, it also supports D3, which can save some power drain. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hui Peng authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 5f8cf712 upstream. If a USB sound card reports 0 interfaces, an error condition is triggered and the function usb_audio_probe errors out. In the error path, there was a use-after-free vulnerability where the memory object of the card was first freed, followed by a decrement of the number of active chips. Moving the decrement above the atomic_dec fixes the UAF. [ The original problem was introduced in 3.1 kernel, while it was developed in a different form. The Fixes tag below indicates the original commit but it doesn't mean that the patch is applicable cleanly. -- tiwai ] Fixes: 362e4e49 ("ALSA: usb-audio - clear chip->probing on error exit") Reported-by:
Hui Peng <benquike@gmail.com> Reported-by:
Mathias Payer <mathias.payer@nebelwelt.net> Signed-off-by:
-
Mathias Payer authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 704620af upstream. When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by:
-
Alexander Theissen authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit d7859905 upstream. Add another Apple Cinema Display to the list of supported displays. Signed-off-by:
Alexander Theissen <alex.theissen@me.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
