<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include, branch v4.14.149</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.149</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.14.149'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-10-11T16:18:49Z</updated>
<entry>
<title>cfg80211: Use const more consistently in for_each_element macros</title>
<updated>2019-10-11T16:18:49Z</updated>
<author>
<name>Jouni Malinen</name>
<email>j@w1.fi</email>
</author>
<published>2019-02-11T14:29:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cd813e524abcf7dc89231930858f1ac3af372af9'/>
<id>urn:sha1:cd813e524abcf7dc89231930858f1ac3af372af9</id>
<content type='text'>
commit 7388afe09143210f555bdd6c75035e9acc1fab96 upstream.

Enforce the first argument to be a correct type of a pointer to struct
element and avoid unnecessary typecasts from const to non-const pointers
(the change in validate_ie_attr() is needed to make this part work). In
addition, avoid signed/unsigned comparison within for_each_element() and
mark struct element packed just in case.

Signed-off-by: Jouni Malinen &lt;j@w1.fi&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cfg80211: add and use strongly typed element iteration macros</title>
<updated>2019-10-11T16:18:48Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2019-02-07T20:44:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1b1e2db0298a0ac7e57f744c3b3bd280273fe6ea'/>
<id>urn:sha1:1b1e2db0298a0ac7e57f744c3b3bd280273fe6ea</id>
<content type='text'>
commit 0f3b07f027f87a38ebe5c436490095df762819be upstream.

Rather than always iterating elements from frames with pure
u8 pointers, add a type "struct element" that encapsulates
the id/datalen/data format of them.

Then, add the element iteration macros
 * for_each_element
 * for_each_element_id
 * for_each_element_extid

which take, as their first 'argument', such a structure and
iterate through a given u8 array interpreting it as elements.

While at it and since we'll need it, also add
 * for_each_subelement
 * for_each_subelement_id
 * for_each_subelement_extid

which instead of taking data/length just take an outer element
and use its data/datalen.

Also add for_each_element_completed() to determine if any of
the loops above completed, i.e. it was able to parse all of
the elements successfully and no data remained.

Use for_each_element_id() in cfg80211_find_ie_match() as the
first user of this.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ASoC: Define a set of DAPM pre/post-up events</title>
<updated>2019-10-11T16:18:30Z</updated>
<author>
<name>Oleksandr Suvorov</name>
<email>oleksandr.suvorov@toradex.com</email>
</author>
<published>2019-07-19T10:05:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7fda3e7f0a5066667a0c362c6c990bc074ed373a'/>
<id>urn:sha1:7fda3e7f0a5066667a0c362c6c990bc074ed373a</id>
<content type='text'>
commit cfc8f568aada98f9608a0a62511ca18d647613e2 upstream.

Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to
reduce coming code size and make it more readable.

Cc: stable@vger.kernel.org
Signed-off-by: Oleksandr Suvorov &lt;oleksandr.suvorov@toradex.com&gt;
Reviewed-by: Marcel Ziswiler &lt;marcel.ziswiler@toradex.com&gt;
Reviewed-by: Igor Opaniuk &lt;igor.opaniuk@toradex.com&gt;
Reviewed-by: Fabio Estevam &lt;festevam@gmail.com&gt;
Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: core: Reduce memory required for SCSI logging</title>
<updated>2019-10-07T16:55:06Z</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2019-08-01T22:38:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=86906603260add5f97829cb8bc72382cc09eae15'/>
<id>urn:sha1:86906603260add5f97829cb8bc72382cc09eae15</id>
<content type='text'>
[ Upstream commit dccc96abfb21dc19d69e707c38c8ba439bba7160 ]

The data structure used for log messages is so large that it can cause a
boot failure. Since allocations from that data structure can fail anyway,
use kmalloc() / kfree() instead of that data structure.

See also https://bugzilla.kernel.org/show_bug.cgi?id=204119.
See also commit ded85c193a39 ("scsi: Implement per-cpu logging buffer") # v4.0.

