<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.9.210</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.210</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.210'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-01-14T19:04:32+00:00</updated>
<entry>
<title>Linux 4.9.210</title>
<updated>2020-01-14T19:04:32+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2020-01-14T19:04:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=36fa7559a1ce29b6fe8bbaa686b1524bfe8f7c77'/>
<id>urn:sha1:36fa7559a1ce29b6fe8bbaa686b1524bfe8f7c77</id>
<content type='text'>
</content>
</entry>
<entry>
<title>drm/i915/gen9: Clear residual context state on context switch</title>
<updated>2020-01-14T19:04:32+00:00</updated>
<author>
<name>Akeem G Abodunrin</name>
<email>akeem.g.abodunrin@intel.com</email>
</author>
<published>2020-01-08T20:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=571233331e1910206ec365ac61e5b51e77cce3b9'/>
<id>urn:sha1:571233331e1910206ec365ac61e5b51e77cce3b9</id>
<content type='text'>
commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Intel GPU Hardware prior to Gen11 does not clear EU state
during a context switch. This can result in information
leakage between contexts.

For Gen8 and Gen9, hardware provides a mechanism for
fast cleardown of the EU state, by issuing a PIPE_CONTROL
with bit 27 set. We can use this in a context batch buffer
to explicitly cleardown the state on every context switch.

As this workaround is already in place for gen8, we can borrow
the code verbatim for Gen9.

Signed-off-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Akeem G Abodunrin &lt;akeem.g.abodunrin@intel.com&gt;
Cc: Kumar Valsan Prathap &lt;prathap.kumar.valsan@intel.com&gt;
Cc: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Cc: Balestrieri Francesco &lt;francesco.balestrieri@intel.com&gt;
Cc: Bloomfield Jon &lt;jon.bloomfield@intel.com&gt;
Cc: Dutt Sudeep &lt;sudeep.dutt@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>netfilter: ipset: avoid null deref when IPSET_ATTR_LINENO is present</title>
<updated>2020-01-14T19:04:32+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2020-01-08T09:59:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6280b60debe02bd31c2efce0dcc72227781f206'/>
<id>urn:sha1:a6280b60debe02bd31c2efce0dcc72227781f206</id>
<content type='text'>
commit 22dad713b8a5ff488e07b821195270672f486eb2 upstream.

The set uadt functions assume lineno is never NULL, but it is in
case of ip_set_utest().

syzkaller managed to generate a netlink message that calls this with
LINENO attr present:

general protection fault: 0000 [#1] PREEMPT SMP KASAN
RIP: 0010:hash_mac4_uadt+0x1bc/0x470 net/netfilter/ipset/ip_set_hash_mac.c:104
Call Trace:
 ip_set_utest+0x55b/0x890 net/netfilter/ipset/ip_set_core.c:1867
 nfnetlink_rcv_msg+0xcf2/0xfb0 net/netfilter/nfnetlink.c:229
 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
 nfnetlink_rcv+0x1ba/0x460 net/netfilter/nfnetlink.c:563

pass a dummy lineno storage, its easier than patching all set
implementations.

This seems to be a day-0 bug.

Cc: Jozsef Kadlecsik &lt;kadlec@blackhole.kfki.hu&gt;
Reported-by: syzbot+34bd2369d38707f3f4a7@syzkaller.appspotmail.com
Fixes: a7b4f989a6294 ("netfilter: ipset: IP set core support")
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Acked-by: Jozsef Kadlecsik &lt;kadlec@blackhole.kfki.hu&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>netfilter: arp_tables: init netns pointer in xt_tgchk_param struct</title>
<updated>2020-01-14T19:04:31+00:00</updated>
<author>
<name>Florian Westphal</name>
<email>fw@strlen.de</email>
</author>
<published>2019-12-27T00:33:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76c146cef28dae3bf82839876e46db6730c63f81'/>
<id>urn:sha1:76c146cef28dae3bf82839876e46db6730c63f81</id>
<content type='text'>
commit 1b789577f655060d98d20ed0c6f9fbd469d6ba63 upstream.

We get crash when the targets checkentry function tries to make
use of the network namespace pointer for arptables.

When the net pointer got added back in 2010, only ip/ip6/ebtables were
changed to initialize it, so arptables has this set to NULL.

This isn't a problem for normal arptables because no existing
arptables target has a checkentry function that makes use of par-&gt;net.

However, direct users of the setsockopt interface can provide any
target they want as long as its registered for ARP or UNPSEC protocols.

syzkaller managed to send a semi-valid arptables rule for RATEEST target
which is enough to trigger NULL deref:

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
RIP: xt_rateest_tg_checkentry+0x11d/0xb40 net/netfilter/xt_RATEEST.c:109
[..]
 xt_check_target+0x283/0x690 net/netfilter/x_tables.c:1019
 check_target net/ipv4/netfilter/arp_tables.c:399 [inline]
 find_check_entry net/ipv4/netfilter/arp_tables.c:422 [inline]
 translate_table+0x1005/0x1d70 net/ipv4/netfilter/arp_tables.c:572
 do_replace net/ipv4/netfilter/arp_tables.c:977 [inline]
 do_arpt_set_ctl+0x310/0x640 net/ipv4/netfilter/arp_tables.c:1456

Fixes: add67461240c1d ("netfilter: add struct net * to target parameters")
Reported-by: syzbot+d7358a458d8a81aee898@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal &lt;fw@strlen.de&gt;
Acked-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: Fix: Don't skip endpoint descriptors with maxpacket=0</title>
<updated>2020-01-14T19:04:31+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2020-01-06T15:43:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=135878c0b1e0d3135f72392c44f531322594987c'/>
<id>urn:sha1:135878c0b1e0d3135f72392c44f531322594987c</id>
<content type='text'>
commit 2548288b4fb059b2da9ceada172ef763077e8a59 upstream.

It turns out that even though endpoints with a maxpacket length of 0
aren't useful for data transfer, the descriptors do serve other
purposes.  In particular, skipping them will also skip over other
class-specific descriptors for classes such as UVC.  This unexpected
side effect has caused some UVC cameras to stop working.

In addition, the USB spec requires that when isochronous endpoint
descriptors are present in an interface's altsetting 0 (which is true
on some devices), the maxpacket size _must_ be set to 0.  Warning
about such things seems like a bad idea.

