NOTE! This is the proposed LAST 4.4.y kernel release to happen under
the rules of the normal stable kernel releases. After this one, it will
be marked End-Of-Life as it has been 6 years and you really should know
better by now and have moved to a newer kernel tree. After this one, no
more security fixes will be backported and you will end up with an
insecure system over time.
--------------------------
This is the start of the stable review cycle for the 4.4.302 release.
There are 25 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.302-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.302-rc1
Guillaume Bertholon <[email protected]>
KVM: x86: Fix misplaced backport of "work around leak of uninitialized stack contents"
Guillaume Bertholon <[email protected]>
Revert "tc358743: fix register i2c_rd/wr function fix"
Guillaume Bertholon <[email protected]>
Revert "drm/radeon/ci: disable mclk switching for high refresh rates (v2)"
Guillaume Bertholon <[email protected]>
Bluetooth: MGMT: Fix misplaced BT_HS check
Eric Dumazet <[email protected]>
ipv4: tcp: send zero IPID in SYNACK messages
Eric Dumazet <[email protected]>
ipv4: raw: lock the socket in raw_bind()
Guenter Roeck <[email protected]>
hwmon: (lm90) Reduce maximum conversion rate for G781
Xianting Tian <[email protected]>
drm/msm: Fix wrong size calculation
Jianguo Wu <[email protected]>
net-procfs: show net devices bound packet types
Eric Dumazet <[email protected]>
ipv4: avoid using shared IP generator for connected sockets
Congyu Liu <[email protected]>
net: fix information leakage in /proc/net/ptype
Ido Schimmel <[email protected]>
ipv6_tunnel: Rate limit warning messages
John Meneghini <[email protected]>
scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()
Alan Stern <[email protected]>
USB: core: Fix hang in usb_kill_urb by adding memory barriers
Alan Stern <[email protected]>
usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge
Cameron Williams <[email protected]>
tty: Add support for Brainboxes UC cards.
[email protected] <[email protected]>
tty: n_gsm: fix SW flow control encoding/handling
Valentin Caron <[email protected]>
serial: stm32: fix software flow control transfer
Greg Kroah-Hartman <[email protected]>
PM: wakeup: simplify the output logic of pm_show_wakelocks()
Jan Kara <[email protected]>
udf: Fix NULL ptr deref when converting from inline format
Jan Kara <[email protected]>
udf: Restore i_lenAlloc when inode expansion fails
Steffen Maier <[email protected]>
scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices
Vasily Gorbik <[email protected]>
s390/hypfs: include z/VM guests with access control group set
Brian Gix <[email protected]>
Bluetooth: refactor malicious adv data check
Ziyang Xuan <[email protected]>
can: bcm: fix UAF of bcm op
-------------
Diffstat:
Makefile | 4 +-
arch/s390/hypfs/hypfs_vm.c | 6 ++-
arch/x86/kvm/x86.c | 14 +++---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
drivers/gpu/drm/radeon/ci_dpm.c | 6 ---
drivers/hwmon/lm90.c | 2 +-
drivers/media/i2c/tc358743.c | 2 +-
drivers/s390/scsi/zfcp_fc.c | 13 ++++-
drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 20 ++------
drivers/tty/n_gsm.c | 4 +-
drivers/tty/serial/8250/8250_pci.c | 100 ++++++++++++++++++++++++++++++++++++-
drivers/tty/serial/stm32-usart.c | 2 +-
drivers/usb/core/hcd.c | 14 ++++++
drivers/usb/core/urb.c | 12 +++++
drivers/usb/storage/unusual_devs.h | 10 ++++
fs/udf/inode.c | 9 ++--
include/linux/netdevice.h | 1 +
include/net/ip.h | 21 ++++----
kernel/power/wakelock.c | 12 ++---
net/bluetooth/hci_event.c | 10 ++--
net/bluetooth/mgmt.c | 8 +--
net/can/bcm.c | 20 ++++----
net/core/net-procfs.c | 38 ++++++++++++--
net/ipv4/ip_output.c | 11 +++-
net/ipv4/raw.c | 5 +-
net/ipv6/ip6_tunnel.c | 8 +--
net/packet/af_packet.c | 2 +
27 files changed, 262 insertions(+), 94 deletions(-)
On Tue, Feb 01, 2022 at 07:16:24PM +0100, Greg Kroah-Hartman wrote:
> NOTE! This is the proposed LAST 4.4.y kernel release to happen under
> the rules of the normal stable kernel releases. After this one, it will
> be marked End-Of-Life as it has been 6 years and you really should know
> better by now and have moved to a newer kernel tree. After this one, no
> more security fixes will be backported and you will end up with an
> insecure system over time.
>
> --------------------------
>
> This is the start of the stable review cycle for the 4.4.302 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 160 pass: 160 fail: 0
Qemu test results:
total: 342 pass: 342 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On 2/1/22 11:16 AM, Greg Kroah-Hartman wrote:
> NOTE! This is the proposed LAST 4.4.y kernel release to happen under
> the rules of the normal stable kernel releases. After this one, it will
> be marked End-Of-Life as it has been 6 years and you really should know
> better by now and have moved to a newer kernel tree. After this one, no
> more security fixes will be backported and you will end up with an
> insecure system over time.
>
> --------------------------
>
> This is the start of the stable review cycle for the 4.4.302 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.302-rc1.gz
Couldn't find the patch. Didn't get pushed perhaps.
thanks,
-- Shuah
From: Eric Dumazet <[email protected]>
commit 23f57406b82de51809d5812afd96f210f8b627f3 upstream.
ip_select_ident_segs() has been very conservative about using
the connected socket private generator only for packets with IP_DF
set, claiming it was needed for some VJ compression implementations.
As mentioned in this referenced document, this can be abused.
(Ref: Off-Path TCP Exploits of the Mixed IPID Assignment)
Before switching to pure random IPID generation and possibly hurt
some workloads, lets use the private inet socket generator.
Not only this will remove one vulnerability, this will also
improve performance of TCP flows using pmtudisc==IP_PMTUDISC_DONT
Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count")
Signed-off-by: Eric Dumazet <[email protected]>
Reviewed-by: David Ahern <[email protected]>
Reported-by: Ray Che <[email protected]>
Cc: Willy Tarreau <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/net/ip.h | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -353,19 +353,18 @@ static inline void ip_select_ident_segs(
{
struct iphdr *iph = ip_hdr(skb);
+ /* We had many attacks based on IPID, use the private
+ * generator as much as we can.
+ */
+ if (sk && inet_sk(sk)->inet_daddr) {
+ iph->id = htons(inet_sk(sk)->inet_id);
+ inet_sk(sk)->inet_id += segs;
+ return;
+ }
if ((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) {
- /* This is only to work around buggy Windows95/2000
- * VJ compression implementations. If the ID field
- * does not change, they drop every other packet in
- * a TCP stream using header compression.
- */
- if (sk && inet_sk(sk)->inet_daddr) {
- iph->id = htons(inet_sk(sk)->inet_id);
- inet_sk(sk)->inet_id += segs;
- } else {
- iph->id = 0;
- }
+ iph->id = 0;
} else {
+ /* Unfortunately we need the big hammer to get a suitable IPID */
__ip_select_ident(net, iph, segs);
}
}
From: Alan Stern <[email protected]>
commit 5b67b315037250a61861119683e7fcb509deea25 upstream.
Two people have reported (and mentioned numerous other reports on the
web) that VIA's VL817 USB-SATA bridge does not work with the uas
driver. Typical log messages are:
[ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD
[ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00
[ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd
[ 3606.328584] scsi host14: uas_eh_device_reset_handler success
Surprisingly, the devices do seem to work okay for some other people.
The cause of the differing behaviors is not known.
In the hope of getting the devices to work for the most users, even at
the possible cost of degraded performance for some, this patch adds an
unusual_devs entry for the VL817 to block it from binding to the uas
driver by default. Users will be able to override this entry by means
of a module parameter, if they want.
CC: <[email protected]>
Reported-by: DocMAX <[email protected]>
Reported-and-tested-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Alan Stern <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/unusual_devs.h | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2155,6 +2155,16 @@ UNUSUAL_DEV( 0x2027, 0xa001, 0x0000, 0x
USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init,
US_FL_SCM_MULT_TARG ),
+/*
+ * Reported by DocMAX <[email protected]>
+ * and Thomas Weißschuh <[email protected]>
+ */
+UNUSUAL_DEV( 0x2109, 0x0715, 0x9999, 0x9999,
+ "VIA Labs, Inc.",
+ "VL817 SATA Bridge",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_IGNORE_UAS),
+
UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001,
"ST",
"2A",
From: Jianguo Wu <[email protected]>
commit 1d10f8a1f40b965d449e8f2d5ed7b96a7c138b77 upstream.
After commit:7866a621043f ("dev: add per net_device packet type chains"),
we can not get packet types that are bound to a specified net device by
/proc/net/ptype, this patch fix the regression.
Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch:
Before:
[root@localhost ~]# cat /proc/net/ptype
Type Device Function
0800 ip_rcv
0806 arp_rcv
86dd ipv6_rcv
After:
[root@localhost ~]# cat /proc/net/ptype
Type Device Function
ALL ens192 tpacket_rcv
0800 ip_rcv
0806 arp_rcv
86dd ipv6_rcv
v1 -> v2:
- fix the regression rather than adding new /proc API as
suggested by Stephen Hemminger.
Fixes: 7866a621043f ("dev: add per net_device packet type chains")
Signed-off-by: Jianguo Wu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/net-procfs.c | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
--- a/net/core/net-procfs.c
+++ b/net/core/net-procfs.c
@@ -207,12 +207,23 @@ static const struct file_operations soft
.release = seq_release,
};
-static void *ptype_get_idx(loff_t pos)
+static void *ptype_get_idx(struct seq_file *seq, loff_t pos)
{
+ struct list_head *ptype_list = NULL;
struct packet_type *pt = NULL;
+ struct net_device *dev;
loff_t i = 0;
int t;
+ for_each_netdev_rcu(seq_file_net(seq), dev) {
+ ptype_list = &dev->ptype_all;
+ list_for_each_entry_rcu(pt, ptype_list, list) {
+ if (i == pos)
+ return pt;
+ ++i;
+ }
+ }
+
list_for_each_entry_rcu(pt, &ptype_all, list) {
if (i == pos)
return pt;
@@ -233,22 +244,40 @@ static void *ptype_seq_start(struct seq_
__acquires(RCU)
{
rcu_read_lock();
- return *pos ? ptype_get_idx(*pos - 1) : SEQ_START_TOKEN;
+ return *pos ? ptype_get_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
+ struct net_device *dev;
struct packet_type *pt;
struct list_head *nxt;
int hash;
++*pos;
if (v == SEQ_START_TOKEN)
- return ptype_get_idx(0);
+ return ptype_get_idx(seq, 0);
pt = v;
nxt = pt->list.next;
+ if (pt->dev) {
+ if (nxt != &pt->dev->ptype_all)
+ goto found;
+
+ dev = pt->dev;
+ for_each_netdev_continue_rcu(seq_file_net(seq), dev) {
+ if (!list_empty(&dev->ptype_all)) {
+ nxt = dev->ptype_all.next;
+ goto found;
+ }
+ }
+
+ nxt = ptype_all.next;
+ goto ptype_all;
+ }
+
if (pt->type == htons(ETH_P_ALL)) {
+ptype_all:
if (nxt != &ptype_all)
goto found;
hash = 0;
From: Xianting Tian <[email protected]>
commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream.
For example, memory-region in .dts as below,
reg = <0x0 0x50000000 0x0 0x20000000>
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 <[email protected]>
Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem")
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -286,7 +286,7 @@ static int msm_init_vram(struct drm_devi
ret = of_address_to_resource(node, 0, &r);
if (ret)
return ret;
- size = r.end - r.start;
+ size = r.end - r.start + 1;
DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start);
} else
#endif
From: Congyu Liu <[email protected]>
commit 47934e06b65637c88a762d9c98329ae6e3238888 upstream.
In one net namespace, after creating a packet socket without binding
it to a device, users in other net namespaces can observe the new
`packet_type` added by this packet socket by reading `/proc/net/ptype`
file. This is minor information leakage as packet socket is
namespace aware.
Add a net pointer in `packet_type` to keep the net namespace of
of corresponding packet socket. In `ptype_seq_show`, this net pointer
must be checked when it is not NULL.
Fixes: 2feb27dbe00c ("[NETNS]: Minor information leak via /proc/net/ptype file.")
Signed-off-by: Congyu Liu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/linux/netdevice.h | 1 +
net/core/net-procfs.c | 3 ++-
net/packet/af_packet.c | 2 ++
3 files changed, 5 insertions(+), 1 deletion(-)
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2055,6 +2055,7 @@ struct packet_type {
struct net_device *);
bool (*id_match)(struct packet_type *ptype,
struct sock *sk);
+ struct net *af_packet_net;
void *af_packet_priv;
struct list_head list;
};
--- a/net/core/net-procfs.c
+++ b/net/core/net-procfs.c
@@ -277,7 +277,8 @@ static int ptype_seq_show(struct seq_fil
if (v == SEQ_START_TOKEN)
seq_puts(seq, "Type Device Function\n");
- else if (pt->dev == NULL || dev_net(pt->dev) == seq_file_net(seq)) {
+ else if ((!pt->af_packet_net || net_eq(pt->af_packet_net, seq_file_net(seq))) &&
+ (!pt->dev || net_eq(dev_net(pt->dev), seq_file_net(seq)))) {
if (pt->type == htons(ETH_P_ALL))
seq_puts(seq, "ALL ");
else
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1709,6 +1709,7 @@ static int fanout_add(struct sock *sk, u
match->prot_hook.dev = po->prot_hook.dev;
match->prot_hook.func = packet_rcv_fanout;
match->prot_hook.af_packet_priv = match;
+ match->prot_hook.af_packet_net = read_pnet(&match->net);
match->prot_hook.id_match = match_fanout_group;
list_add(&match->list, &fanout_list);
}
@@ -3167,6 +3168,7 @@ static int packet_create(struct net *net
po->prot_hook.func = packet_rcv_spkt;
po->prot_hook.af_packet_priv = sk;
+ po->prot_hook.af_packet_net = sock_net(sk);
if (proto) {
po->prot_hook.type = proto;
On Tue, Feb 1, 2022 at 1:17 PM Greg Kroah-Hartman
<[email protected]> wrote:
>
> NOTE! This is the proposed LAST 4.4.y kernel release to happen under
> the rules of the normal stable kernel releases. After this one, it will
> be marked End-Of-Life as it has been 6 years and you really should know
> better by now and have moved to a newer kernel tree. After this one, no
> more security fixes will be backported and you will end up with an
> insecure system over time.
>
> --------------------------
>
> This is the start of the stable review cycle for the 4.4.302 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
> Anything received after that time might be too late.
>
First time testing the kernel like this, but I was able to compile and
boot on my x86_64 test system with no regressions.
Tested-by: Slade Watkins <[email protected]>
(Feel free to let me know if I can't send my Tested-by to you.)
All the best,
Slade
--
Slade Watkins <[email protected]>
From: Eric Dumazet <[email protected]>
[ 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 >/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 <[email protected]>
Reported-by: Ray Che <[email protected]>
Reviewed-by: David Ahern <[email protected]>
Cc: Geoff Alexander <[email protected]>
Cc: Willy Tarreau <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
net/ipv4/ip_output.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -155,12 +155,19 @@ int ip_build_and_send_pkt(struct sk_buff
iph->daddr = (opt && opt->opt.srr ? opt->opt.faddr : daddr);
iph->saddr = saddr;
iph->protocol = sk->sk_protocol;
- if (ip_dont_fragment(sk, &rt->dst)) {
+ /* Do not bother generating IPID for small packets (eg SYNACK) */
+ if (skb->len <= IPV4_MIN_MTU || ip_dont_fragment(sk, &rt->dst)) {
iph->frag_off = htons(IP_DF);
iph->id = 0;
} else {
iph->frag_off = 0;
- __ip_select_ident(net, iph, 1);
+ /* TCP packets here are SYNACK with fat IPv4/TCP options.
+ * Avoid using the hashed IP ident generator.
+ */
+ if (sk->sk_protocol == IPPROTO_TCP)
+ iph->id = (__force __be16)prandom_u32();
+ else
+ __ip_select_ident(net, iph, 1);
}
if (opt && opt->opt.optlen) {
From: Guenter Roeck <[email protected]>
[ 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 <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hwmon/lm90.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index 420f341272621..6f6f173aca6f2 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -265,7 +265,7 @@ static const struct lm90_params lm90_params[] = {
.flags = LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT
| LM90_HAVE_BROKEN_ALERT,
.alert_alarms = 0x7c,
- .max_convrate = 8,
+ .max_convrate = 7,
},
[lm86] = {
.flags = LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT,
--
2.34.1
From: Guillaume Bertholon <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/i2c/tc358743.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -241,7 +241,7 @@ static void i2c_wr16(struct v4l2_subdev
static void i2c_wr16_and_or(struct v4l2_subdev *sd, u16 reg, u16 mask, u16 val)
{
- i2c_wrreg(sd, reg, (i2c_rdreg(sd, reg, 1) & mask) | val, 1);
+ i2c_wrreg(sd, reg, (i2c_rdreg(sd, reg, 2) & mask) | val, 2);
}
static u32 i2c_rd32(struct v4l2_subdev *sd, u16 reg)
On Tue, 1 Feb 2022 at 23:47, Greg Kroah-Hartman
<[email protected]> wrote:
>
> NOTE! This is the proposed LAST 4.4.y kernel release to happen under
> the rules of the normal stable kernel releases. After this one, it will
> be marked End-Of-Life as it has been 6 years and you really should know
> better by now and have moved to a newer kernel tree. After this one, no
> more security fixes will be backported and you will end up with an
> insecure system over time.
>
> --------------------------
>
> This is the start of the stable review cycle for the 4.4.302 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.302-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
## Build
* kernel: 4.4.302-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.4.y
* git commit: 806b2893e0101bdff3ead10f038759a025f73557
* git describe: v4.4.301-26-g806b2893e010
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.301-26-g806b2893e010
## Test Regressions (compared to v4.4.299-114-g37c6a274092f)
No test regressions found.
## Metric Regressions (compared to v4.4.299-114-g37c6a274092f)
No metric regressions found.
## Test Fixes (compared to v4.4.299-114-g37c6a274092f)
No test fixes found.
## Metric Fixes (compared to v4.4.299-114-g37c6a274092f)
No metric fixes found.
## Test result summary
total: 55060, pass: 44792, fail: 242, skip: 8710, xfail: 1316
## Build Summary
* arm: 258 total, 258 passed, 0 failed
* arm64: 62 total, 62 passed, 0 failed
* i386: 35 total, 35 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 44 total, 44 passed, 0 failed
* sparc: 24 total, 24 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 2 total, 1 passed, 1 failed
* x86_64: 60 total, 48 passed, 12 failed
## Test suites summary
* fwts
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
On 2/1/22 11:16 AM, Greg Kroah-Hartman wrote:
> NOTE! This is the proposed LAST 4.4.y kernel release to happen under
> the rules of the normal stable kernel releases. After this one, it will
> be marked End-Of-Life as it has been 6 years and you really should know
> better by now and have moved to a newer kernel tree. After this one, no
> more security fixes will be backported and you will end up with an
> insecure system over time.
>
> --------------------------
>
> This is the start of the stable review cycle for the 4.4.302 release.
> There are 25 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.302-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
From: Guillaume Bertholon <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/x86.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4417,13 +4417,6 @@ static int emulator_write_std(struct x86
if (!system && kvm_x86_ops->get_cpl(vcpu) == 3)
access |= PFERR_USER_MASK;
- /*
- * FIXME: this should call handle_emulation_failure if X86EMUL_IO_NEEDED
- * is returned, but our callers are not ready for that and they blindly
- * call kvm_inject_page_fault. Ensure that they at least do not leak
- * uninitialized kernel stack memory into cr2 and error code.
- */
- memset(exception, 0, sizeof(*exception));
return kvm_write_guest_virt_helper(addr, val, bytes, vcpu,
access, exception);
}
@@ -4431,6 +4424,13 @@ static int emulator_write_std(struct x86
int kvm_write_guest_virt_system(struct kvm_vcpu *vcpu, gva_t addr, void *val,
unsigned int bytes, struct x86_exception *exception)
{
+ /*
+ * FIXME: this should call handle_emulation_failure if X86EMUL_IO_NEEDED
+ * is returned, but our callers are not ready for that and they blindly
+ * call kvm_inject_page_fault. Ensure that they at least do not leak
+ * uninitialized kernel stack memory into cr2 and error code.
+ */
+ memset(exception, 0, sizeof(*exception));
return kvm_write_guest_virt_helper(addr, val, bytes, vcpu,
PFERR_WRITE_MASK, exception);
}
On 2/1/22 12:46 PM, Shuah Khan wrote:
> On 2/1/22 11:16 AM, Greg Kroah-Hartman wrote:
>> NOTE! This is the proposed LAST 4.4.y kernel release to happen under
>> the rules of the normal stable kernel releases. After this one, it will
>> be marked End-Of-Life as it has been 6 years and you really should know
>> better by now and have moved to a newer kernel tree. After this one, no
>> more security fixes will be backported and you will end up with an
>> insecure system over time.
>>
>> --------------------------
>>
>> This is the start of the stable review cycle for the 4.4.302 release.
>> There are 25 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Thu, 03 Feb 2022 18:08:10 +0000.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.302-rc1.gz
>
> Couldn't find the patch. Didn't get pushed perhaps.
>
Found it. All set.
thanks,
-- Shuah
From: Valentin Caron <[email protected]>
commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream.
x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty.
Fix start_tx condition to allow x_char to be sent.
Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
Cc: stable <[email protected]>
Signed-off-by: Erwan Le Ray <[email protected]>
Signed-off-by: Valentin Caron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/stm32-usart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -279,7 +279,7 @@ static void stm32_start_tx(struct uart_p
{
struct circ_buf *xmit = &port->state->xmit;
- if (uart_circ_empty(xmit))
+ if (uart_circ_empty(xmit) && !port->x_char)
return;
stm32_set_bits(port, USART_CR1, USART_CR1_TXEIE | USART_CR1_TE);
From: Guillaume Bertholon <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/ci_dpm.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -782,12 +782,6 @@ bool ci_dpm_vblank_too_short(struct rade
if (r600_dpm_get_vrefresh(rdev) > 120)
return true;
- /* disable mclk switching if the refresh is >120Hz, even if the
- * blanking period would allow it
- */
- if (r600_dpm_get_vrefresh(rdev) > 120)
- return true;
-
if (vblank_time < switch_limit)
return true;
else
From: Guillaume Bertholon <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/bluetooth/mgmt.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2285,10 +2285,6 @@ static int set_link_security(struct sock
BT_DBG("request for %s", hdev->name);
- if (!IS_ENABLED(CONFIG_BT_HS))
- return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS,
- MGMT_STATUS_NOT_SUPPORTED);
-
status = mgmt_bredr_support(hdev);
if (status)
return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_LINK_SECURITY,
@@ -2438,6 +2434,10 @@ static int set_hs(struct sock *sk, struc
BT_DBG("request for %s", hdev->name);
+ if (!IS_ENABLED(CONFIG_BT_HS))
+ return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS,
+ MGMT_STATUS_NOT_SUPPORTED);
+
status = mgmt_bredr_support(hdev);
if (status)
return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, status);
From: Brian Gix <[email protected]>
commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream.
Check for out-of-bound read was being performed at the end of while
num_reports loop, and would fill journal with false positives. Added
check to beginning of loop processing so that it doesn't get checked
after ptr has been advanced.
Signed-off-by: Brian Gix <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: syphyr <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/bluetooth/hci_event.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4940,6 +4940,11 @@ static void hci_le_adv_report_evt(struct
struct hci_ev_le_advertising_info *ev = ptr;
s8 rssi;
+ if (ptr > (void *)skb_tail_pointer(skb) - sizeof(*ev)) {
+ bt_dev_err(hdev, "Malicious advertising data.");
+ break;
+ }
+
if (ev->length <= HCI_MAX_AD_LENGTH &&
ev->data + ev->length <= skb_tail_pointer(skb)) {
rssi = ev->data[ev->length];
@@ -4951,11 +4956,6 @@ static void hci_le_adv_report_evt(struct
}
ptr += sizeof(*ev) + ev->length + 1;
-
- if (ptr > (void *) skb_tail_pointer(skb) - sizeof(*ev)) {
- bt_dev_err(hdev, "Malicious advertising data. Stopping processing");
- break;
- }
}
hci_dev_unlock(hdev);