Reported-by: Jan Palus &lt;jpalus@fastmail.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Cc: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: Jan Palus &lt;jpalus@fastmail.com&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>quota: fix wrong condition in is_quota_modification()</title>
<updated>2019-10-05T10:48:12Z</updated>
<author>
<name>Chao Yu</name>
<email>yuchao0@huawei.com</email>
</author>
<published>2019-09-11T09:36:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=94ad384da9237d707d224d47a4b736e87e0f9a05'/>
<id>urn:sha1:94ad384da9237d707d224d47a4b736e87e0f9a05</id>
<content type='text'>
commit 6565c182094f69e4ffdece337d395eb7ec760efc upstream.

Quoted from
commit 3da40c7b0898 ("ext4: only call ext4_truncate when size &lt;= isize")

" At LSF we decided that if we truncate up from isize we shouldn't trim
  fallocated blocks that were fallocated with KEEP_SIZE and are past the
 new i_size.  This patch fixes ext4 to do this. "

And generic/092 of fstest have covered this case for long time, however
is_quota_modification() didn't adjust based on that rule, so that in
below condition, we will lose to quota block change:
- fallocate blocks beyond EOF
- remount
- truncate(file_path, file_size)

Fix it.

Link: https://lore.kernel.org/r/20190911093650.35329-1-yuchao0@huawei.com
Fixes: 3da40c7b0898 ("ext4: only call ext4_truncate when size &lt;= isize")
CC: stable@vger.kernel.org
Signed-off-by: Chao Yu &lt;yuchao0@huawei.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kprobes: Prohibit probing on BUG() and WARN() address</title>
<updated>2019-10-05T10:48:01Z</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2019-09-03T11:08:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=05fade62bd53af335ee6cae1c8030a0aae40c8ad'/>
<id>urn:sha1:05fade62bd53af335ee6cae1c8030a0aae40c8ad</id>
<content type='text'>
[ Upstream commit e336b4027775cb458dc713745e526fa1a1996b2a ]

Since BUG() and WARN() may use a trap (e.g. UD2 on x86) to
get the address where the BUG() has occurred, kprobes can not
do single-step out-of-line that instruction. So prohibit
probing on such address.

Without this fix, if someone put a kprobe on WARN(), the
kernel will crash with invalid opcode error instead of
outputing warning message, because kernel can not find
correct bug address.

Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Acked-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Acked-by: Naveen N. Rao &lt;naveen.n.rao@linux.vnet.ibm.com&gt;
Cc: Anil S Keshavamurthy &lt;anil.s.keshavamurthy@intel.com&gt;
Cc: David S . Miller &lt;davem@davemloft.net&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Naveen N . Rao &lt;naveen.n.rao@linux.ibm.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lkml.kernel.org/r/156750890133.19112.3393666300746167111.stgit@devnote2
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/core: Add an unbound WQ type to the new CQ API</title>
<updated>2019-10-05T10:47:32Z</updated>
<author>
<name>Jack Morgenstein</name>
<email>jackm@dev.mellanox.co.il</email>
</author>
<published>2018-08-27T05:35:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=51b51a4c6b7d3297c75bf484ae89bfdf4798e73f'/>
<id>urn:sha1:51b51a4c6b7d3297c75bf484ae89bfdf4798e73f</id>
<content type='text'>
commit f794809a7259dfaa3d47d90ef5a86007cf48b1ce upstream.

The upstream kernel commit cited below modified the workqueue in the
new CQ API to be bound to a specific CPU (instead of being unbound).
This caused ALL users of the new CQ API to use the same bound WQ.

Specifically, MAD handling was severely delayed when the CPU bound
to the WQ was busy handling (higher priority) interrupts.

This caused a delay in the MAD "heartbeat" response handling,
which resulted in ports being incorrectly classified as "down".

To fix this, add a new "unbound" WQ type to the new CQ API, so that users
have the option to choose either a bound WQ or an unbound WQ.

For MADs, choose the new "unbound" WQ.