This patch updates an earlier commit which would log a warning and
skip these endpoint descriptors.  Now we only log a warning, and we
don't even do that for isochronous endpoints in altsetting 0.

We don't need to worry about preventing endpoints with maxpacket = 0
from ever being used for data transfers; usb_submit_urb() already
checks for this.

Reported-and-tested-by: Roger Whittaker &lt;Roger.Whittaker@suse.com&gt;
Fixes: d482c7bb0541 ("USB: Skip endpoints with 0 maxpacket length")
Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
CC: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Link: https://marc.info/?l=linux-usb&amp;m=157790377329882&amp;w=2
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2001061040270.1514-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rtl8xxxu: prevent leaking urb</title>
<updated>2020-01-14T19:04:31+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-09-20T03:00:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c00bebd0b959fe8bec6d4a1a07010394b8008e4'/>
<id>urn:sha1:2c00bebd0b959fe8bec6d4a1a07010394b8008e4</id>
<content type='text'>
commit a2cdd07488e666aa93a49a3fc9c9b1299e27ef3c upstream.

In rtl8xxxu_submit_int_urb if usb_submit_urb fails the allocated urb
should be released.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Reviewed-by: Chris Chiu &lt;chiu@endlessm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: bfa: release allocated memory in case of error</title>
<updated>2020-01-14T19:04:31+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-09-10T23:44:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=78cb846f4aea6e20fc942d7bb8930107d1c6e34f'/>
<id>urn:sha1:78cb846f4aea6e20fc942d7bb8930107d1c6e34f</id>
<content type='text'>
commit 0e62395da2bd5166d7c9e14cbc7503b256a34cb0 upstream.

In bfad_im_get_stats if bfa_port_get_stats fails, allocated memory needs to
be released.

Link: https://lore.kernel.org/r/20190910234417.22151-1-navid.emamdoost@gmail.com
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mwifiex: pcie: Fix memory leak in mwifiex_pcie_alloc_cmdrsp_buf</title>
<updated>2020-01-14T19:04:30+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-10-04T20:08:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9bba4330671eaf1d21ac6025f950e7cca92f7aca'/>
<id>urn:sha1:9bba4330671eaf1d21ac6025f950e7cca92f7aca</id>
<content type='text'>
commit db8fd2cde93227e566a412cf53173ffa227998bc upstream.

In mwifiex_pcie_alloc_cmdrsp_buf, a new skb is allocated which should be
released if mwifiex_map_pci_memory() fails. The release is added.

Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Acked-by: Ganapathi Bhat &lt;gbhat@marvell.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mwifiex: fix possible heap overflow in mwifiex_process_country_ie()</title>
<updated>2020-01-14T19:04:30+00:00</updated>
<author>
<name>Ganapathi Bhat</name>
<email>gbhat@marvell.com</email>
</author>
<published>2019-11-21T16:04:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=efa99b6f3844bd20d46c8afd78f92a0161a4718e'/>
<id>urn:sha1:efa99b6f3844bd20d46c8afd78f92a0161a4718e</id>
<content type='text'>
commit 3d94a4a8373bf5f45cf5f939e88b8354dbf2311b upstream.

mwifiex_process_country_ie() function parse elements of bss
descriptor in beacon packet. When processing WLAN_EID_COUNTRY
element, there is no upper limit check for country_ie_len before
calling memcpy. The destination buffer domain_info-&gt;triplet is an
array of length MWIFIEX_MAX_TRIPLET_802_11D(83). The remote
attacker can build a fake AP with the same ssid as real AP, and
send malicous beacon packet with long WLAN_EID_COUNTRY elemen
(country_ie_len &gt; 83). Attacker can  force STA connect to fake AP
on a different channel. When the victim STA connects to fake AP,
will trigger the heap buffer overflow. Fix this by checking for
length and if found invalid, don not connect to the AP.

This fix addresses CVE-2019-14895.

Reported-by: huangwen &lt;huangwenabc@gmail.com&gt;
Signed-off-by: Ganapathi Bhat &lt;gbhat@marvell.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tty: always relink the port</title>
<updated>2020-01-14T19:04:30+00:00</updated>
<author>
<name>Sudip Mukherjee</name>
<email>sudipm.mukherjee@gmail.com</email>
</author>
<published>2019-12-27T17:44:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=017927206a69a109c0ecd4646c7b1cdd2883e4b5'/>
<id>urn:sha1:017927206a69a109c0ecd4646c7b1cdd2883e4b5</id>
<content type='text'>
commit 273f632912f1b24b642ba5b7eb5022e43a72f3b5 upstream.

If the serial device is disconnected and reconnected, it re-enumerates
properly but does not link it. fwiw, linking means just saving the port
index, so allow it always as there is no harm in saving the same value
again even if it tries to relink with the same port.

Fixes: fb2b90014d78 ("tty: link tty and port before configuring it as console")
Reported-by: Kenneth R. Crudup &lt;kenny@panix.com&gt;
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20191227174434.12057-1-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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