This is the start of the stable review cycle for the 4.9.265 release.
There are 35 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 Wed, 07 Apr 2021 08:50:09 +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.9.265-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.265-rc1
Paul Moore <[email protected]>
audit: fix a net reference leak in audit_list_rules_send()
Paul Moore <[email protected]>
audit: fix a net reference leak in audit_send_reply()
Atul Gopinathan <[email protected]>
staging: rtl8192e: Change state information from u16 to u8
Atul Gopinathan <[email protected]>
staging: rtl8192e: Fix incorrect source in memcpy()
Johan Hovold <[email protected]>
USB: cdc-acm: fix use-after-free after probe failure
Oliver Neukum <[email protected]>
USB: cdc-acm: downgrade message to debug
Oliver Neukum <[email protected]>
cdc-acm: fix BREAK rx code path adding necessary calls
Chunfeng Yun <[email protected]>
usb: xhci-mtk: fix broken streams issue on 0.96 xHCI
Vincent Palatin <[email protected]>
USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem
Zheyu Ma <[email protected]>
firewire: nosy: Fix a use-after-free bug in nosy_ioctl()
Dinghao Liu <[email protected]>
extcon: Fix error handling in extcon_dev_register
Wang Panzhenzhuan <[email protected]>
pinctrl: rockchip: fix restore error in resume
Tetsuo Handa <[email protected]>
reiserfs: update reiserfs_xattrs_initialized() condition
Ilya Lipnitskiy <[email protected]>
mm: fix race by making init_zero_pfn() early_initcall
Steven Rostedt (VMware) <[email protected]>
tracing: Fix stack trace event size
Hui Wang <[email protected]>
ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook
Ikjoon Jang <[email protected]>
ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
Jesper Dangaard Brouer <[email protected]>
bpf: Remove MTU check in __bpf_skb_max_len
Tong Zhang <[email protected]>
net: wan/lmc: unregister device when no matching device is found
Doug Brown <[email protected]>
appletalk: Fix skb allocation size in loopback case
zhangyi (F) <[email protected]>
ext4: do not iput inode under running transaction in ext4_rename()
Sameer Pujar <[email protected]>
ASoC: rt5659: Update MCLK rate in set_sysclk()
Tong Zhang <[email protected]>
staging: comedi: cb_pcidas64: fix request_irq() warn
Tong Zhang <[email protected]>
staging: comedi: cb_pcidas: fix request_irq() warn
Alexey Dobriyan <[email protected]>
scsi: qla2xxx: Fix broken #endif placement
Lv Yunlong <[email protected]>
scsi: st: Fix a use after free in st_open()
Laurent Vivier <[email protected]>
vhost: Fix vhost_vq_reset()
Christophe Leroy <[email protected]>
powerpc: Force inlining of cpu_has_feature() to avoid build failure
Benjamin Rood <[email protected]>
ASoC: sgtl5000: set DAP_AVC_CTRL register to correct default value on probe
Hans de Goede <[email protected]>
ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10
Hans de Goede <[email protected]>
ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10
J. Bruce Fields <[email protected]>
rpc: fix NULL dereference on kmalloc failure
Zhaolong Zhang <[email protected]>
ext4: fix bh ref count on error paths
Jakub Kicinski <[email protected]>
ipv6: weaken the v4mapped source check
David Brazdil <[email protected]>
selinux: vsock: Set SID for socket returned by accept()
-------------
Diffstat:
Makefile | 4 +--
arch/powerpc/include/asm/cpu_has_feature.h | 4 +--
drivers/extcon/extcon.c | 1 +
drivers/firewire/nosy.c | 9 ++++--
drivers/net/wan/lmc/lmc_main.c | 2 ++
drivers/pinctrl/pinctrl-rockchip.c | 13 +++++---
drivers/scsi/qla2xxx/qla_target.h | 2 +-
drivers/scsi/st.c | 2 +-
drivers/staging/comedi/drivers/cb_pcidas.c | 2 +-
drivers/staging/comedi/drivers/cb_pcidas64.c | 2 +-
drivers/staging/rtl8192e/rtllib.h | 2 +-
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
drivers/usb/class/cdc-acm.c | 12 +++++--
drivers/usb/core/quirks.c | 4 +++
drivers/usb/host/xhci-mtk.c | 10 +++++-
drivers/vhost/vhost.c | 2 +-
fs/ext4/inode.c | 6 ++--
fs/ext4/namei.c | 18 +++++------
fs/reiserfs/xattr.h | 2 +-
kernel/audit.c | 48 +++++++++++++++++-----------
kernel/audit.h | 2 +-
kernel/auditfilter.c | 13 ++++----
kernel/trace/trace.c | 3 +-
mm/memory.c | 2 +-
net/appletalk/ddp.c | 33 ++++++++++++-------
net/core/filter.c | 7 ++--
net/dccp/ipv6.c | 5 +++
net/ipv6/ip6_input.c | 10 ------
net/ipv6/tcp_ipv6.c | 5 +++
net/sunrpc/auth_gss/svcauth_gss.c | 11 ++++---
net/vmw_vsock/af_vsock.c | 1 +
sound/pci/hda/patch_realtek.c | 1 +
sound/soc/codecs/rt5640.c | 4 +--
sound/soc/codecs/rt5651.c | 4 +--
sound/soc/codecs/rt5659.c | 5 +++
sound/soc/codecs/sgtl5000.c | 2 +-
sound/usb/quirks.c | 1 +
37 files changed, 157 insertions(+), 99 deletions(-)
From: Ilya Lipnitskiy <[email protected]>
commit e720e7d0e983bf05de80b231bccc39f1487f0f16 upstream.
There are code paths that rely on zero_pfn to be fully initialized
before core_initcall. For example, wq_sysfs_init() is a core_initcall
function that eventually results in a call to kernel_execve, which
causes a page fault with a subsequent mmput. If zero_pfn is not
initialized by then it may not get cleaned up properly and result in an
error:
BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1
Here is an analysis of the race as seen on a MIPS device. On this
particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until
initialized, at which point it becomes PFN 5120:
1. wq_sysfs_init calls into kobject_uevent_env at core_initcall:
kobject_uevent_env+0x7e4/0x7ec
kset_register+0x68/0x88
bus_register+0xdc/0x34c
subsys_virtual_register+0x34/0x78
wq_sysfs_init+0x1c/0x4c
do_one_initcall+0x50/0x1a8
kernel_init_freeable+0x230/0x2c8
kernel_init+0x10/0x100
ret_from_kernel_thread+0x14/0x1c
2. kobject_uevent_env() calls call_usermodehelper_exec() which executes
kernel_execve asynchronously.
3. Memory allocations in kernel_execve cause a page fault, bumping the
MM reference counter:
add_mm_counter_fast+0xb4/0xc0
handle_mm_fault+0x6e4/0xea0
__get_user_pages.part.78+0x190/0x37c
__get_user_pages_remote+0x128/0x360
get_arg_page+0x34/0xa0
copy_string_kernel+0x194/0x2a4
kernel_execve+0x11c/0x298
call_usermodehelper_exec_async+0x114/0x194
4. In case zero_pfn has not been initialized yet, zap_pte_range does
not decrement the MM_ANONPAGES RSS counter and the BUG message is
triggered shortly afterwards when __mmdrop checks the ref counters:
__mmdrop+0x98/0x1d0
free_bprm+0x44/0x118
kernel_execve+0x160/0x1d8
call_usermodehelper_exec_async+0x114/0x194
ret_from_kernel_thread+0x14/0x1c
To avoid races such as described above, initialize init_zero_pfn at
early_initcall level. Depending on the architecture, ZERO_PAGE is
either constant or gets initialized even earlier, at paging_init, so
there is no issue with initializing zero_pfn earlier.
Link: https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niAXOpqEbt7w@mail.gmail.com
Signed-off-by: Ilya Lipnitskiy <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: [email protected]
Tested-by: 周琰杰 (Zhou Yanjie) <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -132,7 +132,7 @@ static int __init init_zero_pfn(void)
zero_pfn = page_to_pfn(ZERO_PAGE(0));
return 0;
}
-core_initcall(init_zero_pfn);
+early_initcall(init_zero_pfn);
#if defined(SPLIT_RSS_COUNTING)
From: Vincent Palatin <[email protected]>
commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd upstream.
This LTE modem (M.2 card) has a bug in its power management:
there is some kind of race condition for U3 wake-up between the host and
the device. The modem firmware sometimes crashes/locks when both events
happen at the same time and the modem fully drops off the USB bus (and
sometimes re-enumerates, sometimes just gets stuck until the next
reboot).
Tested with the modem wired to the XHCI controller on an AMD 3015Ce
platform. Without the patch, the modem dropped of the USB bus 5 times in
3 days. With the quirk, it stayed connected for a week while the
'runtime_suspended_time' counter incremented as excepted.
Signed-off-by: Vincent Palatin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/quirks.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -321,6 +321,10 @@ static const struct usb_device_id usb_qu
/* DJI CineSSD */
{ USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM },
+ /* Fibocom L850-GL LTE Modem */
+ { USB_DEVICE(0x2cb7, 0x0007), .driver_info =
+ USB_QUIRK_IGNORE_REMOTE_WAKEUP },
+
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
From: Dinghao Liu <[email protected]>
[ Upstream commit d3bdd1c3140724967ca4136755538fa7c05c2b4e ]
When devm_kcalloc() fails, we should execute device_unregister()
to unregister edev->dev from system.
Fixes: 046050f6e623e ("extcon: Update the prototype of extcon_register_notifier() with enum extcon")
Signed-off-by: Dinghao Liu <[email protected]>
Signed-off-by: Chanwoo Choi <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/extcon/extcon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index d0e367959c91..20e24d4b917a 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1200,6 +1200,7 @@ int extcon_dev_register(struct extcon_dev *edev)
sizeof(*edev->nh) * edev->max_supported, GFP_KERNEL);
if (!edev->nh) {
ret = -ENOMEM;
+ device_unregister(&edev->dev);
goto err_dev;
}
--
2.30.2
From: Hans de Goede <[email protected]>
[ Upstream commit cfa26ed1f9f885c2fd8f53ca492989d1e16d0199 ]
The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB,
not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace
apps which translate the dB scale to a linear scale. With the logarithmic
dB scale being of by a factor of 10 we loose all precision in the lower
area of the range when apps translate things to a linear scale.
E.g. the 0 dB default, which corresponds with a value of 47 of the
0 - 127 range for the control, would be shown as 0/100 in alsa-mixer.
Since the centi-dB values used in the TLV struct cannot represent the
0.375 dB step size used by these controls, change the TLV definition
for them to specify a min and max value instead of min + stepsize.
Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc-
vol-tlv values being off by a factor of 10") which made the exact same
change to the rt5670 codec driver.
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
sound/soc/codecs/rt5640.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c
index 3cc1135fc2cd..81fbbcaf8121 100644
--- a/sound/soc/codecs/rt5640.c
+++ b/sound/soc/codecs/rt5640.c
@@ -341,9 +341,9 @@ static bool rt5640_readable_register(struct device *dev, unsigned int reg)
}
static const DECLARE_TLV_DB_SCALE(out_vol_tlv, -4650, 150, 0);
-static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -65625, 375, 0);
+static const DECLARE_TLV_DB_MINMAX(dac_vol_tlv, -6562, 0);
static const DECLARE_TLV_DB_SCALE(in_vol_tlv, -3450, 150, 0);
-static const DECLARE_TLV_DB_SCALE(adc_vol_tlv, -17625, 375, 0);
+static const DECLARE_TLV_DB_MINMAX(adc_vol_tlv, -1762, 3000);
static const DECLARE_TLV_DB_SCALE(adc_bst_tlv, 0, 1200, 0);
/* {0, +20, +24, +30, +35, +40, +44, +50, +52} dB */
--
2.30.1
From: Atul Gopinathan <[email protected]>
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 bytes of data using memcpy():
(In rtllib_rx.c:1972)
memcpy(network->CcxRmState, &info_element->data[4], 2)
With "info_element->data[]" being a u8 array, if 2 bytes are written
into "CcxRmState" (whose one element is u16 size), then the 2 u8
elements from "data[]" gets squashed and written into the first element
("CcxRmState[0]") while the second element ("CcxRmState[1]") is never
fed with any data.
Same in file rtllib_rx.c:2522:
memcpy(dst->CcxRmState, src->CcxRmState, 2);
The above line duplicates "src" data to "dst" but only writes 2 bytes
(and not 4, which is the actual size). Again, only 1st element gets the
value while the 2nd element remains uninitialized.
This later makes operations done with CcxRmState unpredictable in the
following lines as the 1st element is having a squashed number while the
2nd element is having an uninitialized random number.
rtllib_rx.c:1973: if (network->CcxRmState[0] != 0)
rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07;
network->MBssidMask is also of type u8 and not u16.
Fix this by changing the type of "CcxRmState" from u16 to u8 so that the
data written into this array and read from it make sense and are not
random values.
NOTE: The wrong initialization of "CcxRmState" can be seen in the
following commit:
commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")
The above commit created a file `rtl8192e/ieee80211.h` which used to
have the faulty line. The file has been deleted (or possibly renamed)
with the contents copied in to a new file `rtl8192e/rtllib.h` along with
additional code in the commit 94a799425eee (tagged in Fixes).
Fixes: 94a799425eee ("From: wlanfae <[email protected]> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
Cc: [email protected]
Signed-off-by: Atul Gopinathan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rtl8192e/rtllib.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1160,7 +1160,7 @@ struct rtllib_network {
bool bWithAironetIE;
bool bCkipSupported;
bool bCcxRmEnable;
- u16 CcxRmState[2];
+ u8 CcxRmState[2];
bool bMBssidValid;
u8 MBssidMask;
u8 MBssid[ETH_ALEN];
From: Paul Moore <[email protected]>
commit a48b284b403a4a073d8beb72d2bb33e54df67fb6 upstream.
If audit_send_reply() fails when trying to create a new thread to
send the reply it also fails to cleanup properly, leaking a reference
to a net structure. This patch fixes the error path and makes a
handful of other cleanups that came up while fixing the code.
Reported-by: [email protected]
Reviewed-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Cc: <[email protected]> # 4.9.x
Signed-off-by: Wen Yang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/audit.c | 46 ++++++++++++++++++++++++++++------------------
1 file changed, 28 insertions(+), 18 deletions(-)
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -580,6 +580,18 @@ out_kfree_skb:
return NULL;
}
+static void audit_free_reply(struct audit_reply *reply)
+{
+ if (!reply)
+ return;
+
+ if (reply->skb)
+ kfree_skb(reply->skb);
+ if (reply->net)
+ put_net(reply->net);
+ kfree(reply);
+}
+
static int audit_send_reply_thread(void *arg)
{
struct audit_reply *reply = (struct audit_reply *)arg;
@@ -592,8 +604,8 @@ static int audit_send_reply_thread(void
/* Ignore failure. It'll only happen if the sender goes away,
because our timeout is set to infinite. */
netlink_unicast(aunet->nlsk , reply->skb, reply->portid, 0);
- put_net(net);
- kfree(reply);
+ reply->skb = NULL;
+ audit_free_reply(reply);
return 0;
}
/**
@@ -606,36 +618,34 @@ static int audit_send_reply_thread(void
* @payload: payload data
* @size: payload size
*
- * Allocates an skb, builds the netlink message, and sends it to the port id.
- * No failure notifications.
+ * Allocates a skb, builds the netlink message, and sends it to the port id.
*/
static void audit_send_reply(struct sk_buff *request_skb, int seq, int type, int done,
int multi, const void *payload, int size)
{
u32 portid = NETLINK_CB(request_skb).portid;
- struct net *net = sock_net(NETLINK_CB(request_skb).sk);
- struct sk_buff *skb;
struct task_struct *tsk;
- struct audit_reply *reply = kmalloc(sizeof(struct audit_reply),
- GFP_KERNEL);
+ struct audit_reply *reply;
+ reply = kzalloc(sizeof(*reply), GFP_KERNEL);
if (!reply)
return;
- skb = audit_make_reply(portid, seq, type, done, multi, payload, size);
- if (!skb)
- goto out;
+ reply->skb = audit_make_reply(portid, seq, type, done, multi, payload, size);
+ if (!reply->skb)
+ goto err;
- reply->net = get_net(net);
+ reply->net = get_net(sock_net(NETLINK_CB(request_skb).sk));
reply->portid = portid;
- reply->skb = skb;
tsk = kthread_run(audit_send_reply_thread, reply, "audit_send_reply");
- if (!IS_ERR(tsk))
- return;
- kfree_skb(skb);
-out:
- kfree(reply);
+ if (IS_ERR(tsk))
+ goto err;
+
+ return;
+
+err:
+ audit_free_reply(reply);
}
/*
From: Paul Moore <[email protected]>
commit 3054d06719079388a543de6adb812638675ad8f5 upstream.
If audit_list_rules_send() fails when trying to create a new thread
to send the rules it also fails to cleanup properly, leaking a
reference to a net structure. This patch fixes the error patch and
renames audit_send_list() to audit_send_list_thread() to better
match its cousin, audit_send_reply_thread().
Reported-by: [email protected]
Reviewed-by: Richard Guy Briggs <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Cc: <[email protected]> # 4.9.x
Signed-off-by: Wen Yang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/audit.c | 2 +-
kernel/audit.h | 2 +-
kernel/auditfilter.c | 13 ++++++-------
3 files changed, 8 insertions(+), 9 deletions(-)
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -535,7 +535,7 @@ static int kauditd_thread(void *dummy)
return 0;
}
-int audit_send_list(void *_dest)
+int audit_send_list_thread(void *_dest)
{
struct audit_netlink_list *dest = _dest;
struct sk_buff *skb;
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -245,7 +245,7 @@ struct audit_netlink_list {
struct sk_buff_head q;
};
-int audit_send_list(void *);
+int audit_send_list_thread(void *);
struct audit_net {
struct sock *nlsk;
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1139,10 +1139,8 @@ int audit_rule_change(int type, __u32 po
int audit_list_rules_send(struct sk_buff *request_skb, int seq)
{
u32 portid = NETLINK_CB(request_skb).portid;
- struct net *net = sock_net(NETLINK_CB(request_skb).sk);
struct task_struct *tsk;
struct audit_netlink_list *dest;
- int err = 0;
/* We can't just spew out the rules here because we might fill
* the available socket buffer space and deadlock waiting for
@@ -1150,10 +1148,10 @@ int audit_list_rules_send(struct sk_buff
* happen if we're actually running in the context of auditctl
* trying to _send_ the stuff */
- dest = kmalloc(sizeof(struct audit_netlink_list), GFP_KERNEL);
+ dest = kmalloc(sizeof(*dest), GFP_KERNEL);
if (!dest)
return -ENOMEM;
- dest->net = get_net(net);
+ dest->net = get_net(sock_net(NETLINK_CB(request_skb).sk));
dest->portid = portid;
skb_queue_head_init(&dest->q);
@@ -1161,14 +1159,15 @@ int audit_list_rules_send(struct sk_buff
audit_list_rules(portid, seq, &dest->q);
mutex_unlock(&audit_filter_mutex);
- tsk = kthread_run(audit_send_list, dest, "audit_send_list");
+ tsk = kthread_run(audit_send_list_thread, dest, "audit_send_list");
if (IS_ERR(tsk)) {
skb_queue_purge(&dest->q);
+ put_net(dest->net);
kfree(dest);
- err = PTR_ERR(tsk);
+ return PTR_ERR(tsk);
}
- return err;
+ return 0;
}
int audit_comparator(u32 left, u32 op, u32 right)
From: Atul Gopinathan <[email protected]>
commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream.
The variable "info_element" is of the following type:
struct rtllib_info_element *info_element
defined in drivers/staging/rtl8192e/rtllib.h:
struct rtllib_info_element {
u8 id;
u8 len;
u8 data[];
} __packed;
The "len" field defines the size of the "data[]" array. The code is
supposed to check if "info_element->len" is greater than 4 and later
equal to 6. If this is satisfied then, the last two bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_element" has a size of 2 bytes for "id" and "len",
therefore indexing will be done in interval of 2 bytes. So,
"info_element[4]" would point to data which is beyond the memory
allocated for this pointer (that is, at x+8, while "info_element" has
been allocated only from x to x+7 (2 + 6 => 8 bytes)).
This patch rectifies this error by using "&info_element->data[4]" which
correctly copies the last two bytes of "data[]".
NOTE: The faulty line of code came from the following commit:
commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")
The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c`
which had the faulty line of code. This file has been deleted (or
possibly renamed) with the contents copied in to a new file
`rtl8192e/rtllib_rx.c` along with additional code in the commit
94a799425eee (tagged in Fixes).
Fixes: 94a799425eee ("From: wlanfae <[email protected]> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
Cc: [email protected]
Signed-off-by: Atul Gopinathan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -1986,7 +1986,7 @@ static void rtllib_parse_mife_generic(st
info_element->data[2] == 0x96 &&
info_element->data[3] == 0x01) {
if (info_element->len == 6) {
- memcpy(network->CcxRmState, &info_element[4], 2);
+ memcpy(network->CcxRmState, &info_element->data[4], 2);
if (network->CcxRmState[0] != 0)
network->bCcxRmEnable = true;
else
On 4/5/2021 1:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.265 release.
> There are 35 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 Wed, 07 Apr 2021 08:50:09 +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.9.265-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB, using 32-bit and 64-bit kernels:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.265 release.
> There are 35 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 Wed, 07 Apr 2021 08:50:09 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 163 pass: 163 fail: 0
Qemu test results:
total: 383 pass: 382 fail: 1
Failed tests:
parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
In the failing test, the network interfcace instantiates but fails to get
an IP address. This is not a new problem but a new test. For some reason
it only happens with this specific network interface, this specific SCSI
controller, and with v4.9.y. No reason for concern; I'll try to track down
what is going on.
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.265 release.
> > There are 35 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 Wed, 07 Apr 2021 08:50:09 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 163 pass: 163 fail: 0
> Qemu test results:
> total: 383 pass: 382 fail: 1
> Failed tests:
> parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
>
> In the failing test, the network interfcace instantiates but fails to get
> an IP address. This is not a new problem but a new test. For some reason
> it only happens with this specific network interface, this specific SCSI
> controller, and with v4.9.y. No reason for concern; I'll try to track down
> what is going on.
>
Interesting. The problem affects all kernels up to and including
v4.19.y. Unlike I thought initially, the problem is not associated
with the SCSI controller (that was coincidental) but with pcnet
Ethernet interfaces. It has been fixed in the upstream kernel with
commit 518a2f1925c3 ("dma-mapping: zero memory returned from
dma_alloc_*"). This patch does not apply cleanly to any of the
affected kernels. I backported part of it to v4.19.y and v4.9.y
and confirmed that it fixes the problem in those branches.
Question is what we should do: try to backport 518a2f1925c3 to v4.19.y
and earlier, or stop testing against this specific problem.
Any thoughts ?
Thanks,
Guenter
On 4/5/21 2:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.265 release.
> There are 35 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 Wed, 07 Apr 2021 08:50:09 +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.9.265-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.9.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
On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
> > On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.9.265 release.
> > > There are 35 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 Wed, 07 Apr 2021 08:50:09 +0000.
> > > Anything received after that time might be too late.
> > >
> >
> > Build results:
> > total: 163 pass: 163 fail: 0
> > Qemu test results:
> > total: 383 pass: 382 fail: 1
> > Failed tests:
> > parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
> >
> > In the failing test, the network interfcace instantiates but fails to get
> > an IP address. This is not a new problem but a new test. For some reason
> > it only happens with this specific network interface, this specific SCSI
> > controller, and with v4.9.y. No reason for concern; I'll try to track down
> > what is going on.
> >
>
> Interesting. The problem affects all kernels up to and including
> v4.19.y. Unlike I thought initially, the problem is not associated
> with the SCSI controller (that was coincidental) but with pcnet
> Ethernet interfaces. It has been fixed in the upstream kernel with
> commit 518a2f1925c3 ("dma-mapping: zero memory returned from
> dma_alloc_*"). This patch does not apply cleanly to any of the
> affected kernels. I backported part of it to v4.19.y and v4.9.y
> and confirmed that it fixes the problem in those branches.
>
> Question is what we should do: try to backport 518a2f1925c3 to v4.19.y
> and earlier, or stop testing against this specific problem.
>
Another update: The following code change fixes the problem as well.
Commit 518a2f1925c3 fixes it only as side effect since it clears
all DMA buffers.
diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c
index c22bf52d3320..7a25ec8390e4 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name)
return -ENOMEM;
}
- lp->rx_ring = pci_alloc_consistent(lp->pci_dev,
+ lp->rx_ring = pci_zalloc_consistent(lp->pci_dev,
sizeof(struct pcnet32_rx_head) *
lp->rx_ring_size,
&lp->rx_ring_dma_addr);
I'll submit a patch implementing that; we'll see how it goes.
Thanks,
Guenter
On Mon, Apr 05, 2021 at 07:22:00PM -0700, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
> > On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
> > > On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.9.265 release.
> > > > There are 35 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 Wed, 07 Apr 2021 08:50:09 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > >
> > > Build results:
> > > total: 163 pass: 163 fail: 0
> > > Qemu test results:
> > > total: 383 pass: 382 fail: 1
> > > Failed tests:
> > > parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
> > >
> > > In the failing test, the network interfcace instantiates but fails to get
> > > an IP address. This is not a new problem but a new test. For some reason
> > > it only happens with this specific network interface, this specific SCSI
> > > controller, and with v4.9.y. No reason for concern; I'll try to track down
> > > what is going on.
> > >
> >
> > Interesting. The problem affects all kernels up to and including
> > v4.19.y. Unlike I thought initially, the problem is not associated
> > with the SCSI controller (that was coincidental) but with pcnet
> > Ethernet interfaces. It has been fixed in the upstream kernel with
> > commit 518a2f1925c3 ("dma-mapping: zero memory returned from
> > dma_alloc_*"). This patch does not apply cleanly to any of the
> > affected kernels. I backported part of it to v4.19.y and v4.9.y
> > and confirmed that it fixes the problem in those branches.
> >
> > Question is what we should do: try to backport 518a2f1925c3 to v4.19.y
> > and earlier, or stop testing against this specific problem.
> >
>
> Another update: The following code change fixes the problem as well.
> Commit 518a2f1925c3 fixes it only as side effect since it clears
> all DMA buffers.
>
> diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c
> index c22bf52d3320..7a25ec8390e4 100644
> --- a/drivers/net/ethernet/amd/pcnet32.c
> +++ b/drivers/net/ethernet/amd/pcnet32.c
> @@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name)
> return -ENOMEM;
> }
>
> - lp->rx_ring = pci_alloc_consistent(lp->pci_dev,
> + lp->rx_ring = pci_zalloc_consistent(lp->pci_dev,
> sizeof(struct pcnet32_rx_head) *
> lp->rx_ring_size,
> &lp->rx_ring_dma_addr);
>
> I'll submit a patch implementing that; we'll see how it goes.
Sigh. That doesn't work; upstream uses dma_alloc_coherent().
We could apply the patch making the switch, but dma_alloc_coherent()
doesn't clear memory in older kernels (we are back to commit 518a2f1925c3
which is introducing that). I'll just drop pcnet tests for kernels older
than v5.4.
Guenter
On Mon, 5 Apr 2021 at 14:27, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.9.265 release.
> There are 35 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 Wed, 07 Apr 2021 08:50:09 +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.9.265-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.9.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.9.265-rc1
* git: ['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git',
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
* git branch: linux-4.9.y
* git commit: 570fbad9f4ca61dfb49359b9c2627a97e41e2b4b
* git describe: v4.9.264-36-g570fbad9f4ca
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.264-36-g570fbad9f4ca
## No regressions (compared to v4.9.264-25-gea8146018e96)
## No fixes (compared to v4.9.264-25-gea8146018e96)
## Test result summary
total: 58777, pass: 48253, fail: 593, skip: 9676, xfail: 255,
## Build Summary
* arm: 96 total, 96 passed, 0 failed
* arm64: 23 total, 23 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 13 total, 13 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 36 total, 36 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 13 total, 13 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* 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-lkdtm
* 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
* perf
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
On Mon, Apr 05, 2021 at 07:36:02PM -0700, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 07:22:00PM -0700, Guenter Roeck wrote:
> > On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
> > > On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
> > > > On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.9.265 release.
> > > > > There are 35 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 Wed, 07 Apr 2021 08:50:09 +0000.
> > > > > Anything received after that time might be too late.
> > > > >
> > > >
> > > > Build results:
> > > > total: 163 pass: 163 fail: 0
> > > > Qemu test results:
> > > > total: 383 pass: 382 fail: 1
> > > > Failed tests:
> > > > parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
> > > >
> > > > In the failing test, the network interfcace instantiates but fails to get
> > > > an IP address. This is not a new problem but a new test. For some reason
> > > > it only happens with this specific network interface, this specific SCSI
> > > > controller, and with v4.9.y. No reason for concern; I'll try to track down
> > > > what is going on.
> > > >
> > >
> > > Interesting. The problem affects all kernels up to and including
> > > v4.19.y. Unlike I thought initially, the problem is not associated
> > > with the SCSI controller (that was coincidental) but with pcnet
> > > Ethernet interfaces. It has been fixed in the upstream kernel with
> > > commit 518a2f1925c3 ("dma-mapping: zero memory returned from
> > > dma_alloc_*"). This patch does not apply cleanly to any of the
> > > affected kernels. I backported part of it to v4.19.y and v4.9.y
> > > and confirmed that it fixes the problem in those branches.
> > >
> > > Question is what we should do: try to backport 518a2f1925c3 to v4.19.y
> > > and earlier, or stop testing against this specific problem.
> > >
> >
> > Another update: The following code change fixes the problem as well.
> > Commit 518a2f1925c3 fixes it only as side effect since it clears
> > all DMA buffers.
> >
> > diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c
> > index c22bf52d3320..7a25ec8390e4 100644
> > --- a/drivers/net/ethernet/amd/pcnet32.c
> > +++ b/drivers/net/ethernet/amd/pcnet32.c
> > @@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name)
> > return -ENOMEM;
> > }
> >
> > - lp->rx_ring = pci_alloc_consistent(lp->pci_dev,
> > + lp->rx_ring = pci_zalloc_consistent(lp->pci_dev,
> > sizeof(struct pcnet32_rx_head) *
> > lp->rx_ring_size,
> > &lp->rx_ring_dma_addr);
> >
> > I'll submit a patch implementing that; we'll see how it goes.
>
> Sigh. That doesn't work; upstream uses dma_alloc_coherent().
> We could apply the patch making the switch, but dma_alloc_coherent()
> doesn't clear memory in older kernels (we are back to commit 518a2f1925c3
> which is introducing that). I'll just drop pcnet tests for kernels older
> than v5.4.
If the patch above fixes this in the older kernel versions, I'm all for
taking it if needed.
thanks,
greg k-h