<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.19.196</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.196</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.196'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-06-30T13:18:40+00:00</updated>
<entry>
<title>Linux 4.19.196</title>
<updated>2021-06-30T13:18:40+00:00</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2021-06-30T13:18:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9f84340f012ee60c12aacc03662bcdd67419a31a'/>
<id>urn:sha1:9f84340f012ee60c12aacc03662bcdd67419a31a</id>
<content type='text'>
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Hulk Robot &lt;hulkrobot@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: robotfuzz-osif: fix control-request directions</title>
<updated>2021-06-30T12:48:34+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2021-05-24T09:09:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f376dd8a409fe4cca5b121cd7c42b894689aada6'/>
<id>urn:sha1:f376dd8a409fe4cca5b121cd7c42b894689aada6</id>
<content type='text'>
commit 4ca070ef0dd885616ef294d269a9bf8e3b258e1a upstream.

The direction of the pipe argument must match the request-type direction
bit or control requests may fail depending on the host-controller-driver
implementation.

Control transfers without a data stage are treated as OUT requests by
the USB stack and should be using usb_sndctrlpipe(). Failing to do so
will now trigger a warning.

Fix the OSIFI2C_SET_BIT_RATE and OSIFI2C_STOP requests which erroneously
used the osif_usb_read() helper and set the IN direction bit.

Reported-by: syzbot+9d7dadd15b8819d73f41@syzkaller.appspotmail.com
Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.")
Cc: stable@vger.kernel.org      # 3.14
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>nilfs2: fix memory leak in nilfs_sysfs_delete_device_group</title>
<updated>2021-06-30T12:48:34+00:00</updated>
<author>
<name>Pavel Skripkin</name>
<email>paskripkin@gmail.com</email>
</author>
<published>2021-06-25T01:39:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9436cdffaf5bc83f41e72dfbd4d9ec885ff7b4f2'/>
<id>urn:sha1:9436cdffaf5bc83f41e72dfbd4d9ec885ff7b4f2</id>
<content type='text'>
[ Upstream commit 8fd0c1b0647a6bda4067ee0cd61e8395954b6f28 ]

My local syzbot instance hit memory leak in nilfs2.  The problem was in
missing kobject_put() in nilfs_sysfs_delete_device_group().

kobject_del() does not call kobject_cleanup() for passed kobject and it
leads to leaking duped kobject name if kobject_put() was not called.

Fail log:

  BUG: memory leak
  unreferenced object 0xffff8880596171e0 (size 8):
  comm "syz-executor379", pid 8381, jiffies 4294980258 (age 21.100s)
  hex dump (first 8 bytes):
    6c 6f 6f 70 30 00 00 00                          loop0...
  backtrace:
     kstrdup+0x36/0x70 mm/util.c:60
     kstrdup_const+0x53/0x80 mm/util.c:83
     kvasprintf_const+0x108/0x190 lib/kasprintf.c:48
     kobject_set_name_vargs+0x56/0x150 lib/kobject.c:289
     kobject_add_varg lib/kobject.c:384 [inline]
     kobject_init_and_add+0xc9/0x160 lib/kobject.c:473
     nilfs_sysfs_create_device_group+0x150/0x800 fs/nilfs2/sysfs.c:999
     init_nilfs+0xe26/0x12b0 fs/nilfs2/the_nilfs.c:637

Link: https://lkml.kernel.org/r/20210612140559.20022-1-paskripkin@gmail.com
Fixes: da7141fb78db ("nilfs2: add /sys/fs/nilfs2/&lt;device&gt; group")
Signed-off-by: Pavel Skripkin &lt;paskripkin@gmail.com&gt;
Acked-by: Ryusuke Konishi &lt;konishi.ryusuke@gmail.com&gt;
Cc: Michael L. Semon &lt;mlsemon35@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: stm32: fix the reported number of GPIO lines per bank</title>
<updated>2021-06-30T12:48:34+00:00</updated>
<author>
<name>Fabien Dessenne</name>
<email>fabien.dessenne@foss.st.com</email>
</author>
<published>2021-06-17T14:46:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fde184840c38e235620931895c8d121fa37bb4f8'/>
<id>urn:sha1:fde184840c38e235620931895c8d121fa37bb4f8</id>
<content type='text'>
[ Upstream commit 67e2996f72c71ebe4ac2fcbcf77e54479bb7aa11 ]

Each GPIO bank supports a variable number of lines which is usually 16, but
is less in some cases : this is specified by the last argument of the
"gpio-ranges" bank node property.
Report to the framework, the actual number of lines, so the libgpiod
gpioinfo command lists the actually existing GPIO lines.

Fixes: 1dc9d289154b ("pinctrl: stm32: add possibility to use gpio-ranges to declare bank range")
Signed-off-by: Fabien Dessenne &lt;fabien.dessenne@foss.st.com&gt;
Link: https://lore.kernel.org/r/20210617144629.2557693-1-fabien.dessenne@foss.st.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY</title>
<updated>2021-06-30T12:48:33+00:00</updated>
<author>
<name>Esben Haabendal</name>
<email>esben@geanix.com</email>
</author>
<published>2021-06-18T10:52:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a5ccdf780c934efd5fbc41a717a998362d76c004'/>
<id>urn:sha1:a5ccdf780c934efd5fbc41a717a998362d76c004</id>
<content type='text'>
[ Upstream commit f6396341194234e9b01cd7538bc2c6ac4501ab14 ]

