<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel, branch linux-4.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.4.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2022-02-03T08:27:54Z</updated>
<entry>
<title>Linux 4.4.302</title>
<updated>2022-02-03T08:27:54Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2022-02-03T08:27:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a09b2d8f61ea0e9ae735c400399b97966a9418d6'/>
<id>urn:sha1:a09b2d8f61ea0e9ae735c400399b97966a9418d6</id>
<content type='text'>
Link: https://lore.kernel.org/r/20220201180822.148370751@linuxfoundation.org
Tested-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Slade Watkins &lt;slade@sladewatkins.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Input: i8042 - Fix misplaced backport of "add ASUS Zenbook Flip to noselftest list"</title>
<updated>2022-02-03T08:27:54Z</updated>
<author>
<name>Guillaume Bertholon</name>
<email>guillaume.bertholon@ens.fr</email>
</author>
<published>2022-02-02T14:03:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0c4ba621fca224e6aa231c27e49f110b99c66ba2'/>
<id>urn:sha1:0c4ba621fca224e6aa231c27e49f110b99c66ba2</id>
<content type='text'>
The upstream commit b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to
noselftest list") inserted a new entry in the `i8042_dmi_noselftest_table`
table, further patched by commit daa58c8eec0a ("Input: i8042 - fix Pegatron
C15B ID entry") to insert a missing separator.

However, their backported version in stable (commit e480ccf433be
("Input: i8042 - add ASUS Zenbook Flip to noselftest list") and
commit 7444a4152ac3 ("Input: i8042 - fix Pegatron C15B ID entry"))
inserted this entry in `i8042_dmi_forcemux_table` instead.

This patch moves the entry back into `i8042_dmi_noselftest_table`.

Fixes: e480ccf433be ("Input: i8042 - add ASUS Zenbook Flip to noselftest list")
Signed-off-by: Guillaume Bertholon &lt;guillaume.bertholon@ens.fr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: x86: Fix misplaced backport of "work around leak of uninitialized stack contents"</title>
<updated>2022-02-03T08:27:54Z</updated>
<author>
<name>Guillaume Bertholon</name>
<email>guillaume.bertholon@ens.fr</email>
</author>
<published>2022-02-01T17:17:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=52060aa13c85ef1acb53f0498bfcdf22e129ef51'/>
<id>urn:sha1:52060aa13c85ef1acb53f0498bfcdf22e129ef51</id>
<content type='text'>
The upstream commit 541ab2aeb282 ("KVM: x86: work around leak of
uninitialized stack contents") resets `exception` in the function
`kvm_write_guest_virt_system`.
However, its backported version in stable (commit ba7f1c934f2e
("KVM: x86: work around leak of uninitialized stack contents")) applied
the change in `emulator_write_std` instead.

This patch moves the memset instruction back to
`kvm_write_guest_virt_system`.

Fixes: ba7f1c934f2e ("KVM: x86: work around leak of uninitialized stack contents")
Signed-off-by: Guillaume Bertholon &lt;guillaume.bertholon@ens.fr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "tc358743: fix register i2c_rd/wr function fix"</title>
<updated>2022-02-03T08:27:54Z</updated>
<author>
<name>Guillaume Bertholon</name>
<email>guillaume.bertholon@ens.fr</email>
</author>
<published>2022-02-01T17:14:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1fa3bfc12bebafed63f992ed206ae434c1736f0d'/>
<id>urn:sha1:1fa3bfc12bebafed63f992ed206ae434c1736f0d</id>
<content type='text'>
This reverts commit a3f9c74652c749486bf9e989caabcae6f68272ee.

The reverted commit was backported and applied twice on the stable branch:
- First as commit 44f3c2b6e5e9 ("tc358743: fix register i2c_rd/wr
  function fix") at the right position `i2c_wr8_and_or`
- Then as commit a3f9c74652c7 ("tc358743: fix register i2c_rd/wr
  function fix") on the wrong function `i2c_wr16_and_or`

Fixes: a3f9c74652c7 ("tc358743: fix register i2c_rd/wr function fix")
Signed-off-by: Guillaume Bertholon &lt;guillaume.bertholon@ens.fr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "drm/radeon/ci: disable mclk switching for high refresh rates (v2)"</title>
<updated>2022-02-03T08:27:53Z</updated>
<author>
<name>Guillaume Bertholon</name>
<email>guillaume.bertholon@ens.fr</email>
</author>
<published>2022-02-01T17:11:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=29a49f8e9cac916eaa0d1e97207a8ebcf10a885c'/>
<id>urn:sha1:29a49f8e9cac916eaa0d1e97207a8ebcf10a885c</id>
<content type='text'>
This reverts commit 0157e2a8a71978c58a7d6cfb3616ab17d9726631.

The reverted commit was backported and applied twice on the stable branch:
- First as commit 15de2e4c90b7 ("drm/radeon/ci: disable mclk switching for
high refresh rates (v2)")
- Then as commit 0157e2a8a719 ("drm/radeon/ci: disable mclk switching for
high refresh rates (v2)")

Fixes: 0157e2a8a719 ("drm/radeon/ci: disable mclk switching for high refresh rates (v2)")
Signed-off-by: Guillaume Bertholon &lt;guillaume.bertholon@ens.fr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: MGMT: Fix misplaced BT_HS check</title>
<updated>2022-02-03T08:27:53Z</updated>
<author>
<name>Guillaume Bertholon</name>
<email>guillaume.bertholon@ens.fr</email>
</author>
<published>2022-02-01T14:24:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bfd9dcb36526a86a3b00c3e0d72dcb306de970b2'/>
<id>urn:sha1:bfd9dcb36526a86a3b00c3e0d72dcb306de970b2</id>
<content type='text'>
The upstream commit b560a208cda0 ("Bluetooth: MGMT: Fix not checking if
BT_HS is enabled") inserted a new check in the `set_hs` function.
However, its backported version in stable (commit 5abe9f99f512
("Bluetooth: MGMT: Fix not checking if BT_HS is enabled")),
added the check in `set_link_security` instead.

This patch restores the intent of the upstream commit by moving back the
BT_HS check to `set_hs`.

Fixes: 5abe9f99f512 ("Bluetooth: MGMT: Fix not checking if BT_HS is enabled")
Signed-off-by: Guillaume Bertholon &lt;guillaume.bertholon@ens.fr&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ipv4: tcp: send zero IPID in SYNACK messages</title>
<updated>2022-02-03T08:27:53Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2022-01-27T01:10:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=07cf4e8ddac7203a9c8dfcf7cf978a9d95ce1112'/>
<id>urn:sha1:07cf4e8ddac7203a9c8dfcf7cf978a9d95ce1112</id>
<content type='text'>
[ Upstream commit 970a5a3ea86da637471d3cd04d513a0755aba4bf ]

In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and
ACK sent in SYN-RECV and TIME-WAIT state") we took care of some
ctl packets sent by TCP.

It turns out we need to use a similar strategy for SYNACK packets.

By default, they carry IP_DF and IPID==0, but there are ways
to ask them to use the hashed IP ident generator and thus
be used to build off-path attacks.
(Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)

One of this way is to force (before listener is started)
echo 1 &gt;/proc/sys/net/ipv4/ip_no_pmtu_disc

Another way is using forged ICMP ICMP_FRAG_NEEDED
with a very small MTU (like 68) to force a false return from
ip_dont_fragment()

In this patch, ip_build_and_send_pkt() uses the following
heuristics.

1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore
can use IP_DF regardless of the listener or route pmtu setting.

2) In case the SYNACK packet is bigger than IPV4_MIN_MTU,
we use prandom_u32() generator instead of the IPv4 hashed ident one.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Ray Che &lt;xijiache@gmail.com&gt;
Reviewed-by: David Ahern &lt;dsahern@kernel.org&gt;
Cc: Geoff Alexander &lt;alexandg@cs.unm.edu&gt;
Cc: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ipv4: raw: lock the socket in raw_bind()</title>
<updated>2022-02-03T08:27:53Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2022-01-27T00:51:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0ccf51399d55963b2a5d0a86468885c8efb9e7a4'/>
<id>urn:sha1:0ccf51399d55963b2a5d0a86468885c8efb9e7a4</id>
<content type='text'>
[ Upstream commit 153a0d187e767c68733b8e9f46218eb1f41ab902 ]

For some reason, raw_bind() forgot to lock the socket.

BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind

write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0:
 raw_bind+0x1b0/0x250 net/ipv4/raw.c:739
 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443
 __sys_bind+0x14b/0x1b0 net/socket.c:1697
 __do_sys_bind net/socket.c:1708 [inline]
 __se_sys_bind net/socket.c:1706 [inline]
 __x64_sys_bind+0x3d/0x50 net/socket.c:1706
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1:
 __ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39
 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89
 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576
 __sys_connect_file net/socket.c:1900 [inline]
 __sys_connect+0x197/0x1b0 net/socket.c:1917
 __do_sys_connect net/socket.c:1927 [inline]
 __se_sys_connect net/socket.c:1924 [inline]
 __x64_sys_connect+0x3d/0x50 net/socket.c:1924
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

value changed: 0x00000000 -&gt; 0x0003007f

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: syzbot &lt;syzkaller@googlegroups.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>hwmon: (lm90) Reduce maximum conversion rate for G781</title>
<updated>2022-02-03T08:27:53Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2022-01-06T19:48:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8e7d56781007beb5d9d9f2acff2df9fb631c0410'/>
<id>urn:sha1:8e7d56781007beb5d9d9f2acff2df9fb631c0410</id>
<content type='text'>
[ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ]

According to its datasheet, G781 supports a maximum conversion rate value
of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only
support a maximum conversion rate value of 7 (125 ms). On the other side,
chips labeled G781-1 and G784 were found to support a conversion rate value
of 8. There is no known means to distinguish G780 from G781 or G784; all
chips report the same manufacturer ID and chip revision.
Setting the conversion rate register value to 8 on chips not supporting
it causes unexpected behavior since the real conversion rate is set to 0
(16 seconds) if a value of 8 is written into the conversion rate register.
Limit the conversion rate register value to 7 for all G78x chips to avoid
the problem.

Fixes: ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781")
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/msm: Fix wrong size calculation</title>
<updated>2022-02-03T08:27:53Z</updated>
<author>
<name>Xianting Tian</name>
<email>xianting.tian@linux.alibaba.com</email>
</author>
<published>2022-01-12T12:33:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8700381f1200e257e08611808cf88dbbe757ed6c'/>
<id>urn:sha1:8700381f1200e257e08611808cf88dbbe757ed6c</id>
<content type='text'>
commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream.

For example, memory-region in .dts as below,
	reg = &lt;0x0 0x50000000 0x0 0x20000000&gt;

We can get below values,
struct resource r;
r.start = 0x50000000;
r.end	= 0x6fffffff;

So the size should be:
size = r.end - r.start + 1 = 0x20000000

Signed-off-by: Xianting Tian &lt;xianting.tian@linux.alibaba.com&gt;
Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://lore.kernel.org/r/20220112123334.749776-1-xianting.tian@linux.alibaba.com
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