Fixes: b7363e67b23e ("IB/device: Convert ib-comp-wq to be CPU-bound")
Signed-off-by: Jack Morgenstein &lt;jackm@dev.mellanox.co.il&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@mellanox.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.m&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info</title>
<updated>2019-09-21T05:15:32Z</updated>
<author>
<name>Juliana Rodrigueiro</name>
<email>juliana.rodrigueiro@intra2net.com</email>
</author>
<published>2019-08-16T15:02:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a46102f47dfe7da531facb9eacc5020e86ae7229'/>
<id>urn:sha1:a46102f47dfe7da531facb9eacc5020e86ae7229</id>
<content type='text'>
[ Upstream commit 89a26cd4b501e9511d3cd3d22327fc76a75a38b3 ]

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 &lt;chain&gt; -m nfacct --nfacct-name &lt;acct-object&gt;
    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: Juliana Rodrigueiro &lt;juliana.rodrigueiro@intra2net.com&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>isdn/capi: check message length in capi_write()</title>
<updated>2019-09-19T07:08:00Z</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2019-09-06T02:36:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2b710b0ec2b3c0957e7ab434b33153f47fbae60e'/>
<id>urn:sha1:2b710b0ec2b3c0957e7ab434b33153f47fbae60e</id>
<content type='text'>
[ Upstream commit fe163e534e5eecdfd7b5920b0dfd24c458ee85d6 ]

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: syzbot+0849c524d9c634f5ae66@syzkaller.appspotmail.com
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ip6: fix skb leak in ip6frag_expire_frag_queue()</title>
<updated>2019-09-16T06:20:44Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2019-05-03T15:24:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=720a6817e131b1208263f1a951d0c8ee1982950a'/>
<id>urn:sha1:720a6817e131b1208263f1a951d0c8ee1982950a</id>
<content type='text'>
commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4 upstream.

Since ip6frag_expire_frag_queue() now pulls the head skb
from frag queue, we should no longer use skb_get(), since
this leads to an skb leak.

Stefan Bader initially reported a problem in 4.4.stable [1] caused
by the skb_get(), so this patch should also fix this issue.

296583.091021] kernel BUG at /build/linux-6VmqmP/linux-4.4.0/net/core/skbuff.c:1207!
[296583.091734] Call Trace:
[296583.091749]  [&lt;ffffffff81740e50&gt;] __pskb_pull_tail+0x50/0x350
[296583.091764]  [&lt;ffffffff8183939a&gt;] _decode_session6+0x26a/0x400
[296583.091779]  [&lt;ffffffff817ec719&gt;] __xfrm_decode_session+0x39/0x50
[296583.091795]  [&lt;ffffffff818239d0&gt;] icmpv6_route_lookup+0xf0/0x1c0
[296583.091809]  [&lt;ffffffff81824421&gt;] icmp6_send+0x5e1/0x940
[296583.091823]  [&lt;ffffffff81753238&gt;] ? __netif_receive_skb+0x18/0x60
[296583.091838]  [&lt;ffffffff817532b2&gt;] ? netif_receive_skb_internal+0x32/0xa0
[296583.091858]  [&lt;ffffffffc0199f74&gt;] ? ixgbe_clean_rx_irq+0x594/0xac0 [ixgbe]
[296583.091876]  [&lt;ffffffffc04eb260&gt;] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
[296583.091893]  [&lt;ffffffff8183d431&gt;] icmpv6_send+0x21/0x30
[296583.091906]  [&lt;ffffffff8182b500&gt;] ip6_expire_frag_queue+0xe0/0x120
[296583.091921]  [&lt;ffffffffc04eb27f&gt;] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6]
[296583.091938]  [&lt;ffffffff810f3b57&gt;] call_timer_fn+0x37/0x140
[296583.091951]  [&lt;ffffffffc04eb260&gt;] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
[296583.091968]  [&lt;ffffffff810f5464&gt;] run_timer_softirq+0x234/0x330
[296583.091982]  [&lt;ffffffff8108a339&gt;] __do_softirq+0x109/0x2b0

Fixes: d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6 defrag")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Stefan Bader &lt;stefan.bader@canonical.com&gt;
Cc: Peter Oskolkov &lt;posk@google.com&gt;
Cc: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