As documented in Documentation/networking/driver.rst, the ndo_start_xmit
method must not return NETDEV_TX_BUSY under any normal circumstances, and
as recommended, we simply stop the tx queue in advance, when there is a
risk that the next xmit would cause a NETDEV_TX_BUSY return.

Signed-off-by: Esben Haabendal &lt;esben@geanix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI: Add AMD RS690 quirk to enable 64-bit DMA</title>
<updated>2021-06-30T12:48:33+00:00</updated>
<author>
<name>Mikel Rychliski</name>
<email>mikel@mikelr.com</email>
</author>
<published>2021-06-11T21:48:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=987c6da9b2f4ba5a74545477c740178e06c2da45'/>
<id>urn:sha1:987c6da9b2f4ba5a74545477c740178e06c2da45</id>
<content type='text'>
[ Upstream commit cacf994a91d3a55c0c2f853d6429cd7b86113915 ]

Although the AMD RS690 chipset has 64-bit DMA support, BIOS implementations
sometimes fail to configure the memory limit registers correctly.

The Acer F690GVM mainboard uses this chipset and a Marvell 88E8056 NIC. The
sky2 driver programs the NIC to use 64-bit DMA, which will not work:

  sky2 0000:02:00.0: error interrupt status=0x8
  sky2 0000:02:00.0 eth0: tx timeout
  sky2 0000:02:00.0 eth0: transmit ring 0 .. 22 report=0 done=0

Other drivers required by this mainboard either don't support 64-bit DMA,
or have it disabled using driver specific quirks. For example, the ahci
driver has quirks to enable or disable 64-bit DMA depending on the BIOS
version (see ahci_sb600_enable_64bit() in ahci.c). This ahci quirk matches
against the SB600 SATA controller, but the real issue is almost certainly
with the RS690 PCI host that it was commonly attached to.

To avoid this issue in all drivers with 64-bit DMA support, fix the
configuration of the PCI host. If the kernel is aware of physical memory
above 4GB, but the BIOS never configured the PCI host with this
information, update the registers with our values.

[bhelgaas: drop PCI_DEVICE_ID_ATI_RS690 definition]
Link: https://lore.kernel.org/r/20210611214823.4898-1-mikel@mikelr.com
Signed-off-by: Mikel Rychliski &lt;mikel@mikelr.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: qed: Fix memcpy() overflow of qed_dcbx_params()</title>
<updated>2021-06-30T12:48:33+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2021-06-17T17:09:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=144ca5c30c7a97d0c37c404c157db1b1358e2fcf'/>
<id>urn:sha1:144ca5c30c7a97d0c37c404c157db1b1358e2fcf</id>
<content type='text'>
[ Upstream commit 1c200f832e14420fa770193f9871f4ce2df00d07 ]

The source (&amp;dcbx_info-&gt;operational.params) and dest
(&amp;p_hwfn-&gt;p_dcbx_info-&gt;set.config.params) are both struct qed_dcbx_params
(560 bytes), not struct qed_dcbx_admin_params (564 bytes), which is used
as the memcpy() size.

However it seems that struct qed_dcbx_operational_params
(dcbx_info-&gt;operational)'s layout matches struct qed_dcbx_admin_params
(p_hwfn-&gt;p_dcbx_info-&gt;set.config)'s 4 byte difference (3 padding, 1 byte
for "valid").

On the assumption that the size is wrong (rather than the source structure
type), adjust the memcpy() size argument to be 4 bytes smaller and add
a BUILD_BUG_ON() to validate any changes to the structure sizes.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: selftests: Fix kvm_check_cap() assertion</title>
<updated>2021-06-30T12:48:32+00:00</updated>
<author>
<name>Fuad Tabba</name>
<email>tabba@google.com</email>
</author>
<published>2021-06-15T15:04:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=df084ef4de987d870eb958ce2e1ae97f6251109a'/>
<id>urn:sha1:df084ef4de987d870eb958ce2e1ae97f6251109a</id>
<content type='text'>
[ Upstream commit d8ac05ea13d789d5491a5920d70a05659015441d ]

KVM_CHECK_EXTENSION ioctl can return any negative value on error,
and not necessarily -1. Change the assertion to reflect that.

Signed-off-by: Fuad Tabba &lt;tabba@google.com&gt;
Message-Id: &lt;20210615150443.1183365-1-tabba@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>r8169: Avoid memcpy() over-reading of ETH_SS_STATS</title>
<updated>2021-06-30T12:48:32+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2021-06-16T19:53:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4e42da589e76ca071366fce0f30b87d4ba6d02e'/>
<id>urn:sha1:e4e42da589e76ca071366fce0f30b87d4ba6d02e</id>
<content type='text'>
[ Upstream commit da5ac772cfe2a03058b0accfac03fad60c46c24d ]

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally reading across neighboring array fields.

The memcpy() is copying the entire structure, not just the first array.
Adjust the source argument so the compiler can do appropriate bounds
checking.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sh_eth: Avoid memcpy() over-reading of ETH_SS_STATS</title>
<updated>2021-06-30T12:48:32+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2021-06-16T19:53:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cb59801bd8edd96b6e4e563ccb968e6ba002b57'/>
<id>urn:sha1:7cb59801bd8edd96b6e4e563ccb968e6ba002b57</id>
<content type='text'>
[ Upstream commit 224004fbb033600715dbd626bceec10bfd9c58bc ]

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally reading across neighboring array fields.

The memcpy() is copying the entire structure, not just the first array.
Adjust the source argument so the compiler can do appropriate bounds
checking.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
