* [PATCH 5.10 01/38] nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 02/38] net: ipv6: fix skb_over_panic in __ip6_append_data Greg Kroah-Hartman
` (45 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jordy Zomer, Krzysztof Kozlowski,
David S. Miller, Denis Efremov
From: Jordy Zomer <jordy@pwning.systems>
commit 4fbcc1a4cb20fe26ad0225679c536c80f1648221 upstream.
It appears that there are some buffer overflows in EVT_TRANSACTION.
This happens because the length parameters that are passed to memcpy
come directly from skb->data and are not guarded in any way.
Signed-off-by: Jordy Zomer <jordy@pwning.systems>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Denis Efremov <denis.e.efremov@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nfc/st21nfca/se.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -320,6 +320,11 @@ int st21nfca_connectivity_event_received
return -ENOMEM;
transaction->aid_len = skb->data[1];
+
+ /* Checking if the length of the AID is valid */
+ if (transaction->aid_len > sizeof(transaction->aid))
+ return -EINVAL;
+
memcpy(transaction->aid, &skb->data[2],
transaction->aid_len);
@@ -329,6 +334,11 @@ int st21nfca_connectivity_event_received
return -EPROTO;
transaction->params_len = skb->data[transaction->aid_len + 3];
+
+ /* Total size is allocated (skb->len - 2) minus fixed array members */
+ if (transaction->params_len > ((skb->len - 2) - sizeof(struct nfc_evt_transaction)))
+ return -EINVAL;
+
memcpy(transaction->params, skb->data +
transaction->aid_len + 4, transaction->params_len);
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 02/38] net: ipv6: fix skb_over_panic in __ip6_append_data
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 01/38] nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 03/38] exfat: avoid incorrectly releasing for root inode Greg Kroah-Hartman
` (44 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+e223cf47ec8ae183f2a0,
Tadeusz Struk, Willem de Bruijn, Jakub Kicinski
From: Tadeusz Struk <tadeusz.struk@linaro.org>
commit 5e34af4142ffe68f01c8a9acae83300f8911e20c upstream.
Syzbot found a kernel bug in the ipv6 stack:
LINK: https://syzkaller.appspot.com/bug?id=205d6f11d72329ab8d62a610c44c5e7e25415580
The reproducer triggers it by sending a crafted message via sendmmsg()
call, which triggers skb_over_panic, and crashes the kernel:
skbuff: skb_over_panic: text:ffffffff84647fb4 len:65575 put:65575
head:ffff888109ff0000 data:ffff888109ff0088 tail:0x100af end:0xfec0
dev:<NULL>
Update the check that prevents an invalid packet with MTU equal
to the fregment header size to eat up all the space for payload.
The reproducer can be found here:
LINK: https://syzkaller.appspot.com/text?tag=ReproC&x=1648c83fb00000
Reported-by: syzbot+e223cf47ec8ae183f2a0@syzkaller.appspotmail.com
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Acked-by: Willem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/r/20220310232538.1044947-1-tadeusz.struk@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_output.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1500,8 +1500,8 @@ static int __ip6_append_data(struct sock
sizeof(struct frag_hdr) : 0) +
rt->rt6i_nfheader_len;
- if (mtu < fragheaderlen ||
- ((mtu - fragheaderlen) & ~7) + fragheaderlen < sizeof(struct frag_hdr))
+ if (mtu <= fragheaderlen ||
+ ((mtu - fragheaderlen) & ~7) + fragheaderlen <= sizeof(struct frag_hdr))
goto emsgsize;
maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen -
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 03/38] exfat: avoid incorrectly releasing for root inode
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 01/38] nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 02/38] net: ipv6: fix skb_over_panic in __ip6_append_data Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 04/38] cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv Greg Kroah-Hartman
` (43 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chen Li, Namjae Jeon, Tadeusz Struk
From: Chen Li <chenli@uniontech.com>
commit 839a534f1e853f1aec100d06040c0037b89c2dc3 upstream.
In d_make_root, when we fail to allocate dentry for root inode,
we will iput root inode and returned value is NULL in this function.
So we do not need to release this inode again at d_make_root's caller.
Signed-off-by: Chen Li <chenli@uniontech.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/exfat/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/exfat/super.c
+++ b/fs/exfat/super.c
@@ -690,7 +690,7 @@ static int exfat_fill_super(struct super
if (!sb->s_root) {
exfat_err(sb, "failed to get the root dentry");
err = -ENOMEM;
- goto put_inode;
+ goto free_table;
}
return 0;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 04/38] cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 03/38] exfat: avoid incorrectly releasing for root inode Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 05/38] cgroup: Use open-time cgroup namespace for process migration perm checks Greg Kroah-Hartman
` (42 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tejun Heo, Linus Torvalds,
Michal Koutný
From: Tejun Heo <tj@kernel.org>
commit 0d2b5955b36250a9428c832664f2079cbf723bec upstream.
of->priv is currently used by each interface file implementation to store
private information. This patch collects the current two private data usages
into struct cgroup_file_ctx which is allocated and freed by the common path.
This allows generic private data which applies to multiple files, which will
be used to in the following patch.
Note that cgroup_procs iterator is now embedded as procs.iter in the new
cgroup_file_ctx so that it doesn't need to be allocated and freed
separately.
v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in
cgroup_file_ctx as suggested by Linus.
v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too.
Converted. Didn't change to embedded allocation as cgroup1 pidlists get
stored for caching.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Michal Koutný <mkoutny@suse.com>
[mkoutny: v5.10: modify cgroup.pressure handlers, adjust context]
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup-internal.h | 17 ++++++++++++
kernel/cgroup/cgroup-v1.c | 26 ++++++++++---------
kernel/cgroup/cgroup.c | 54 +++++++++++++++++++++++++---------------
3 files changed, 65 insertions(+), 32 deletions(-)
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -65,6 +65,23 @@ static inline struct cgroup_fs_context *
return container_of(kfc, struct cgroup_fs_context, kfc);
}
+struct cgroup_pidlist;
+
+struct cgroup_file_ctx {
+ struct {
+ void *trigger;
+ } psi;
+
+ struct {
+ bool started;
+ struct css_task_iter iter;
+ } procs;
+
+ struct {
+ struct cgroup_pidlist *pidlist;
+ } procs1;
+};
+
/*
* A cgroup can be associated with multiple css_sets as different tasks may
* belong to different cgroups on different hierarchies. In the other
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -393,6 +393,7 @@ static void *cgroup_pidlist_start(struct
* next pid to display, if any
*/
struct kernfs_open_file *of = s->private;
+ struct cgroup_file_ctx *ctx = of->priv;
struct cgroup *cgrp = seq_css(s)->cgroup;
struct cgroup_pidlist *l;
enum cgroup_filetype type = seq_cft(s)->private;
@@ -402,25 +403,24 @@ static void *cgroup_pidlist_start(struct
mutex_lock(&cgrp->pidlist_mutex);
/*
- * !NULL @of->priv indicates that this isn't the first start()
- * after open. If the matching pidlist is around, we can use that.
- * Look for it. Note that @of->priv can't be used directly. It
- * could already have been destroyed.
+ * !NULL @ctx->procs1.pidlist indicates that this isn't the first
+ * start() after open. If the matching pidlist is around, we can use
+ * that. Look for it. Note that @ctx->procs1.pidlist can't be used
+ * directly. It could already have been destroyed.
*/
- if (of->priv)
- of->priv = cgroup_pidlist_find(cgrp, type);
+ if (ctx->procs1.pidlist)
+ ctx->procs1.pidlist = cgroup_pidlist_find(cgrp, type);
/*
* Either this is the first start() after open or the matching
* pidlist has been destroyed inbetween. Create a new one.
*/
- if (!of->priv) {
- ret = pidlist_array_load(cgrp, type,
- (struct cgroup_pidlist **)&of->priv);
+ if (!ctx->procs1.pidlist) {
+ ret = pidlist_array_load(cgrp, type, &ctx->procs1.pidlist);
if (ret)
return ERR_PTR(ret);
}
- l = of->priv;
+ l = ctx->procs1.pidlist;
if (pid) {
int end = l->length;
@@ -448,7 +448,8 @@ static void *cgroup_pidlist_start(struct
static void cgroup_pidlist_stop(struct seq_file *s, void *v)
{
struct kernfs_open_file *of = s->private;
- struct cgroup_pidlist *l = of->priv;
+ struct cgroup_file_ctx *ctx = of->priv;
+ struct cgroup_pidlist *l = ctx->procs1.pidlist;
if (l)
mod_delayed_work(cgroup_pidlist_destroy_wq, &l->destroy_dwork,
@@ -459,7 +460,8 @@ static void cgroup_pidlist_stop(struct s
static void *cgroup_pidlist_next(struct seq_file *s, void *v, loff_t *pos)
{
struct kernfs_open_file *of = s->private;
- struct cgroup_pidlist *l = of->priv;
+ struct cgroup_file_ctx *ctx = of->priv;
+ struct cgroup_pidlist *l = ctx->procs1.pidlist;
pid_t *p = v;
pid_t *end = l->list + l->length;
/*
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3590,6 +3590,7 @@ static int cgroup_cpu_pressure_show(stru
static ssize_t cgroup_pressure_write(struct kernfs_open_file *of, char *buf,
size_t nbytes, enum psi_res res)
{
+ struct cgroup_file_ctx *ctx = of->priv;
struct psi_trigger *new;
struct cgroup *cgrp;
struct psi_group *psi;
@@ -3602,7 +3603,7 @@ static ssize_t cgroup_pressure_write(str
cgroup_kn_unlock(of->kn);
/* Allow only one trigger per file descriptor */
- if (of->priv) {
+ if (ctx->psi.trigger) {
cgroup_put(cgrp);
return -EBUSY;
}
@@ -3614,7 +3615,7 @@ static ssize_t cgroup_pressure_write(str
return PTR_ERR(new);
}
- smp_store_release(&of->priv, new);
+ smp_store_release(&ctx->psi.trigger, new);
cgroup_put(cgrp);
return nbytes;
@@ -3644,12 +3645,15 @@ static ssize_t cgroup_cpu_pressure_write
static __poll_t cgroup_pressure_poll(struct kernfs_open_file *of,
poll_table *pt)
{
- return psi_trigger_poll(&of->priv, of->file, pt);
+ struct cgroup_file_ctx *ctx = of->priv;
+ return psi_trigger_poll(&ctx->psi.trigger, of->file, pt);
}
static void cgroup_pressure_release(struct kernfs_open_file *of)
{
- psi_trigger_destroy(of->priv);
+ struct cgroup_file_ctx *ctx = of->priv;
+
+ psi_trigger_destroy(ctx->psi.trigger);
}
#endif /* CONFIG_PSI */
@@ -3690,18 +3694,31 @@ static ssize_t cgroup_freeze_write(struc
static int cgroup_file_open(struct kernfs_open_file *of)
{
struct cftype *cft = of->kn->priv;
+ struct cgroup_file_ctx *ctx;
+ int ret;
- if (cft->open)
- return cft->open(of);
- return 0;
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+ of->priv = ctx;
+
+ if (!cft->open)
+ return 0;
+
+ ret = cft->open(of);
+ if (ret)
+ kfree(ctx);
+ return ret;
}
static void cgroup_file_release(struct kernfs_open_file *of)
{
struct cftype *cft = of->kn->priv;
+ struct cgroup_file_ctx *ctx = of->priv;
if (cft->release)
cft->release(of);
+ kfree(ctx);
}
static ssize_t cgroup_file_write(struct kernfs_open_file *of, char *buf,
@@ -4625,21 +4642,21 @@ void css_task_iter_end(struct css_task_i
static void cgroup_procs_release(struct kernfs_open_file *of)
{
- if (of->priv) {
- css_task_iter_end(of->priv);
- kfree(of->priv);
- }
+ struct cgroup_file_ctx *ctx = of->priv;
+
+ if (ctx->procs.started)
+ css_task_iter_end(&ctx->procs.iter);
}
static void *cgroup_procs_next(struct seq_file *s, void *v, loff_t *pos)
{
struct kernfs_open_file *of = s->private;
- struct css_task_iter *it = of->priv;
+ struct cgroup_file_ctx *ctx = of->priv;
if (pos)
(*pos)++;
- return css_task_iter_next(it);
+ return css_task_iter_next(&ctx->procs.iter);
}
static void *__cgroup_procs_start(struct seq_file *s, loff_t *pos,
@@ -4647,21 +4664,18 @@ static void *__cgroup_procs_start(struct
{
struct kernfs_open_file *of = s->private;
struct cgroup *cgrp = seq_css(s)->cgroup;
- struct css_task_iter *it = of->priv;
+ struct cgroup_file_ctx *ctx = of->priv;
+ struct css_task_iter *it = &ctx->procs.iter;
/*
* When a seq_file is seeked, it's always traversed sequentially
* from position 0, so we can simply keep iterating on !0 *pos.
*/
- if (!it) {
+ if (!ctx->procs.started) {
if (WARN_ON_ONCE((*pos)))
return ERR_PTR(-EINVAL);
-
- it = kzalloc(sizeof(*it), GFP_KERNEL);
- if (!it)
- return ERR_PTR(-ENOMEM);
- of->priv = it;
css_task_iter_start(&cgrp->self, iter_flags, it);
+ ctx->procs.started = true;
} else if (!(*pos)) {
css_task_iter_end(it);
css_task_iter_start(&cgrp->self, iter_flags, it);
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 05/38] cgroup: Use open-time cgroup namespace for process migration perm checks
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 04/38] cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 06/38] cgroup-v1: Correct privileges check in release_agent writes Greg Kroah-Hartman
` (41 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric W. Biederman, Linus Torvalds,
Michal Koutný,
Oleg Nesterov, syzbot+50f5cf33a284ce738b62, Tejun Heo
From: Tejun Heo <tj@kernel.org>
commit e57457641613fef0d147ede8bd6a3047df588b95 upstream.
cgroup process migration permission checks are performed at write time as
whether a given operation is allowed or not is dependent on the content of
the write - the PID. This currently uses current's cgroup namespace which is
a potential security weakness as it may allow scenarios where a less
privileged process tricks a more privileged one into writing into a fd that
it created.
This patch makes cgroup remember the cgroup namespace at the time of open
and uses it for migration permission checks instad of current's. Note that
this only applies to cgroup2 as cgroup1 doesn't have namespace support.
This also fixes a use-after-free bug on cgroupns reported in
https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
Note that backporting this fix also requires the preceding patch.
Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Michal Koutný <mkoutny@suse.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Michal Koutný <mkoutny@suse.com>
Reported-by: syzbot+50f5cf33a284ce738b62@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
Fixes: 5136f6365ce3 ("cgroup: implement "nsdelegate" mount option")
Signed-off-by: Tejun Heo <tj@kernel.org>
[mkoutny: v5.10: duplicate ns check in procs/threads write handler, adjust context]
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup-internal.h | 2 ++
kernel/cgroup/cgroup.c | 32 ++++++++++++++++++++++----------
2 files changed, 24 insertions(+), 10 deletions(-)
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -68,6 +68,8 @@ static inline struct cgroup_fs_context *
struct cgroup_pidlist;
struct cgroup_file_ctx {
+ struct cgroup_namespace *ns;
+
struct {
void *trigger;
} psi;
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3700,14 +3700,19 @@ static int cgroup_file_open(struct kernf
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
+
+ ctx->ns = current->nsproxy->cgroup_ns;
+ get_cgroup_ns(ctx->ns);
of->priv = ctx;
if (!cft->open)
return 0;
ret = cft->open(of);
- if (ret)
+ if (ret) {
+ put_cgroup_ns(ctx->ns);
kfree(ctx);
+ }
return ret;
}
@@ -3718,13 +3723,14 @@ static void cgroup_file_release(struct k
if (cft->release)
cft->release(of);
+ put_cgroup_ns(ctx->ns);
kfree(ctx);
}
static ssize_t cgroup_file_write(struct kernfs_open_file *of, char *buf,
size_t nbytes, loff_t off)
{
- struct cgroup_namespace *ns = current->nsproxy->cgroup_ns;
+ struct cgroup_file_ctx *ctx = of->priv;
struct cgroup *cgrp = of->kn->parent->priv;
struct cftype *cft = of->kn->priv;
struct cgroup_subsys_state *css;
@@ -3741,7 +3747,7 @@ static ssize_t cgroup_file_write(struct
*/
if ((cgrp->root->flags & CGRP_ROOT_NS_DELEGATE) &&
!(cft->flags & CFTYPE_NS_DELEGATABLE) &&
- ns != &init_cgroup_ns && ns->root_cset->dfl_cgrp == cgrp)
+ ctx->ns != &init_cgroup_ns && ctx->ns->root_cset->dfl_cgrp == cgrp)
return -EPERM;
if (cft->write)
@@ -4726,9 +4732,9 @@ static int cgroup_may_write(const struct
static int cgroup_procs_write_permission(struct cgroup *src_cgrp,
struct cgroup *dst_cgrp,
- struct super_block *sb)
+ struct super_block *sb,
+ struct cgroup_namespace *ns)
{
- struct cgroup_namespace *ns = current->nsproxy->cgroup_ns;
struct cgroup *com_cgrp = src_cgrp;
int ret;
@@ -4757,11 +4763,12 @@ static int cgroup_procs_write_permission
static int cgroup_attach_permissions(struct cgroup *src_cgrp,
struct cgroup *dst_cgrp,
- struct super_block *sb, bool threadgroup)
+ struct super_block *sb, bool threadgroup,
+ struct cgroup_namespace *ns)
{
int ret = 0;
- ret = cgroup_procs_write_permission(src_cgrp, dst_cgrp, sb);
+ ret = cgroup_procs_write_permission(src_cgrp, dst_cgrp, sb, ns);
if (ret)
return ret;
@@ -4778,6 +4785,7 @@ static int cgroup_attach_permissions(str
static ssize_t cgroup_procs_write(struct kernfs_open_file *of,
char *buf, size_t nbytes, loff_t off)
{
+ struct cgroup_file_ctx *ctx = of->priv;
struct cgroup *src_cgrp, *dst_cgrp;
struct task_struct *task;
ssize_t ret;
@@ -4798,7 +4806,8 @@ static ssize_t cgroup_procs_write(struct
spin_unlock_irq(&css_set_lock);
ret = cgroup_attach_permissions(src_cgrp, dst_cgrp,
- of->file->f_path.dentry->d_sb, true);
+ of->file->f_path.dentry->d_sb, true,
+ ctx->ns);
if (ret)
goto out_finish;
@@ -4820,6 +4829,7 @@ static void *cgroup_threads_start(struct
static ssize_t cgroup_threads_write(struct kernfs_open_file *of,
char *buf, size_t nbytes, loff_t off)
{
+ struct cgroup_file_ctx *ctx = of->priv;
struct cgroup *src_cgrp, *dst_cgrp;
struct task_struct *task;
ssize_t ret;
@@ -4843,7 +4853,8 @@ static ssize_t cgroup_threads_write(stru
/* thread migrations follow the cgroup.procs delegation rule */
ret = cgroup_attach_permissions(src_cgrp, dst_cgrp,
- of->file->f_path.dentry->d_sb, false);
+ of->file->f_path.dentry->d_sb, false,
+ ctx->ns);
if (ret)
goto out_finish;
@@ -6023,7 +6034,8 @@ static int cgroup_css_set_fork(struct ke
goto err;
ret = cgroup_attach_permissions(cset->dfl_cgrp, dst_cgrp, sb,
- !(kargs->flags & CLONE_THREAD));
+ !(kargs->flags & CLONE_THREAD),
+ current->nsproxy->cgroup_ns);
if (ret)
goto err;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 06/38] cgroup-v1: Correct privileges check in release_agent writes
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 05/38] cgroup: Use open-time cgroup namespace for process migration perm checks Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 07/38] tpm: Fix error handling in async work Greg Kroah-Hartman
` (40 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Koutný,
Masami Ichikawa(CIP),
Tejun Heo
From: Michal Koutný <mkoutny@suse.com>
commit 467a726b754f474936980da793b4ff2ec3e382a7 upstream.
The idea is to check: a) the owning user_ns of cgroup_ns, b)
capabilities in init_user_ns.
The commit 24f600856418 ("cgroup-v1: Require capabilities to set
release_agent") got this wrong in the write handler of release_agent
since it checked user_ns of the opener (may be different from the owning
user_ns of cgroup_ns).
Secondly, to avoid possibly confused deputy, the capability of the
opener must be checked.
Fixes: 24f600856418 ("cgroup-v1: Require capabilities to set release_agent")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/stable/20220216121142.GB30035@blackbody.suse.cz/
Signed-off-by: Michal Koutný <mkoutny@suse.com>
Reviewed-by: Masami Ichikawa(CIP) <masami.ichikawa@cybertrust.co.jp>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/cgroup/cgroup-v1.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -544,6 +544,7 @@ static ssize_t cgroup_release_agent_writ
char *buf, size_t nbytes, loff_t off)
{
struct cgroup *cgrp;
+ struct cgroup_file_ctx *ctx;
BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);
@@ -551,8 +552,9 @@ static ssize_t cgroup_release_agent_writ
* Release agent gets called with all capabilities,
* require capabilities to set release agent.
*/
- if ((of->file->f_cred->user_ns != &init_user_ns) ||
- !capable(CAP_SYS_ADMIN))
+ ctx = of->priv;
+ if ((ctx->ns->user_ns != &init_user_ns) ||
+ !file_ns_capable(of->file, &init_user_ns, CAP_SYS_ADMIN))
return -EPERM;
cgrp = cgroup_kn_lock_live(of->kn, false);
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 07/38] tpm: Fix error handling in async work
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 06/38] cgroup-v1: Correct privileges check in release_agent writes Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 08/38] staging: fbtft: fb_st7789v: reset display before initialization Greg Kroah-Hartman
` (39 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jarkko Sakkinen, Jason Gunthorpe,
linux-integrity, Tadeusz Struk, Tadeusz Struk
From: Tadeusz Struk <tstruk@gmail.com>
commit 2e8e4c8f6673247e22efc7985ce5497accd16f88 upstream.
When an invalid (non existing) handle is used in a TPM command,
that uses the resource manager interface (/dev/tpmrm0) the resource
manager tries to load it from its internal cache, but fails and
the tpm_dev_transmit returns an -EINVAL error to the caller.
The existing async handler doesn't handle these error cases
currently and the condition in the poll handler never returns
mask with EPOLLIN set.
The result is that the poll call blocks and the application gets stuck
until the user_read_timer wakes it up after 120 sec.
Change the tpm_dev_async_work function to handle error conditions
returned from tpm_dev_transmit they are also reflected in the poll mask
and a correct error code could passed back to the caller.
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: <linux-integrity@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Fixes: 9e1b74a63f77 ("tpm: add support for nonblocking operation")
Tested-by: Jarkko Sakkinen<jarkko@kernel.org>
Signed-off-by: Tadeusz Struk <tstruk@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/tpm/tpm-dev-common.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -70,7 +70,13 @@ static void tpm_dev_async_work(struct wo
ret = tpm_dev_transmit(priv->chip, priv->space, priv->data_buffer,
sizeof(priv->data_buffer));
tpm_put_ops(priv->chip);
- if (ret > 0) {
+
+ /*
+ * If ret is > 0 then tpm_dev_transmit returned the size of the
+ * response. If ret is < 0 then tpm_dev_transmit failed and
+ * returned an error code.
+ */
+ if (ret != 0) {
priv->response_length = ret;
mod_timer(&priv->user_read_timer, jiffies + (120 * HZ));
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 08/38] staging: fbtft: fb_st7789v: reset display before initialization
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 07/38] tpm: Fix error handling in async work Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind() Greg Kroah-Hartman
` (38 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Oliver Graute, Sudip Mukherjee
From: Oliver Graute <oliver.graute@kococonnector.com>
commit b6821b0d9b56386d2bf14806f90ec401468c799f upstream.
In rare cases the display is flipped or mirrored. This was observed more
often in a low temperature environment. A clean reset on init_display()
should help to get registers in a sane state.
Fixes: ef8f317795da (staging: fbtft: use init function instead of init sequence)
Cc: stable@vger.kernel.org
Signed-off-by: Oliver Graute <oliver.graute@kococonnector.com>
Link: https://lore.kernel.org/r/20220210085322.15676-1-oliver.graute@kococonnector.com
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/fbtft/fb_st7789v.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -82,6 +82,8 @@ enum st7789v_command {
*/
static int init_display(struct fbtft_par *par)
{
+ par->fbtftops.reset(par);
+
/* turn off sleep mode */
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
mdelay(120);
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 08/38] staging: fbtft: fb_st7789v: reset display before initialization Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-26 20:09 ` Pavel Machek
2022-03-25 15:04 ` [PATCH 5.10 10/38] swiotlb: fix info leak with DMA_FROM_DEVICE Greg Kroah-Hartman
` (37 subsequent siblings)
46 siblings, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov, Jakub Kicinski
From: Eric Dumazet <edumazet@google.com>
commit 764f4eb6846f5475f1244767d24d25dd86528a4a upstream.
Whenever llc_ui_bind() and/or llc_ui_autobind()
took a reference on a netdevice but subsequently fail,
they must properly release their reference
or risk the infamous message from unregister_netdevice()
at device dismantle.
unregister_netdevice: waiting for eth0 to become free. Usage count = 3
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: 赵子轩 <beraphin@gmail.com>
Reported-by: Stoyan Manolov <smanolov@suse.de>
Link: https://lore.kernel.org/r/20220323004147.1990845-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/llc/af_llc.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -311,6 +311,10 @@ static int llc_ui_autobind(struct socket
sock_reset_flag(sk, SOCK_ZAPPED);
rc = 0;
out:
+ if (rc) {
+ dev_put(llc->dev);
+ llc->dev = NULL;
+ }
return rc;
}
@@ -409,6 +413,10 @@ static int llc_ui_bind(struct socket *so
out_put:
llc_sap_put(sap);
out:
+ if (rc) {
+ dev_put(llc->dev);
+ llc->dev = NULL;
+ }
release_sock(sk);
return rc;
}
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-25 15:04 ` [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind() Greg Kroah-Hartman
@ 2022-03-26 20:09 ` Pavel Machek
2022-03-26 20:13 ` Jakub Kicinski
0 siblings, 1 reply; 65+ messages in thread
From: Pavel Machek @ 2022-03-26 20:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Eric Dumazet, 赵子轩,
Stoyan Manolov, Jakub Kicinski
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
Hi!
> From: Eric Dumazet <edumazet@google.com>
>
> commit 764f4eb6846f5475f1244767d24d25dd86528a4a upstream.
>
> Whenever llc_ui_bind() and/or llc_ui_autobind()
> took a reference on a netdevice but subsequently fail,
> they must properly release their reference
> or risk the infamous message from unregister_netdevice()
> at device dismantle.
>
> unregister_netdevice: waiting for eth0 to become free. Usage count =
> 3
Can someone check this? AFAICT this is buggy.
static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
{
struct sock *sk = sock->sk;
struct llc_sock *llc = llc_sk(sk);
struct llc_sap *sap;
int rc = -EINVAL;
if (!sock_flag(sk, SOCK_ZAPPED))
goto out;
There are 'goto out's from both before dev_get() and after it,
dev_put() will be called with NULL pointer. dev_put() can't handle
NULL at least in the old kernels... this is simply confused.
Mainline has dev_put_track() there, but I see same confusion.
Best regards,
Pavel
> --- a/net/llc/af_llc.c
> +++ b/net/llc/af_llc.c
> @@ -311,6 +311,10 @@ static int llc_ui_autobind(struct socket
> sock_reset_flag(sk, SOCK_ZAPPED);
> rc = 0;
> out:
> + if (rc) {
> + dev_put(llc->dev);
> + llc->dev = NULL;
> + }
> return rc;
> }
>
> @@ -409,6 +413,10 @@ static int llc_ui_bind(struct socket *so
> out_put:
> llc_sap_put(sap);
> out:
> + if (rc) {
> + dev_put(llc->dev);
> + llc->dev = NULL;
> + }
> release_sock(sk);
> return rc;
> }
>
--
'DENX Software Engineering GmbH, Managing Director: Wolfgang Denk'
'HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-26 20:09 ` Pavel Machek
@ 2022-03-26 20:13 ` Jakub Kicinski
2022-03-26 21:35 ` Pavel Machek
2022-03-27 9:51 ` Greg Kroah-Hartman
0 siblings, 2 replies; 65+ messages in thread
From: Jakub Kicinski @ 2022-03-26 20:13 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
On Sat, 26 Mar 2022 21:09:22 +0100 Pavel Machek wrote:
> Can someone check this? AFAICT this is buggy.
>
> static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> {
> struct sock *sk = sock->sk;
> struct llc_sock *llc = llc_sk(sk);
> struct llc_sap *sap;
> int rc = -EINVAL;
>
> if (!sock_flag(sk, SOCK_ZAPPED))
> goto out;
>
> There are 'goto out's from both before dev_get() and after it,
> dev_put() will be called with NULL pointer. dev_put() can't handle
> NULL at least in the old kernels... this is simply confused.
>
> Mainline has dev_put_track() there, but I see same confusion.
>
> Best regards,
commit 2d327a79ee17 ("llc: only change llc->dev when bind() succeeds"),
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2d327a79ee176930dc72c131a970c891d367c1dc
Should be in mainline on Thursday, LMK if we need to accelerate.
IDK if anyone enables LLC2.
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-26 20:13 ` Jakub Kicinski
@ 2022-03-26 21:35 ` Pavel Machek
2022-03-27 9:51 ` Greg Kroah-Hartman
1 sibling, 0 replies; 65+ messages in thread
From: Pavel Machek @ 2022-03-26 21:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Pavel Machek, Greg Kroah-Hartman, linux-kernel, stable,
Eric Dumazet, 赵子轩,
Stoyan Manolov
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]
Hi!
> > Can someone check this? AFAICT this is buggy.
> >
> > static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> > {
> > struct sock *sk = sock->sk;
> > struct llc_sock *llc = llc_sk(sk);
> > struct llc_sap *sap;
> > int rc = -EINVAL;
> >
> > if (!sock_flag(sk, SOCK_ZAPPED))
> > goto out;
> >
> > There are 'goto out's from both before dev_get() and after it,
> > dev_put() will be called with NULL pointer. dev_put() can't handle
> > NULL at least in the old kernels... this is simply confused.
> >
> > Mainline has dev_put_track() there, but I see same confusion.
> >
> > Best regards,
>
> commit 2d327a79ee17 ("llc: only change llc->dev when bind() succeeds"),
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2d327a79ee176930dc72c131a970c891d367c1dc
>
> Should be in mainline on Thursday, LMK if we need to accelerate.
> IDK if anyone enables LLC2.
Thank you, yes, that looks good at the fast glance.
But this patch does more harm than good on its own, so I believe it
should be dropped for now, and only queued when the fixes are
available.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-26 20:13 ` Jakub Kicinski
2022-03-26 21:35 ` Pavel Machek
@ 2022-03-27 9:51 ` Greg Kroah-Hartman
2022-03-28 9:08 ` Pavel Machek
1 sibling, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-27 9:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Pavel Machek, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
On Sat, Mar 26, 2022 at 01:13:25PM -0700, Jakub Kicinski wrote:
> On Sat, 26 Mar 2022 21:09:22 +0100 Pavel Machek wrote:
> > Can someone check this? AFAICT this is buggy.
> >
> > static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> > {
> > struct sock *sk = sock->sk;
> > struct llc_sock *llc = llc_sk(sk);
> > struct llc_sap *sap;
> > int rc = -EINVAL;
> >
> > if (!sock_flag(sk, SOCK_ZAPPED))
> > goto out;
> >
> > There are 'goto out's from both before dev_get() and after it,
> > dev_put() will be called with NULL pointer. dev_put() can't handle
> > NULL at least in the old kernels... this is simply confused.
> >
> > Mainline has dev_put_track() there, but I see same confusion.
> >
> > Best regards,
>
> commit 2d327a79ee17 ("llc: only change llc->dev when bind() succeeds"),
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2d327a79ee176930dc72c131a970c891d367c1dc
>
> Should be in mainline on Thursday, LMK if we need to accelerate.
> IDK if anyone enables LLC2.
I'll queue this up now, thanks.
greg k-h
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-27 9:51 ` Greg Kroah-Hartman
@ 2022-03-28 9:08 ` Pavel Machek
2022-03-28 9:13 ` Greg Kroah-Hartman
0 siblings, 1 reply; 65+ messages in thread
From: Pavel Machek @ 2022-03-28 9:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jakub Kicinski, Pavel Machek, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
Hi!
> > > Can someone check this? AFAICT this is buggy.
> > >
> > > static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> > > {
> > > struct sock *sk = sock->sk;
> > > struct llc_sock *llc = llc_sk(sk);
> > > struct llc_sap *sap;
> > > int rc = -EINVAL;
> > >
> > > if (!sock_flag(sk, SOCK_ZAPPED))
> > > goto out;
> > >
> > > There are 'goto out's from both before dev_get() and after it,
> > > dev_put() will be called with NULL pointer. dev_put() can't handle
> > > NULL at least in the old kernels... this is simply confused.
> > >
> > > Mainline has dev_put_track() there, but I see same confusion.
> > >
> > > Best regards,
> >
> > commit 2d327a79ee17 ("llc: only change llc->dev when bind() succeeds"),
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2d327a79ee176930dc72c131a970c891d367c1dc
> >
> > Should be in mainline on Thursday, LMK if we need to accelerate.
> > IDK if anyone enables LLC2.
>
> I'll queue this up now, thanks.
As the changelog says, this needs b37a46683739, otherwise there will
be oops-es in even more cases.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-28 9:08 ` Pavel Machek
@ 2022-03-28 9:13 ` Greg Kroah-Hartman
2022-03-28 9:31 ` Pavel Machek
2022-03-28 9:37 ` Pavel Machek
0 siblings, 2 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-28 9:13 UTC (permalink / raw)
To: Pavel Machek
Cc: Jakub Kicinski, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
On Mon, Mar 28, 2022 at 11:08:30AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > Can someone check this? AFAICT this is buggy.
> > > >
> > > > static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> > > > {
> > > > struct sock *sk = sock->sk;
> > > > struct llc_sock *llc = llc_sk(sk);
> > > > struct llc_sap *sap;
> > > > int rc = -EINVAL;
> > > >
> > > > if (!sock_flag(sk, SOCK_ZAPPED))
> > > > goto out;
> > > >
> > > > There are 'goto out's from both before dev_get() and after it,
> > > > dev_put() will be called with NULL pointer. dev_put() can't handle
> > > > NULL at least in the old kernels... this is simply confused.
> > > >
> > > > Mainline has dev_put_track() there, but I see same confusion.
> > > >
> > > > Best regards,
> > >
> > > commit 2d327a79ee17 ("llc: only change llc->dev when bind() succeeds"),
> > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2d327a79ee176930dc72c131a970c891d367c1dc
> > >
> > > Should be in mainline on Thursday, LMK if we need to accelerate.
> > > IDK if anyone enables LLC2.
> >
> > I'll queue this up now, thanks.
>
> As the changelog says, this needs b37a46683739, otherwise there will
> be oops-es in even more cases.
If you look at the change, I think I already handled that issue. If
not, please let me know.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-28 9:13 ` Greg Kroah-Hartman
@ 2022-03-28 9:31 ` Pavel Machek
2022-03-28 9:42 ` Greg Kroah-Hartman
2022-03-28 9:37 ` Pavel Machek
1 sibling, 1 reply; 65+ messages in thread
From: Pavel Machek @ 2022-03-28 9:31 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pavel Machek, Jakub Kicinski, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
Hi!
> > > > Should be in mainline on Thursday, LMK if we need to accelerate.
> > > > IDK if anyone enables LLC2.
> > >
> > > I'll queue this up now, thanks.
> >
> > As the changelog says, this needs b37a46683739, otherwise there will
> > be oops-es in even more cases.
>
> If you look at the change, I think I already handled that issue. If
> not, please let me know.
I did not notice you making changes there, but no, it is not correct
AFAICT.
# commit 163960a7de1333514c9352deb7c80c6b9fd9abf2
# Author: Eric Dumazet <edumazet@google.com>
# Date: Thu Mar 24 20:58:27 2022 -0700
# llc: only change llc->dev when bind() succeeds
...
# Make sure commit b37a46683739 ("netdevice: add the case if dev is NULL")
# is already present in your trees.
Before b37a46683739, dev_put can't handle NULL.
+++ b/net/llc/af_llc.c
@@ -287,14 +288,14 @@ static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
...
- llc->dev = dev_getfirstbyhwtype(&init_net, addr->sllc_arphrd);
- if (!llc->dev)
+ dev = dev_getfirstbyhwtype(&init_net, addr->sllc_arphrd);
+ if (!dev)
goto out;
rc = -EUSERS;
llc->laddr.lsap = llc_ui_autoport();
One of several paths where we goto out with dev==NULL.
@@ -311,10 +317,7 @@ static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
sock_reset_flag(sk, SOCK_ZAPPED);
rc = 0;
out:
- if (rc) {
- dev_put(llc->dev);
- llc->dev = NULL;
- }
+ dev_put(dev);
return rc;
}
But dev_put can't handle NULL.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-28 9:31 ` Pavel Machek
@ 2022-03-28 9:42 ` Greg Kroah-Hartman
0 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-28 9:42 UTC (permalink / raw)
To: Pavel Machek
Cc: Jakub Kicinski, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
On Mon, Mar 28, 2022 at 11:31:16AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > Should be in mainline on Thursday, LMK if we need to accelerate.
> > > > > IDK if anyone enables LLC2.
> > > >
> > > > I'll queue this up now, thanks.
> > >
> > > As the changelog says, this needs b37a46683739, otherwise there will
> > > be oops-es in even more cases.
> >
> > If you look at the change, I think I already handled that issue. If
> > not, please let me know.
>
> I did not notice you making changes there, but no, it is not correct
> AFAICT.
>
> # commit 163960a7de1333514c9352deb7c80c6b9fd9abf2
> # Author: Eric Dumazet <edumazet@google.com>
> # Date: Thu Mar 24 20:58:27 2022 -0700
>
> # llc: only change llc->dev when bind() succeeds
> ...
> # Make sure commit b37a46683739 ("netdevice: add the case if dev is NULL")
> # is already present in your trees.
>
> Before b37a46683739, dev_put can't handle NULL.
>
> +++ b/net/llc/af_llc.c
> @@ -287,14 +288,14 @@ static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> ...
>
> - llc->dev = dev_getfirstbyhwtype(&init_net, addr->sllc_arphrd);
> - if (!llc->dev)
> + dev = dev_getfirstbyhwtype(&init_net, addr->sllc_arphrd);
> + if (!dev)
> goto out;
> rc = -EUSERS;
> llc->laddr.lsap = llc_ui_autoport();
>
> One of several paths where we goto out with dev==NULL.
>
> @@ -311,10 +317,7 @@ static int llc_ui_autobind(struct socket *sock, struct sockaddr_llc *addr)
> sock_reset_flag(sk, SOCK_ZAPPED);
> rc = 0;
> out:
> - if (rc) {
> - dev_put(llc->dev);
> - llc->dev = NULL;
> - }
> + dev_put(dev);
> return rc;
> }
>
>
> But dev_put can't handle NULL.
Ah, missed that one. I'll go queue up b37a46683739 now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind()
2022-03-28 9:13 ` Greg Kroah-Hartman
2022-03-28 9:31 ` Pavel Machek
@ 2022-03-28 9:37 ` Pavel Machek
1 sibling, 0 replies; 65+ messages in thread
From: Pavel Machek @ 2022-03-28 9:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pavel Machek, Jakub Kicinski, linux-kernel, stable, Eric Dumazet,
赵子轩,
Stoyan Manolov
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
Hi!
> > > > commit 2d327a79ee17 ("llc: only change llc->dev when bind() succeeds"),
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=2d327a79ee176930dc72c131a970c891d367c1dc
> > > >
> > > > Should be in mainline on Thursday, LMK if we need to accelerate.
> > > > IDK if anyone enables LLC2.
> > >
> > > I'll queue this up now, thanks.
> >
> > As the changelog says, this needs b37a46683739, otherwise there will
> > be oops-es in even more cases.
>
> If you look at the change, I think I already handled that issue. If
> not, please let me know.
Actually, AFAICT it will now oops even in the common (non-error) path
in llc_ui_autobind().
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 5.10 10/38] swiotlb: fix info leak with DMA_FROM_DEVICE
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 09/38] llc: fix netdevice reference leaks in llc_ui_bind() Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE" Greg Kroah-Hartman
` (36 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Halil Pasic, Christoph Hellwig
From: Halil Pasic <pasic@linux.ibm.com>
commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e upstream.
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a corresponding dxferp. The peculiar thing about this is that TUR
is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
bounces the user-space buffer. As if the device was to transfer into
it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
sg_build_indirect()") we make sure this first bounce buffer is
allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
device won't touch the buffer we prepare as if the we had a
DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
and the buffer allocated by SG is mapped by the function
virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
scatter-gather and not scsi generics). This mapping involves bouncing
via the swiotlb (we need swiotlb to do virtio in protected guest like
s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
(that is swiotlb) bounce buffer (which most likely contains some
previous IO data), to the first bounce buffer, which contains all
zeros. Then we copy back the content of the first bounce buffer to
the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
ain't all zeros and fails.
One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).
Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce.
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/core-api/dma-attributes.rst | 8 ++++++++
include/linux/dma-mapping.h | 8 ++++++++
kernel/dma/swiotlb.c | 3 ++-
3 files changed, 18 insertions(+), 1 deletion(-)
--- a/Documentation/core-api/dma-attributes.rst
+++ b/Documentation/core-api/dma-attributes.rst
@@ -130,3 +130,11 @@ accesses to DMA buffers in both privileg
subsystem that the buffer is fully accessible at the elevated privilege
level (and ideally inaccessible or at least read-only at the
lesser-privileged levels).
+
+DMA_ATTR_OVERWRITE
+------------------
+
+This is a hint to the DMA-mapping subsystem that the device is expected to
+overwrite the entire mapped size, thus the caller does not require any of the
+previous buffer contents to be preserved. This allows bounce-buffering
+implementations to optimise DMA_FROM_DEVICE transfers.
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -62,6 +62,14 @@
#define DMA_ATTR_PRIVILEGED (1UL << 9)
/*
+ * This is a hint to the DMA-mapping subsystem that the device is expected
+ * to overwrite the entire mapped size, thus the caller does not require any
+ * of the previous buffer contents to be preserved. This allows
+ * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers.
+ */
+#define DMA_ATTR_OVERWRITE (1UL << 10)
+
+/*
* A dma_addr_t can hold any valid DMA or bus address for the platform. It can
* be given to a device to use as a DMA source or target. It is specific to a
* given device and there may be a translation between the CPU physical address
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -598,7 +598,8 @@ phys_addr_t swiotlb_tbl_map_single(struc
tlb_addr = slot_addr(io_tlb_start, index) + offset;
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
+ (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE ||
+ dir == DMA_BIDIRECTIONAL))
swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE);
return tlb_addr;
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 10/38] swiotlb: fix info leak with DMA_FROM_DEVICE Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 17:08 ` Linus Torvalds
2022-03-25 15:04 ` [PATCH 5.10 12/38] ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call Greg Kroah-Hartman
` (35 subsequent siblings)
46 siblings, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Halil Pasic, Christoph Hellwig,
Linus Torvalds
From: Halil Pasic <pasic@linux.ibm.com>
commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream.
Unfortunately, we ended up merging an old version of the patch "fix info
leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph
(the swiotlb maintainer), he asked me to create an incremental fix
(after I have pointed this out the mix up, and asked him for guidance).
So here we go.
The main differences between what we got and what was agreed are:
* swiotlb_sync_single_for_device is also required to do an extra bounce
* We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters
* The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE
must take precedence over DMA_ATTR_SKIP_CPU_SYNC
Thus this patch removes DMA_ATTR_OVERWRITE, and makes
swiotlb_sync_single_for_device() bounce unconditionally (that is, also
when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
data from the swiotlb buffer.
Let me note, that if the size used with dma_sync_* API is less than the
size used with dma_[un]map_*, under certain circumstances we may still
end up with swiotlb not being transparent. In that sense, this is no
perfect fix either.
To get this bullet proof, we would have to bounce the entire
mapping/bounce buffer. For that we would have to figure out the starting
address, and the size of the mapping in
swiotlb_sync_single_for_device(). While this does seem possible, there
seems to be no firm consensus on how things are supposed to work.
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/core-api/dma-attributes.rst | 8 --------
include/linux/dma-mapping.h | 8 --------
kernel/dma/swiotlb.c | 25 ++++++++++++++++---------
3 files changed, 16 insertions(+), 25 deletions(-)
--- a/Documentation/core-api/dma-attributes.rst
+++ b/Documentation/core-api/dma-attributes.rst
@@ -130,11 +130,3 @@ accesses to DMA buffers in both privileg
subsystem that the buffer is fully accessible at the elevated privilege
level (and ideally inaccessible or at least read-only at the
lesser-privileged levels).
-
-DMA_ATTR_OVERWRITE
-------------------
-
-This is a hint to the DMA-mapping subsystem that the device is expected to
-overwrite the entire mapped size, thus the caller does not require any of the
-previous buffer contents to be preserved. This allows bounce-buffering
-implementations to optimise DMA_FROM_DEVICE transfers.
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -62,14 +62,6 @@
#define DMA_ATTR_PRIVILEGED (1UL << 9)
/*
- * This is a hint to the DMA-mapping subsystem that the device is expected
- * to overwrite the entire mapped size, thus the caller does not require any
- * of the previous buffer contents to be preserved. This allows
- * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers.
- */
-#define DMA_ATTR_OVERWRITE (1UL << 10)
-
-/*
* A dma_addr_t can hold any valid DMA or bus address for the platform. It can
* be given to a device to use as a DMA source or target. It is specific to a
* given device and there may be a translation between the CPU physical address
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -597,10 +597,14 @@ phys_addr_t swiotlb_tbl_map_single(struc
io_tlb_orig_addr[index + i] = slot_addr(orig_addr, i);
tlb_addr = slot_addr(io_tlb_start, index) + offset;
- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE ||
- dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE);
+ /*
+ * When dir == DMA_FROM_DEVICE we could omit the copy from the orig
+ * to the tlb buffer, if we knew for sure the device will
+ * overwirte the entire current content. But we don't. Thus
+ * unconditional bounce may prevent leaking swiotlb content (i.e.
+ * kernel memory) to user-space.
+ */
+ swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE);
return tlb_addr;
}
@@ -680,11 +684,14 @@ void swiotlb_tbl_sync_single(struct devi
BUG_ON(dir != DMA_TO_DEVICE);
break;
case SYNC_FOR_DEVICE:
- if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(orig_addr, tlb_addr,
- size, DMA_TO_DEVICE);
- else
- BUG_ON(dir != DMA_FROM_DEVICE);
+ /*
+ * Unconditional bounce is necessary to avoid corruption on
+ * sync_*_for_cpu or dma_ummap_* when the device didn't
+ * overwrite the whole lengt of the bounce buffer.
+ */
+ swiotlb_bounce(orig_addr, tlb_addr,
+ size, DMA_TO_DEVICE);
+ BUG_ON(!valid_dma_direction(dir));
break;
default:
BUG();
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-25 15:04 ` [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE" Greg Kroah-Hartman
@ 2022-03-25 17:08 ` Linus Torvalds
2022-03-25 17:36 ` Thomas Backlund
2022-03-26 10:18 ` Greg Kroah-Hartman
0 siblings, 2 replies; 65+ messages in thread
From: Linus Torvalds @ 2022-03-25 17:08 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
On Fri, Mar 25, 2022 at 8:09 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> From: Halil Pasic <pasic@linux.ibm.com>
>
> commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream.
This one causes a regression on at least some wireless drivers
(ath9k). There's some active discussion about it, maybe it gets
reverted, maybe there are other options.
There's an ath9k patch that fixes the problem, so if this patch goes
into the stable tree the ath9k fix will follow.
But it might be a good idea to simply hold off on this patch a bit,
because that ath9k patch hasn't actually landed yet, there's some
discussion about it all, and it's not clear that other drivers might
not have the same issue.
So I'm not NAK'ing this patch from stable, but I also don't think it's
timing-critical, and it might be a good idea to delay it for a week or
two to both wait for the ath9k patch and to see if something else
comes up.
Linus
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-25 17:08 ` Linus Torvalds
@ 2022-03-25 17:36 ` Thomas Backlund
2022-03-26 10:18 ` Greg Kroah-Hartman
1 sibling, 0 replies; 65+ messages in thread
From: Thomas Backlund @ 2022-03-25 17:36 UTC (permalink / raw)
To: Linus Torvalds, Greg Kroah-Hartman
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
Den 2022-03-25 kl. 19:08, skrev Linus Torvalds:
> On Fri, Mar 25, 2022 at 8:09 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>>
>> From: Halil Pasic <pasic@linux.ibm.com>
>>
>> commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream.
>
> This one causes a regression on at least some wireless drivers
> (ath9k). There's some active discussion about it, maybe it gets
> reverted, maybe there are other options.
>
> There's an ath9k patch that fixes the problem, so if this patch goes
> into the stable tree the ath9k fix will follow.
>
> But it might be a good idea to simply hold off on this patch a bit,
> because that ath9k patch hasn't actually landed yet, there's some
> discussion about it all, and it's not clear that other drivers might
> not have the same issue.
>
> So I'm not NAK'ing this patch from stable, but I also don't think it's
> timing-critical, and it might be a good idea to delay it for a week or
> two to both wait for the ath9k patch and to see if something else
> comes up.
>
> Linus
>
As it has already landed in 5.15.29 and 5.16.15 it should IMHO
preferably be reverted in those trees too to get them back to working
state...
--
Thomas
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-25 17:08 ` Linus Torvalds
2022-03-25 17:36 ` Thomas Backlund
@ 2022-03-26 10:18 ` Greg Kroah-Hartman
2022-03-26 18:41 ` Linus Torvalds
1 sibling, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-26 10:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
On Fri, Mar 25, 2022 at 10:08:27AM -0700, Linus Torvalds wrote:
> On Fri, Mar 25, 2022 at 8:09 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > From: Halil Pasic <pasic@linux.ibm.com>
> >
> > commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream.
>
> This one causes a regression on at least some wireless drivers
> (ath9k). There's some active discussion about it, maybe it gets
> reverted, maybe there are other options.
>
> There's an ath9k patch that fixes the problem, so if this patch goes
> into the stable tree the ath9k fix will follow.
>
> But it might be a good idea to simply hold off on this patch a bit,
> because that ath9k patch hasn't actually landed yet, there's some
> discussion about it all, and it's not clear that other drivers might
> not have the same issue.
>
> So I'm not NAK'ing this patch from stable, but I also don't think it's
> timing-critical, and it might be a good idea to delay it for a week or
> two to both wait for the ath9k patch and to see if something else
> comes up.
Yes, I've been watching that thread. This change is already in 5.15 and
5.16 kernels, and does solve one known security issue, so it's a tough
call. I'll drop them from 5.10 and 5.4 for now and save them to see how
it plays out...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 65+ messages in thread
* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-26 10:18 ` Greg Kroah-Hartman
@ 2022-03-26 18:41 ` Linus Torvalds
2022-03-27 9:30 ` Greg Kroah-Hartman
0 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2022-03-26 18:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
On Sat, Mar 26, 2022 at 3:18 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:"
>
> Yes, I've been watching that thread. This change is already in 5.15 and
> 5.16 kernels, and does solve one known security issue, so it's a tough
> call.
If you're following that thread, you'll have seen that I've reverted
it, and I actually think the security argument was bogus - the whole
commit was due to a misunderstanding of the actual direction of the
data transfer.
But hey, maybe I'm wrong. The only truly uncontested fact is that it
broke the ath9k driver.
Linus
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-26 18:41 ` Linus Torvalds
@ 2022-03-27 9:30 ` Greg Kroah-Hartman
2022-03-27 18:02 ` Linus Torvalds
0 siblings, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-27 9:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
On Sat, Mar 26, 2022 at 11:41:17AM -0700, Linus Torvalds wrote:
> On Sat, Mar 26, 2022 at 3:18 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:"
> >
> > Yes, I've been watching that thread. This change is already in 5.15 and
> > 5.16 kernels, and does solve one known security issue, so it's a tough
> > call.
>
> If you're following that thread, you'll have seen that I've reverted
> it, and I actually think the security argument was bogus - the whole
> commit was due to a misunderstanding of the actual direction of the
> data transfer.
I see that now, thanks.
But why did you just revert that commit, and not the previous one (i.e.
the one that this one "fixes")? Shouldn't ddbd89deb7d3 ("swiotlb: fix
info leak with DMA_FROM_DEVICE") also be dropped?
I'm going to drop both from the 5.4 and 5.10 stable queues now, and add
your revert, but I think your tree also needs the original swiotlb fix
commit reverted to get back to a "known good" state.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-27 9:30 ` Greg Kroah-Hartman
@ 2022-03-27 18:02 ` Linus Torvalds
2022-03-28 8:21 ` Greg Kroah-Hartman
0 siblings, 1 reply; 65+ messages in thread
From: Linus Torvalds @ 2022-03-27 18:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
On Sun, Mar 27, 2022 at 2:30 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> But why did you just revert that commit, and not the previous one (i.e.
> the one that this one "fixes")? Shouldn't ddbd89deb7d3 ("swiotlb: fix
> info leak with DMA_FROM_DEVICE") also be dropped?
The previous one wasn't obviously broken, and while it's a bit ugly,
it doesn't have the fundamental issues that the "fix" commit had.
And it does fix the whole "bounce buffer contents are undefined, and
can get copied back later" at the bounce buffer allocation (well,
"mapping") stage.
Which could cause wasted CPU cycles and isn't great, but should fix
the stale content thing for at least the common "map DMA, do DMA,
unmap" situation.
What commit aa6f8dcbab47 tried to fix was the "do multiple DMA
sequences using one single mapping" case, but that's also what then
broke ath9k because it really does want to do exactly that, but it
very much needs to do it using the same buffer with no "let's reset
it".
So I think you're fine to drop ddbd89deb7d3 too, but that commit
doesn't seem *wrong* per se.
I do think we need some model for "clear the bounce buffer of stale
data", and I do think that commit ddbd89deb7d3 probably isn't the
final word, but we don't actually _have_ the final word on this all,
so stable dropping it all is sane.
But as mentioned, commit ddbd89deb7d3 can actually fix some cases.
In particular, I do think it fixes the SG_IO data leak case that
triggered the whole issue. It was just then the "let's expand on this
fix" that was a disaster.
Linus
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
2022-03-27 18:02 ` Linus Torvalds
@ 2022-03-28 8:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-28 8:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, stable, Halil Pasic, Christoph Hellwig
On Sun, Mar 27, 2022 at 11:02:12AM -0700, Linus Torvalds wrote:
> On Sun, Mar 27, 2022 at 2:30 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > But why did you just revert that commit, and not the previous one (i.e.
> > the one that this one "fixes")? Shouldn't ddbd89deb7d3 ("swiotlb: fix
> > info leak with DMA_FROM_DEVICE") also be dropped?
>
> The previous one wasn't obviously broken, and while it's a bit ugly,
> it doesn't have the fundamental issues that the "fix" commit had.
>
> And it does fix the whole "bounce buffer contents are undefined, and
> can get copied back later" at the bounce buffer allocation (well,
> "mapping") stage.
>
> Which could cause wasted CPU cycles and isn't great, but should fix
> the stale content thing for at least the common "map DMA, do DMA,
> unmap" situation.
>
> What commit aa6f8dcbab47 tried to fix was the "do multiple DMA
> sequences using one single mapping" case, but that's also what then
> broke ath9k because it really does want to do exactly that, but it
> very much needs to do it using the same buffer with no "let's reset
> it".
>
> So I think you're fine to drop ddbd89deb7d3 too, but that commit
> doesn't seem *wrong* per se.
>
> I do think we need some model for "clear the bounce buffer of stale
> data", and I do think that commit ddbd89deb7d3 probably isn't the
> final word, but we don't actually _have_ the final word on this all,
> so stable dropping it all is sane.
>
> But as mentioned, commit ddbd89deb7d3 can actually fix some cases.
>
> In particular, I do think it fixes the SG_IO data leak case that
> triggered the whole issue. It was just then the "let's expand on this
> fix" that was a disaster.
Ok, I have just queued that one up now for the older kernels, and the
revert for 5.15 and newer, thanks.
greg k-h
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 5.10 12/38] ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE" Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 13/38] ALSA: oss: Fix PCM OSS buffer allocation overflow Greg Kroah-Hartman
` (34 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Palmer, Arnaud POULIQUEN,
Takashi Iwai, Arnaud Pouliquen, Mark Brown
From: Takashi Iwai <tiwai@suse.de>
commit 455c5653f50e10b4f460ef24e99f0044fbe3401c upstream.
This is essentially a revert of the commit dc865fb9e7c2 ("ASoC: sti:
Use snd_pcm_stop_xrun() helper"), which converted the manual
snd_pcm_stop() calls with snd_pcm_stop_xrun().
The commit above introduced a deadlock as snd_pcm_stop_xrun() itself
takes the PCM stream lock while the caller already holds it. Since
the conversion was done only for consistency reason and the open-call
with snd_pcm_stop() to the XRUN state is a correct usage, let's revert
the commit back as the fix.
Fixes: dc865fb9e7c2 ("ASoC: sti: Use snd_pcm_stop_xrun() helper")
Reported-by: Daniel Palmer <daniel@0x0f.com>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220315091319.3351522-1-daniel@0x0f.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20220315164158.19804-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/sti/uniperif_player.c | 6 +++---
sound/soc/sti/uniperif_reader.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/sound/soc/sti/uniperif_player.c
+++ b/sound/soc/sti/uniperif_player.c
@@ -91,7 +91,7 @@ static irqreturn_t uni_player_irq_handle
SET_UNIPERIF_ITM_BCLR_FIFO_ERROR(player);
/* Stop the player */
- snd_pcm_stop_xrun(player->substream);
+ snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN);
}
ret = IRQ_HANDLED;
@@ -105,7 +105,7 @@ static irqreturn_t uni_player_irq_handle
SET_UNIPERIF_ITM_BCLR_DMA_ERROR(player);
/* Stop the player */
- snd_pcm_stop_xrun(player->substream);
+ snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN);
ret = IRQ_HANDLED;
}
@@ -138,7 +138,7 @@ static irqreturn_t uni_player_irq_handle
dev_err(player->dev, "Underflow recovery failed\n");
/* Stop the player */
- snd_pcm_stop_xrun(player->substream);
+ snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN);
ret = IRQ_HANDLED;
}
--- a/sound/soc/sti/uniperif_reader.c
+++ b/sound/soc/sti/uniperif_reader.c
@@ -65,7 +65,7 @@ static irqreturn_t uni_reader_irq_handle
if (unlikely(status & UNIPERIF_ITS_FIFO_ERROR_MASK(reader))) {
dev_err(reader->dev, "FIFO error detected\n");
- snd_pcm_stop_xrun(reader->substream);
+ snd_pcm_stop(reader->substream, SNDRV_PCM_STATE_XRUN);
ret = IRQ_HANDLED;
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 13/38] ALSA: oss: Fix PCM OSS buffer allocation overflow
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 12/38] ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 14/38] ALSA: usb-audio: add mapping for new Corsair Virtuoso SE Greg Kroah-Hartman
` (33 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+72732c532ac1454eeee9,
Linus Torvalds, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit efb6402c3c4a7c26d97c92d70186424097b6e366 upstream.
We've got syzbot reports hitting INT_MAX overflow at vmalloc()
allocation that is called from snd_pcm_plug_alloc(). Although we
apply the restrictions to input parameters, it's based only on the
hw_params of the underlying PCM device. Since the PCM OSS layer
allocates a temporary buffer for the data conversion, the size may
become unexpectedly large when more channels or higher rates is given;
in the reported case, it went over INT_MAX, hence it hits WARN_ON().
This patch is an attempt to avoid such an overflow and an allocation
for too large buffers. First off, it adds the limit of 1MB as the
upper bound for period bytes. This must be large enough for all use
cases, and we really don't want to handle a larger temporary buffer
than this size. The size check is performed at two places, where the
original period bytes is calculated and where the plugin buffer size
is calculated.
In addition, the driver uses array_size() and array3_size() for
multiplications to catch overflows for the converted period size and
buffer bytes.
Reported-by: syzbot+72732c532ac1454eeee9@syzkaller.appspotmail.com
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/00000000000085b1b305da5a66f3@google.com
Link: https://lore.kernel.org/r/20220318082036.29699-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/oss/pcm_oss.c | 12 ++++++++----
sound/core/oss/pcm_plugin.c | 5 ++++-
2 files changed, 12 insertions(+), 5 deletions(-)
--- a/sound/core/oss/pcm_oss.c
+++ b/sound/core/oss/pcm_oss.c
@@ -774,6 +774,11 @@ static int snd_pcm_oss_period_size(struc
if (oss_period_size < 16)
return -EINVAL;
+
+ /* don't allocate too large period; 1MB period must be enough */
+ if (oss_period_size > 1024 * 1024)
+ return -ENOMEM;
+
runtime->oss.period_bytes = oss_period_size;
runtime->oss.period_frames = 1;
runtime->oss.periods = oss_periods;
@@ -1042,10 +1047,9 @@ static int snd_pcm_oss_change_params_loc
goto failure;
}
#endif
- oss_period_size *= oss_frame_size;
-
- oss_buffer_size = oss_period_size * runtime->oss.periods;
- if (oss_buffer_size < 0) {
+ oss_period_size = array_size(oss_period_size, oss_frame_size);
+ oss_buffer_size = array_size(oss_period_size, runtime->oss.periods);
+ if (oss_buffer_size <= 0) {
err = -EINVAL;
goto failure;
}
--- a/sound/core/oss/pcm_plugin.c
+++ b/sound/core/oss/pcm_plugin.c
@@ -61,7 +61,10 @@ static int snd_pcm_plugin_alloc(struct s
}
if ((width = snd_pcm_format_physical_width(format->format)) < 0)
return width;
- size = frames * format->channels * width;
+ size = array3_size(frames, format->channels, width);
+ /* check for too large period size once again */
+ if (size > 1024 * 1024)
+ return -ENOMEM;
if (snd_BUG_ON(size % 8))
return -ENXIO;
size /= 8;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 14/38] ALSA: usb-audio: add mapping for new Corsair Virtuoso SE
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 13/38] ALSA: oss: Fix PCM OSS buffer allocation overflow Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:04 ` [PATCH 5.10 15/38] ALSA: hda/realtek: Add quirk for Clevo NP70PNJ Greg Kroah-Hartman
` (32 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Reza Jahanbakhshi, Takashi Iwai
From: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
commit cd94df1795418056a19ff4cb44eadfc18ac99a57 upstream.
New device id for Corsair Virtuoso SE RGB Wireless that currently is not
in the mixer_map. This entry in the mixer_map is necessary in order to
label its mixer appropriately and allow userspace to pick the correct
volume controls. For instance, my own Corsair Virtuoso SE RGB Wireless
headset has this new ID and consequently, the sidetone and volume are not
working correctly without this change.
> sudo lsusb -v | grep -i corsair
Bus 007 Device 011: ID 1b1c:0a40 Corsair CORSAIR VIRTUOSO SE Wireless Gam
idVendor 0x1b1c Corsair
iManufacturer 1 Corsair
iProduct 2 CORSAIR VIRTUOSO SE Wireless Gaming Headset
Signed-off-by: Reza Jahanbakhshi <reza.jahanbakhshi@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220304212303.195949-1-reza.jahanbakhshi@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer_maps.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/sound/usb/mixer_maps.c
+++ b/sound/usb/mixer_maps.c
@@ -543,6 +543,16 @@ static const struct usbmix_ctl_map usbmi
.map = scms_usb3318_map,
},
{
+ /* Corsair Virtuoso SE Latest (wired mode) */
+ .id = USB_ID(0x1b1c, 0x0a3f),
+ .map = corsair_virtuoso_map,
+ },
+ {
+ /* Corsair Virtuoso SE Latest (wireless mode) */
+ .id = USB_ID(0x1b1c, 0x0a40),
+ .map = corsair_virtuoso_map,
+ },
+ {
.id = USB_ID(0x30be, 0x0101), /* Schiit Hel */
.ignore_ctl_error = 1,
},
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 15/38] ALSA: hda/realtek: Add quirk for Clevo NP70PNJ
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 14/38] ALSA: usb-audio: add mapping for new Corsair Virtuoso SE Greg Kroah-Hartman
@ 2022-03-25 15:04 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 16/38] ALSA: hda/realtek: Add quirk for Clevo NP50PNJ Greg Kroah-Hartman
` (31 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:04 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tim Crawford, Takashi Iwai
From: Tim Crawford <tcrawford@system76.com>
commit 0c20fce13e6e111463e3a15ce3cf6713fe518388 upstream.
Fixes headset detection on Clevo NP70PNJ.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220304170840.3351-1-tcrawford@system76.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8884,6 +8884,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1558, 0x8561, "System76 Gazelle (gaze14)", ALC269_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1558, 0x8562, "Clevo NH[5|7][0-9]RZ[Q]", ALC269_FIXUP_DMIC),
SND_PCI_QUIRK(0x1558, 0x8668, "Clevo NP50B[BE]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x867d, "Clevo NP7[01]PN[HJK]", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x8680, "Clevo NJ50LU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x8686, "Clevo NH50[CZ]U", ALC256_FIXUP_MIC_NO_PRESENCE_AND_RESUME),
SND_PCI_QUIRK(0x1558, 0x8a20, "Clevo NH55DCQ-Y", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 16/38] ALSA: hda/realtek: Add quirk for Clevo NP50PNJ
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2022-03-25 15:04 ` [PATCH 5.10 15/38] ALSA: hda/realtek: Add quirk for Clevo NP70PNJ Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 17/38] ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671 Greg Kroah-Hartman
` (30 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tim Crawford, Takashi Iwai
From: Tim Crawford <tcrawford@system76.com>
commit 9cb727506704b5323998047789fc871e64a6aa14 upstream.
Fixes headset detection on Clevo NP50PNJ.
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220307193229.5141-1-tcrawford@system76.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8884,6 +8884,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1558, 0x8561, "System76 Gazelle (gaze14)", ALC269_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1558, 0x8562, "Clevo NH[5|7][0-9]RZ[Q]", ALC269_FIXUP_DMIC),
SND_PCI_QUIRK(0x1558, 0x8668, "Clevo NP50B[BE]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x866d, "Clevo NP5[05]PN[HJK]", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x867d, "Clevo NP7[01]PN[HJK]", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x8680, "Clevo NJ50LU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x8686, "Clevo NH50[CZ]U", ALC256_FIXUP_MIC_NO_PRESENCE_AND_RESUME),
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 17/38] ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 16/38] ALSA: hda/realtek: Add quirk for Clevo NP50PNJ Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 18/38] ALSA: hda/realtek: Add quirk for ASUS GA402 Greg Kroah-Hartman
` (29 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, huangwenhui, Takashi Iwai
From: huangwenhui <huangwenhuia@uniontech.com>
commit 882bd07f564f97fca6e42ce6ce627ce24ce1ef5a upstream.
On a HP 288 Pro G8, the front mic could not be detected.In order to
get it working, the pin configuration needs to be set correctly, and
the ALC671_FIXUP_HP_HEADSET_MIC2 fixup needs to be applied.
Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220311093836.20754-1-huangwenhuia@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -10841,6 +10841,7 @@ static const struct snd_pci_quirk alc662
SND_PCI_QUIRK(0x1028, 0x069f, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
SND_PCI_QUIRK(0x103c, 0x873e, "HP", ALC671_FIXUP_HP_HEADSET_MIC2),
+ SND_PCI_QUIRK(0x103c, 0x885f, "HP 288 Pro G8", ALC671_FIXUP_HP_HEADSET_MIC2),
SND_PCI_QUIRK(0x1043, 0x1080, "Asus UX501VW", ALC668_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50),
SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50),
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 18/38] ALSA: hda/realtek: Add quirk for ASUS GA402
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 17/38] ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671 Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 19/38] ALSA: pcm: Fix races among concurrent hw_params and hw_free calls Greg Kroah-Hartman
` (28 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jason Zheng, Takashi Iwai
From: Jason Zheng <jasonzheng2004@gmail.com>
commit b7557267c233b55d8e8d7ba4c68cf944fe2ec02c upstream.
ASUS GA402 requires a workaround to manage the routing of its 4 speakers
like the other ASUS models. Add a corresponding quirk entry to fix it.
Signed-off-by: Jason Zheng <jasonzheng2004@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220313092216.29858-1-jasonzheng2004@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8801,6 +8801,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS),
SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401),
SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401),
+ SND_PCI_QUIRK(0x1043, 0x1d42, "ASUS Zephyrus G14 2022", ALC289_FIXUP_ASUS_GA401),
SND_PCI_QUIRK(0x1043, 0x16b2, "ASUS GU603", ALC289_FIXUP_ASUS_GA401),
SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2),
SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC),
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 19/38] ALSA: pcm: Fix races among concurrent hw_params and hw_free calls
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 18/38] ALSA: hda/realtek: Add quirk for ASUS GA402 Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 20/38] ALSA: pcm: Fix races among concurrent read/write and buffer changes Greg Kroah-Hartman
` (27 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hu Jiahui, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 92ee3c60ec9fe64404dc035e7c41277d74aa26cb upstream.
Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF. Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.
This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths. Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.
Reported-by: Hu Jiahui <kirin.say@gmail.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/sound/pcm.h | 1
sound/core/pcm.c | 2 +
sound/core/pcm_native.c | 61 ++++++++++++++++++++++++++++++------------------
3 files changed, 42 insertions(+), 22 deletions(-)
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -398,6 +398,7 @@ struct snd_pcm_runtime {
wait_queue_head_t tsleep; /* transfer sleep */
struct fasync_struct *fasync;
bool stop_operating; /* sync_stop will be called */
+ struct mutex buffer_mutex; /* protect for buffer changes */
/* -- private section -- */
void *private_data;
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -969,6 +969,7 @@ int snd_pcm_attach_substream(struct snd_
init_waitqueue_head(&runtime->tsleep);
runtime->status->state = SNDRV_PCM_STATE_OPEN;
+ mutex_init(&runtime->buffer_mutex);
substream->runtime = runtime;
substream->private_data = pcm->private_data;
@@ -1002,6 +1003,7 @@ void snd_pcm_detach_substream(struct snd
} else {
substream->runtime = NULL;
}
+ mutex_destroy(&runtime->buffer_mutex);
kfree(runtime);
put_pid(substream->pid);
substream->pid = NULL;
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -667,33 +667,40 @@ static int snd_pcm_hw_params_choose(stru
return 0;
}
+#if IS_ENABLED(CONFIG_SND_PCM_OSS)
+#define is_oss_stream(substream) ((substream)->oss.oss)
+#else
+#define is_oss_stream(substream) false
+#endif
+
static int snd_pcm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
struct snd_pcm_runtime *runtime;
- int err, usecs;
+ int err = 0, usecs;
unsigned int bits;
snd_pcm_uframes_t frames;
if (PCM_RUNTIME_CHECK(substream))
return -ENXIO;
runtime = substream->runtime;
+ mutex_lock(&runtime->buffer_mutex);
snd_pcm_stream_lock_irq(substream);
switch (runtime->status->state) {
case SNDRV_PCM_STATE_OPEN:
case SNDRV_PCM_STATE_SETUP:
case SNDRV_PCM_STATE_PREPARED:
+ if (!is_oss_stream(substream) &&
+ atomic_read(&substream->mmap_count))
+ err = -EBADFD;
break;
default:
- snd_pcm_stream_unlock_irq(substream);
- return -EBADFD;
+ err = -EBADFD;
+ break;
}
snd_pcm_stream_unlock_irq(substream);
-#if IS_ENABLED(CONFIG_SND_PCM_OSS)
- if (!substream->oss.oss)
-#endif
- if (atomic_read(&substream->mmap_count))
- return -EBADFD;
+ if (err)
+ goto unlock;
snd_pcm_sync_stop(substream, true);
@@ -780,16 +787,21 @@ static int snd_pcm_hw_params(struct snd_
if ((usecs = period_to_usecs(runtime)) >= 0)
cpu_latency_qos_add_request(&substream->latency_pm_qos_req,
usecs);
- return 0;
+ err = 0;
_error:
- /* hardware might be unusable from this time,
- so we force application to retry to set
- the correct hardware parameter settings */
- snd_pcm_set_state(substream, SNDRV_PCM_STATE_OPEN);
- if (substream->ops->hw_free != NULL)
- substream->ops->hw_free(substream);
- if (substream->managed_buffer_alloc)
- snd_pcm_lib_free_pages(substream);
+ if (err) {
+ /* hardware might be unusable from this time,
+ * so we force application to retry to set
+ * the correct hardware parameter settings
+ */
+ snd_pcm_set_state(substream, SNDRV_PCM_STATE_OPEN);
+ if (substream->ops->hw_free != NULL)
+ substream->ops->hw_free(substream);
+ if (substream->managed_buffer_alloc)
+ snd_pcm_lib_free_pages(substream);
+ }
+ unlock:
+ mutex_unlock(&runtime->buffer_mutex);
return err;
}
@@ -829,26 +841,31 @@ static int do_hw_free(struct snd_pcm_sub
static int snd_pcm_hw_free(struct snd_pcm_substream *substream)
{
struct snd_pcm_runtime *runtime;
- int result;
+ int result = 0;
if (PCM_RUNTIME_CHECK(substream))
return -ENXIO;
runtime = substream->runtime;
+ mutex_lock(&runtime->buffer_mutex);
snd_pcm_stream_lock_irq(substream);
switch (runtime->status->state) {
case SNDRV_PCM_STATE_SETUP:
case SNDRV_PCM_STATE_PREPARED:
+ if (atomic_read(&substream->mmap_count))
+ result = -EBADFD;
break;
default:
- snd_pcm_stream_unlock_irq(substream);
- return -EBADFD;
+ result = -EBADFD;
+ break;
}
snd_pcm_stream_unlock_irq(substream);
- if (atomic_read(&substream->mmap_count))
- return -EBADFD;
+ if (result)
+ goto unlock;
result = do_hw_free(substream);
snd_pcm_set_state(substream, SNDRV_PCM_STATE_OPEN);
cpu_latency_qos_remove_request(&substream->latency_pm_qos_req);
+ unlock:
+ mutex_unlock(&runtime->buffer_mutex);
return result;
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 20/38] ALSA: pcm: Fix races among concurrent read/write and buffer changes
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 19/38] ALSA: pcm: Fix races among concurrent hw_params and hw_free calls Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 21/38] ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls Greg Kroah-Hartman
` (26 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit dca947d4d26dbf925a64a6cfb2ddbc035e831a3d upstream.
In the current PCM design, the read/write syscalls (as well as the
equivalent ioctls) are allowed before the PCM stream is running, that
is, at PCM PREPARED state. Meanwhile, we also allow to re-issue
hw_params and hw_free ioctl calls at the PREPARED state that may
change or free the buffers, too. The problem is that there is no
protection against those mix-ups.
This patch applies the previously introduced runtime->buffer_mutex to
the read/write operations so that the concurrent hw_params or hw_free
call can no longer interfere during the operation. The mutex is
unlocked before scheduling, so we don't take it too long.
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/pcm_lib.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -1871,9 +1871,11 @@ static int wait_for_avail(struct snd_pcm
if (avail >= runtime->twake)
break;
snd_pcm_stream_unlock_irq(substream);
+ mutex_unlock(&runtime->buffer_mutex);
tout = schedule_timeout(wait_time);
+ mutex_lock(&runtime->buffer_mutex);
snd_pcm_stream_lock_irq(substream);
set_current_state(TASK_INTERRUPTIBLE);
switch (runtime->status->state) {
@@ -2167,6 +2169,7 @@ snd_pcm_sframes_t __snd_pcm_lib_xfer(str
nonblock = !!(substream->f_flags & O_NONBLOCK);
+ mutex_lock(&runtime->buffer_mutex);
snd_pcm_stream_lock_irq(substream);
err = pcm_accessible_state(runtime);
if (err < 0)
@@ -2254,6 +2257,7 @@ snd_pcm_sframes_t __snd_pcm_lib_xfer(str
if (xfer > 0 && err >= 0)
snd_pcm_update_state(substream, runtime);
snd_pcm_stream_unlock_irq(substream);
+ mutex_unlock(&runtime->buffer_mutex);
return xfer > 0 ? (snd_pcm_sframes_t)xfer : err;
}
EXPORT_SYMBOL(__snd_pcm_lib_xfer);
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 21/38] ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 20/38] ALSA: pcm: Fix races among concurrent read/write and buffer changes Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 22/38] ALSA: pcm: Fix races among concurrent prealloc proc writes Greg Kroah-Hartman
` (25 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 3c3201f8c7bb77eb53b08a3ca8d9a4ddc500b4c0 upstream.
Like the previous fixes to hw_params and hw_free ioctl races, we need
to paper over the concurrent prepare ioctl calls against hw_params and
hw_free, too.
This patch implements the locking with the existing
runtime->buffer_mutex for prepare ioctls. Unlike the previous case
for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is
performed to the linked streams, hence the lock can't be applied
simply on the top. For tracking the lock in each linked substream, we
modify snd_pcm_action_group() slightly and apply the buffer_mutex for
the case stream_lock=false (formerly there was no lock applied)
there.
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/pcm_native.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -1171,15 +1171,17 @@ struct action_ops {
static int snd_pcm_action_group(const struct action_ops *ops,
struct snd_pcm_substream *substream,
snd_pcm_state_t state,
- bool do_lock)
+ bool stream_lock)
{
struct snd_pcm_substream *s = NULL;
struct snd_pcm_substream *s1;
int res = 0, depth = 1;
snd_pcm_group_for_each_entry(s, substream) {
- if (do_lock && s != substream) {
- if (s->pcm->nonatomic)
+ if (s != substream) {
+ if (!stream_lock)
+ mutex_lock_nested(&s->runtime->buffer_mutex, depth);
+ else if (s->pcm->nonatomic)
mutex_lock_nested(&s->self_group.mutex, depth);
else
spin_lock_nested(&s->self_group.lock, depth);
@@ -1207,18 +1209,18 @@ static int snd_pcm_action_group(const st
ops->post_action(s, state);
}
_unlock:
- if (do_lock) {
- /* unlock streams */
- snd_pcm_group_for_each_entry(s1, substream) {
- if (s1 != substream) {
- if (s1->pcm->nonatomic)
- mutex_unlock(&s1->self_group.mutex);
- else
- spin_unlock(&s1->self_group.lock);
- }
- if (s1 == s) /* end */
- break;
+ /* unlock streams */
+ snd_pcm_group_for_each_entry(s1, substream) {
+ if (s1 != substream) {
+ if (!stream_lock)
+ mutex_unlock(&s1->runtime->buffer_mutex);
+ else if (s1->pcm->nonatomic)
+ mutex_unlock(&s1->self_group.mutex);
+ else
+ spin_unlock(&s1->self_group.lock);
}
+ if (s1 == s) /* end */
+ break;
}
return res;
}
@@ -1348,10 +1350,12 @@ static int snd_pcm_action_nonatomic(cons
/* Guarantee the group members won't change during non-atomic action */
down_read(&snd_pcm_link_rwsem);
+ mutex_lock(&substream->runtime->buffer_mutex);
if (snd_pcm_stream_linked(substream))
res = snd_pcm_action_group(ops, substream, state, false);
else
res = snd_pcm_action_single(ops, substream, state);
+ mutex_unlock(&substream->runtime->buffer_mutex);
up_read(&snd_pcm_link_rwsem);
return res;
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 22/38] ALSA: pcm: Fix races among concurrent prealloc proc writes
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 21/38] ALSA: pcm: Fix races among concurrent prepare and hw_params/hw_free calls Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 23/38] ALSA: pcm: Add stream lock during PCM reset ioctl operations Greg Kroah-Hartman
` (24 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 69534c48ba8ce552ce383b3dfdb271ffe51820c3 upstream.
We have no protection against concurrent PCM buffer preallocation
changes via proc files, and it may potentially lead to UAF or some
weird problem. This patch applies the PCM open_mutex to the proc
write operation for avoiding the racy proc writes and the PCM stream
open (and further operations).
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/pcm_memory.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/sound/core/pcm_memory.c
+++ b/sound/core/pcm_memory.c
@@ -164,19 +164,20 @@ static void snd_pcm_lib_preallocate_proc
size_t size;
struct snd_dma_buffer new_dmab;
+ mutex_lock(&substream->pcm->open_mutex);
if (substream->runtime) {
buffer->error = -EBUSY;
- return;
+ goto unlock;
}
if (!snd_info_get_line(buffer, line, sizeof(line))) {
snd_info_get_str(str, line, sizeof(str));
size = simple_strtoul(str, NULL, 10) * 1024;
if ((size != 0 && size < 8192) || size > substream->dma_max) {
buffer->error = -EINVAL;
- return;
+ goto unlock;
}
if (substream->dma_buffer.bytes == size)
- return;
+ goto unlock;
memset(&new_dmab, 0, sizeof(new_dmab));
new_dmab.dev = substream->dma_buffer.dev;
if (size > 0) {
@@ -185,7 +186,7 @@ static void snd_pcm_lib_preallocate_proc
substream->dma_buffer.dev.dev,
size, &new_dmab) < 0) {
buffer->error = -ENOMEM;
- return;
+ goto unlock;
}
substream->buffer_bytes_max = size;
} else {
@@ -197,6 +198,8 @@ static void snd_pcm_lib_preallocate_proc
} else {
buffer->error = -EINVAL;
}
+ unlock:
+ mutex_unlock(&substream->pcm->open_mutex);
}
static inline void preallocate_info_init(struct snd_pcm_substream *substream)
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 23/38] ALSA: pcm: Add stream lock during PCM reset ioctl operations
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 22/38] ALSA: pcm: Fix races among concurrent prealloc proc writes Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 24/38] ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB Greg Kroah-Hartman
` (23 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jaroslav Kysela, Takashi Iwai
From: Takashi Iwai <tiwai@suse.de>
commit 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c upstream.
snd_pcm_reset() is a non-atomic operation, and it's allowed to run
during the PCM stream running. It implies that the manipulation of
hw_ptr and other parameters might be racy.
This patch adds the PCM stream lock at appropriate places in
snd_pcm_*_reset() actions for covering that.
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/pcm_native.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -1850,11 +1850,13 @@ static int snd_pcm_do_reset(struct snd_p
int err = snd_pcm_ops_ioctl(substream, SNDRV_PCM_IOCTL1_RESET, NULL);
if (err < 0)
return err;
+ snd_pcm_stream_lock_irq(substream);
runtime->hw_ptr_base = 0;
runtime->hw_ptr_interrupt = runtime->status->hw_ptr -
runtime->status->hw_ptr % runtime->period_size;
runtime->silence_start = runtime->status->hw_ptr;
runtime->silence_filled = 0;
+ snd_pcm_stream_unlock_irq(substream);
return 0;
}
@@ -1862,10 +1864,12 @@ static void snd_pcm_post_reset(struct sn
snd_pcm_state_t state)
{
struct snd_pcm_runtime *runtime = substream->runtime;
+ snd_pcm_stream_lock_irq(substream);
runtime->control->appl_ptr = runtime->status->hw_ptr;
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
runtime->silence_size > 0)
snd_pcm_playback_silence(substream, ULONG_MAX);
+ snd_pcm_stream_unlock_irq(substream);
}
static const struct action_ops snd_pcm_action_reset = {
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 24/38] ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 23/38] ALSA: pcm: Add stream lock during PCM reset ioctl operations Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 25/38] ALSA: cmipci: Restore aux vol on suspend/resume Greg Kroah-Hartman
` (22 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lars-Peter Clausen, Takashi Iwai
From: Lars-Peter Clausen <lars@metafoo.de>
commit 0f306cca42fe879694fb5e2382748c43dc9e0196 upstream.
For the RODE NT-USB the lowest Playback mixer volume setting mutes the
audio output. But it is not reported as such causing e.g. PulseAudio to
accidentally mute the device when selecting a low volume.
Fix this by applying the existing quirk for this kind of issue when the
device is detected.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220311201400.235892-1-lars@metafoo.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/mixer_quirks.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -3135,9 +3135,10 @@ void snd_usb_mixer_fu_apply_quirk(struct
if (unitid == 7 && cval->control == UAC_FU_VOLUME)
snd_dragonfly_quirk_db_scale(mixer, cval, kctl);
break;
- /* lowest playback value is muted on C-Media devices */
- case USB_ID(0x0d8c, 0x000c):
- case USB_ID(0x0d8c, 0x0014):
+ /* lowest playback value is muted on some devices */
+ case USB_ID(0x0d8c, 0x000c): /* C-Media */
+ case USB_ID(0x0d8c, 0x0014): /* C-Media */
+ case USB_ID(0x19f7, 0x0003): /* RODE NT-USB */
if (strstr(kctl->id.name, "Playback"))
cval->min_mute = 1;
break;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 25/38] ALSA: cmipci: Restore aux vol on suspend/resume
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 24/38] ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 26/38] ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec Greg Kroah-Hartman
` (21 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jonathan Teh, Takashi Iwai
From: Jonathan Teh <jonathan.teh@outlook.com>
commit c14231cc04337c2c2a937db084af342ce704dbde upstream.
Save and restore CM_REG_AUX_VOL instead of register 0x24 twice on
suspend/resume.
Tested on CMI8738LX.
Fixes: cb60e5f5b2b1 ("[ALSA] cmipci - Add PM support")
Signed-off-by: Jonathan Teh <jonathan.teh@outlook.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/DBAPR04MB7366CB3EA9C8521C35C56E8B920E9@DBAPR04MB7366.eurprd04.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/cmipci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/sound/pci/cmipci.c
+++ b/sound/pci/cmipci.c
@@ -302,7 +302,6 @@ MODULE_PARM_DESC(joystick_port, "Joystic
#define CM_MICGAINZ 0x01 /* mic boost */
#define CM_MICGAINZ_SHIFT 0
-#define CM_REG_MIXER3 0x24
#define CM_REG_AUX_VOL 0x26
#define CM_VAUXL_MASK 0xf0
#define CM_VAUXR_MASK 0x0f
@@ -3291,7 +3290,7 @@ static void snd_cmipci_remove(struct pci
*/
static const unsigned char saved_regs[] = {
CM_REG_FUNCTRL1, CM_REG_CHFORMAT, CM_REG_LEGACY_CTRL, CM_REG_MISC_CTRL,
- CM_REG_MIXER0, CM_REG_MIXER1, CM_REG_MIXER2, CM_REG_MIXER3, CM_REG_PLL,
+ CM_REG_MIXER0, CM_REG_MIXER1, CM_REG_MIXER2, CM_REG_AUX_VOL, CM_REG_PLL,
CM_REG_CH0_FRAME1, CM_REG_CH0_FRAME2,
CM_REG_CH1_FRAME1, CM_REG_CH1_FRAME2, CM_REG_EXT_MISC,
CM_REG_INT_STATUS, CM_REG_INT_HLDCLR, CM_REG_FUNCTRL0,
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 26/38] ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 25/38] ALSA: cmipci: Restore aux vol on suspend/resume Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 27/38] drivers: net: xgene: Fix regression in CRC stripping Greg Kroah-Hartman
` (20 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Giacomo Guiduzzi, Paolo Valente,
Takashi Iwai
From: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
commit 17aaf0193392cb3451bf0ac75ba396ec4cbded6e upstream.
Tests 72 and 78 for ALSA in kselftest fail due to reading
inconsistent values from some devices on a VirtualBox
Virtual Machine using the snd_intel8x0 driver for the AC'97
Audio Controller device.
Taking for example test number 72, this is what the test reports:
"Surround Playback Volume.0 expected 1 but read 0, is_volatile 0"
"Surround Playback Volume.1 expected 0 but read 1, is_volatile 0"
These errors repeat for each value from 0 to 31.
Taking a look at these error messages it is possible to notice
that the written values are read back swapped.
When the write is performed, these values are initially stored in
an array used to sanity-check them and write them in the pcmreg
array. To write them, the two one-byte values are packed together
in a two-byte variable through bitwise operations: the first
value is shifted left by one byte and the second value is stored in the
right byte through a bitwise OR. When reading the values back,
right shifts are performed to retrieve the previously stored
bytes. These shifts are executed in the wrong order, thus
reporting the values swapped as shown above.
This patch fixes this mistake by reversing the read
operations' order.
Signed-off-by: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/ac97/ac97_codec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/sound/pci/ac97/ac97_codec.c
+++ b/sound/pci/ac97/ac97_codec.c
@@ -938,8 +938,8 @@ static int snd_ac97_ad18xx_pcm_get_volum
int codec = kcontrol->private_value & 3;
mutex_lock(&ac97->page_mutex);
- ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31);
- ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31);
+ ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31);
+ ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31);
mutex_unlock(&ac97->page_mutex);
return 0;
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 27/38] drivers: net: xgene: Fix regression in CRC stripping
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 26/38] ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 28/38] netfilter: nf_tables: initialize registers in nft_do_chain() Greg Kroah-Hartman
` (19 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Stephane Graber, Jakub Kicinski
From: Stephane Graber <stgraber@ubuntu.com>
commit e9e6faeafaa00da1851bcf47912b0f1acae666b4 upstream.
All packets on ingress (except for jumbo) are terminated with a 4-bytes
CRC checksum. It's the responsability of the driver to strip those 4
bytes. Unfortunately a change dating back to March 2017 re-shuffled some
code and made the CRC stripping code effectively dead.
This change re-orders that part a bit such that the datalen is
immediately altered if needed.
Fixes: 4902a92270fb ("drivers: net: xgene: Add workaround for errata 10GE_8/ENET_11")
Cc: stable@vger.kernel.org
Signed-off-by: Stephane Graber <stgraber@ubuntu.com>
Tested-by: Stephane Graber <stgraber@ubuntu.com>
Link: https://lore.kernel.org/r/20220322224205.752795-1-stgraber@ubuntu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -696,6 +696,12 @@ static int xgene_enet_rx_frame(struct xg
buf_pool->rx_skb[skb_index] = NULL;
datalen = xgene_enet_get_data_len(le64_to_cpu(raw_desc->m1));
+
+ /* strip off CRC as HW isn't doing this */
+ nv = GET_VAL(NV, le64_to_cpu(raw_desc->m0));
+ if (!nv)
+ datalen -= 4;
+
skb_put(skb, datalen);
prefetch(skb->data - NET_IP_ALIGN);
skb->protocol = eth_type_trans(skb, ndev);
@@ -717,12 +723,8 @@ static int xgene_enet_rx_frame(struct xg
}
}
- nv = GET_VAL(NV, le64_to_cpu(raw_desc->m0));
- if (!nv) {
- /* strip off CRC as HW isn't doing this */
- datalen -= 4;
+ if (!nv)
goto skip_jumbo;
- }
slots = page_pool->slots - 1;
head = page_pool->head;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 28/38] netfilter: nf_tables: initialize registers in nft_do_chain()
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 27/38] drivers: net: xgene: Fix regression in CRC stripping Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-26 20:10 ` Pavel Machek
2022-03-25 15:05 ` [PATCH 5.10 29/38] ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 board Greg Kroah-Hartman
` (18 subsequent siblings)
46 siblings, 1 reply; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pablo Neira Ayuso
From: Pablo Neira Ayuso <pablo@netfilter.org>
commit 4c905f6740a365464e91467aa50916555b28213d upstream.
Initialize registers to avoid stack leak into userspace.
Fixes: 96518518cc41 ("netfilter: add nftables")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/nf_tables_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netfilter/nf_tables_core.c
+++ b/net/netfilter/nf_tables_core.c
@@ -162,7 +162,7 @@ nft_do_chain(struct nft_pktinfo *pkt, vo
struct nft_rule *const *rules;
const struct nft_rule *rule;
const struct nft_expr *expr, *last;
- struct nft_regs regs;
+ struct nft_regs regs = {};
unsigned int stackptr = 0;
struct nft_jumpstack jumpstack[NFT_JUMP_STACK_SIZE];
bool genbit = READ_ONCE(net->nft.gencursor);
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 28/38] netfilter: nf_tables: initialize registers in nft_do_chain()
2022-03-25 15:05 ` [PATCH 5.10 28/38] netfilter: nf_tables: initialize registers in nft_do_chain() Greg Kroah-Hartman
@ 2022-03-26 20:10 ` Pavel Machek
0 siblings, 0 replies; 65+ messages in thread
From: Pavel Machek @ 2022-03-26 20:10 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, stable, Pablo Neira Ayuso
[-- Attachment #1: Type: text/plain, Size: 933 bytes --]
On Fri 2022-03-25 16:05:12, Greg Kroah-Hartman wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
>
> commit 4c905f6740a365464e91467aa50916555b28213d upstream.
>
> Initialize registers to avoid stack leak into userspace.
For that, memset() is better, due to padding. There is no padding in
the struct AFAICT, still memset would be better for robustness.
> --- a/net/netfilter/nf_tables_core.c
> +++ b/net/netfilter/nf_tables_core.c
> @@ -162,7 +162,7 @@ nft_do_chain(struct nft_pktinfo *pkt, vo
> struct nft_rule *const *rules;
> const struct nft_rule *rule;
> const struct nft_expr *expr, *last;
> - struct nft_regs regs;
> + struct nft_regs regs = {};
> unsigned int stackptr = 0;
> struct nft_jumpstack jumpstack[NFT_JUMP_STACK_SIZE];
> bool genbit = READ_ONCE(net->nft.gencursor);
>
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread
* [PATCH 5.10 29/38] ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 board
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 28/38] netfilter: nf_tables: initialize registers in nft_do_chain() Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 30/38] ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3 Greg Kroah-Hartman
` (17 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Cilissen, Hans de Goede,
Rafael J. Wysocki
From: Mark Cilissen <mark@yotsuba.nl>
commit e702196bf85778f2c5527ca47f33ef2e2fca8297 upstream.
On this board the ACPI RSDP structure points to both a RSDT and an XSDT,
but the XSDT points to a truncated FADT. This causes all sorts of trouble
and usually a complete failure to boot after the following error occurs:
ACPI Error: Unsupported address space: 0x20 (*/hwregs-*)
ACPI Error: AE_SUPPORT, Unable to initialize fixed events (*/evevent-*)
ACPI: Unable to start ACPI Interpreter
This leaves the ACPI implementation in such a broken state that subsequent
kernel subsystem initialisations go wrong, resulting in among others
mismapped PCI memory, SATA and USB enumeration failures, and freezes.
As this is an older embedded platform that will likely never see any BIOS
updates to address this issue and its default shipping OS only complies to
ACPI 1.0, work around this by forcing `acpi=rsdt`. This patch, applied on
top of Linux 5.10.102, was confirmed on real hardware to fix the issue.
Signed-off-by: Mark Cilissen <mark@yotsuba.nl>
Cc: All applicable <stable@vger.kernel.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/acpi/boot.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1340,6 +1340,17 @@ static int __init disable_acpi_pci(const
return 0;
}
+static int __init disable_acpi_xsdt(const struct dmi_system_id *d)
+{
+ if (!acpi_force) {
+ pr_notice("%s detected: force use of acpi=rsdt\n", d->ident);
+ acpi_gbl_do_not_use_xsdt = TRUE;
+ } else {
+ pr_notice("Warning: DMI blacklist says broken, but acpi XSDT forced\n");
+ }
+ return 0;
+}
+
static int __init dmi_disable_acpi(const struct dmi_system_id *d)
{
if (!acpi_force) {
@@ -1464,6 +1475,19 @@ static const struct dmi_system_id acpi_d
DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
},
},
+ /*
+ * Boxes that need ACPI XSDT use disabled due to corrupted tables
+ */
+ {
+ .callback = disable_acpi_xsdt,
+ .ident = "Advantech DAC-BJ01",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Bearlake CRB Board"),
+ DMI_MATCH(DMI_BIOS_VERSION, "V1.12"),
+ DMI_MATCH(DMI_BIOS_DATE, "02/01/2011"),
+ },
+ },
{}
};
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 30/38] ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 29/38] ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 board Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 31/38] ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU Greg Kroah-Hartman
` (16 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maximilian Luz, Rafael J. Wysocki
From: Maximilian Luz <luzmaximilian@gmail.com>
commit 7dacee0b9efc8bd061f097b1a8d4daa6591af0c6 upstream.
For some reason, the Microsoft Surface Go 3 uses the standard ACPI
interface for battery information, but does not use the standard PNP0C0A
HID. Instead it uses MSHW0146 as identifier. Add that ID to the driver
as this seems to work well.
Additionally, the power state is not updated immediately after the AC
has been (un-)plugged, so add the respective quirk for that.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/battery.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -66,6 +66,10 @@ MODULE_PARM_DESC(cache_time, "cache time
static const struct acpi_device_id battery_device_ids[] = {
{"PNP0C0A", 0},
+
+ /* Microsoft Surface Go 3 */
+ {"MSHW0146", 0},
+
{"", 0},
};
@@ -1171,6 +1175,14 @@ static const struct dmi_system_id bat_dm
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad"),
},
},
+ {
+ /* Microsoft Surface Go 3 */
+ .callback = battery_notification_delay_quirk,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Surface Go 3"),
+ },
+ },
{},
};
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 31/38] ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 30/38] ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3 Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 32/38] crypto: qat - disable registration of algorithms Greg Kroah-Hartman
` (15 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Werner Sembach, Rafael J. Wysocki
From: Werner Sembach <wse@tuxedocomputers.com>
commit c844d22fe0c0b37dc809adbdde6ceb6462c43acf upstream.
Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a working
native and video interface. However the default detection mechanism first
registers the video interface before unregistering it again and switching
to the native interface during boot. This results in a dangling SBIOS
request for backlight change for some reason, causing the backlight to
switch to ~2% once per boot on the first power cord connect or disconnect
event. Setting the native interface explicitly circumvents this buggy
behaviour by avoiding the unregistering process.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/video_detect.c | 75 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 75 insertions(+)
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -409,6 +409,81 @@ static const struct dmi_system_id video_
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+ /*
+ * Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
+ * working native and video interface. However the default detection
+ * mechanism first registers the video interface before unregistering
+ * it again and switching to the native interface during boot. This
+ * results in a dangling SBIOS request for backlight change for some
+ * reason, causing the backlight to switch to ~2% once per boot on the
+ * first power cord connect or disconnect event. Setting the native
+ * interface explicitly circumvents this buggy behaviour, by avoiding
+ * the unregistering process.
+ */
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xRU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xRU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xRU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xRU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+ DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xRU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+ DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xNU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xNU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ .ident = "Clevo NL5xNU",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
+ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+ },
+ },
/*
* Desktops which falsely report a backlight and which our heuristics
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 32/38] crypto: qat - disable registration of algorithms
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 31/38] ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 33/38] Revert "ath: add support for special 0x0 regulatory domain" Greg Kroah-Hartman
` (14 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Giovanni Cabiddu, Herbert Xu
From: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
commit 8893d27ffcaf6ec6267038a177cb87bcde4dd3de upstream.
The implementations of aead and skcipher in the QAT driver do not
support properly requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set.
If the HW queue is full, the driver returns -EBUSY but does not enqueue
the request.
This can result in applications like dm-crypt waiting indefinitely for a
completion of a request that was never submitted to the hardware.
To avoid this problem, disable the registration of all crypto algorithms
in the QAT driver by setting the number of crypto instances to 0 at
configuration time.
Cc: stable@vger.kernel.org
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/qat/qat_common/qat_crypto.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/crypto/qat/qat_common/qat_crypto.c
+++ b/drivers/crypto/qat/qat_common/qat_crypto.c
@@ -126,6 +126,14 @@ int qat_crypto_dev_config(struct adf_acc
goto err;
if (adf_cfg_section_add(accel_dev, "Accelerator0"))
goto err;
+
+ /* Temporarily set the number of crypto instances to zero to avoid
+ * registering the crypto algorithms.
+ * This will be removed when the algorithms will support the
+ * CRYPTO_TFM_REQ_MAY_BACKLOG flag
+ */
+ instances = 0;
+
for (i = 0; i < instances; i++) {
val = i;
snprintf(key, sizeof(key), ADF_CY "%d" ADF_RING_BANK_NUM, i);
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 33/38] Revert "ath: add support for special 0x0 regulatory domain"
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 32/38] crypto: qat - disable registration of algorithms Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 34/38] rcu: Dont deboost before reporting expedited quiescent state Greg Kroah-Hartman
` (13 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wen Gong, Brian Norris, Kalle Valo
From: Brian Norris <briannorris@chromium.org>
commit 1ec7ed5163c70a0d040150d2279f932c7e7c143f upstream.
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Users are reporting regressions in regulatory domain detection and
channel availability.
The problem this was trying to resolve was fixed in firmware anyway:
QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042
https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc604f8eff82552
Link: https://bbs.archlinux.org/viewtopic.php?id=254535
Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html
Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html
Link: https://lore.kernel.org/all/1c160dfb-6ccc-b4d6-76f6-4364e0adb6dd@reox.at/
Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc: <stable@vger.kernel.org>
Cc: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20200527165718.129307-1-briannorris@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/regd.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulator
/*
* Some users have reported their EEPROM programmed with
- * 0x8000 or 0x0 set, this is not a supported regulatory
- * domain but since we have more than one user with it we
- * need a solution for them. We default to 0x64, which is
- * the default Atheros world regulatory domain.
+ * 0x8000 set, this is not a supported regulatory domain
+ * but since we have more than one user with it we need
+ * a solution for them. We default to 0x64, which is the
+ * default Atheros world regulatory domain.
*/
static void ath_regd_sanitize(struct ath_regulatory *reg)
{
- if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
+ if (reg->current_rd != COUNTRY_ERD_FLAG)
return;
printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
reg->current_rd = 0x64;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 34/38] rcu: Dont deboost before reporting expedited quiescent state
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 33/38] Revert "ath: add support for special 0x0 regulatory domain" Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 35/38] mac80211: fix potential double free on mesh join Greg Kroah-Hartman
` (12 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tim Murray, Joel Fernandes,
Neeraj Upadhyay, Uladzislau Rezki (Sony),
Todd Kjos, Sandeep Patil, Paul E. McKenney
From: Paul E. McKenney <paulmck@kernel.org>
commit 10c535787436d62ea28156a4b91365fd89b5a432 upstream.
Currently rcu_preempt_deferred_qs_irqrestore() releases rnp->boost_mtx
before reporting the expedited quiescent state. Under heavy real-time
load, this can result in this function being preempted before the
quiescent state is reported, which can in turn prevent the expedited grace
period from completing. Tim Murray reports that the resulting expedited
grace periods can take hundreds of milliseconds and even more than one
second, when they should normally complete in less than a millisecond.
This was fine given that there were no particular response-time
constraints for synchronize_rcu_expedited(), as it was designed
for throughput rather than latency. However, some users now need
sub-100-millisecond response-time constratints.
This patch therefore follows Neeraj's suggestion (seconded by Tim and
by Uladzislau Rezki) of simply reversing the two operations.
Reported-by: Tim Murray <timmurray@google.com>
Reported-by: Joel Fernandes <joelaf@google.com>
Reported-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Reviewed-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Tested-by: Tim Murray <timmurray@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: <stable@vger.kernel.org> # 5.4.x
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tree_plugin.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -531,16 +531,17 @@ rcu_preempt_deferred_qs_irqrestore(struc
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
}
- /* Unboost if we were boosted. */
- if (IS_ENABLED(CONFIG_RCU_BOOST) && drop_boost_mutex)
- rt_mutex_futex_unlock(&rnp->boost_mtx);
-
/*
* If this was the last task on the expedited lists,
* then we need to report up the rcu_node hierarchy.
*/
if (!empty_exp && empty_exp_now)
rcu_report_exp_rnp(rnp, true);
+
+ /* Unboost if we were boosted. */
+ if (IS_ENABLED(CONFIG_RCU_BOOST) && drop_boost_mutex)
+ rt_mutex_futex_unlock(&rnp->boost_mtx);
+
} else {
local_irq_restore(flags);
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 35/38] mac80211: fix potential double free on mesh join
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 34/38] rcu: Dont deboost before reporting expedited quiescent state Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 36/38] tpm: use try_get_ops() in tpm-space.c Greg Kroah-Hartman
` (11 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Matthias Kretschmer,
Linus Lüssing, Johannes Berg
From: Linus Lüssing <ll@simonwunderlich.de>
commit 4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3 upstream.
While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving
mesh") fixed a memory leak on mesh leave / teardown it introduced a
potential memory corruption caused by a double free when rejoining the
mesh:
ieee80211_leave_mesh()
-> kfree(sdata->u.mesh.ie);
...
ieee80211_join_mesh()
-> copy_mesh_setup()
-> old_ie = ifmsh->ie;
-> kfree(old_ie);
This double free / kernel panics can be reproduced by using wpa_supplicant
with an encrypted mesh (if set up without encryption via "iw" then
ifmsh->ie is always NULL, which avoids this issue). And then calling:
$ iw dev mesh0 mesh leave
$ iw dev mesh0 mesh join my-mesh
Note that typically these commands are not used / working when using
wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
the memory corruption, too.
The issue was first observed in an application which was not using
wpa_supplicant but "Senf" instead, which implements its own calls to
nl80211.
Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
join function and leaving it solely up to the mesh leave to free the
mesh IE.
Cc: stable@vger.kernel.org
Fixes: 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh")
Reported-by: Matthias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Linus Lüssing <ll@simonwunderlich.de>
Tested-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Link: https://lore.kernel.org/r/20220310183513.28589-1-linus.luessing@c0d3.blue
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/cfg.c | 3 ---
1 file changed, 3 deletions(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2076,14 +2076,12 @@ static int copy_mesh_setup(struct ieee80
const struct mesh_setup *setup)
{
u8 *new_ie;
- const u8 *old_ie;
struct ieee80211_sub_if_data *sdata = container_of(ifmsh,
struct ieee80211_sub_if_data, u.mesh);
int i;
/* allocate information elements */
new_ie = NULL;
- old_ie = ifmsh->ie;
if (setup->ie_len) {
new_ie = kmemdup(setup->ie, setup->ie_len,
@@ -2093,7 +2091,6 @@ static int copy_mesh_setup(struct ieee80
}
ifmsh->ie_len = setup->ie_len;
ifmsh->ie = new_ie;
- kfree(old_ie);
/* now copy the rest of the setup parameters */
ifmsh->mesh_id_len = setup->mesh_id_len;
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 36/38] tpm: use try_get_ops() in tpm-space.c
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 35/38] mac80211: fix potential double free on mesh join Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 37/38] wcn36xx: Differentiate wcn3660 from wcn3620 Greg Kroah-Hartman
` (10 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, James Bottomley, Jarkko Sakkinen
From: James Bottomley <James.Bottomley@HansenPartnership.com>
commit fb5abce6b2bb5cb3d628aaa63fa821da8c4600f9 upstream.
As part of the series conversion to remove nested TPM operations:
https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/
exposure of the chip->tpm_mutex was removed from much of the upper
level code. In this conversion, tpm2_del_space() was missed. This
didn't matter much because it's usually called closely after a
converted operation, so there's only a very tiny race window where the
chip can be removed before the space flushing is done which causes a
NULL deref on the mutex. However, there are reports of this window
being hit in practice, so fix this by converting tpm2_del_space() to
use tpm_try_get_ops(), which performs all the teardown checks before
acquring the mutex.
Cc: stable@vger.kernel.org # 5.4.x
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/tpm/tpm2-space.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -58,12 +58,12 @@ int tpm2_init_space(struct tpm_space *sp
void tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space)
{
- mutex_lock(&chip->tpm_mutex);
- if (!tpm_chip_start(chip)) {
+
+ if (tpm_try_get_ops(chip) == 0) {
tpm2_flush_sessions(chip, space);
- tpm_chip_stop(chip);
+ tpm_put_ops(chip);
}
- mutex_unlock(&chip->tpm_mutex);
+
kfree(space->context_buf);
kfree(space->session_buf);
}
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 37/38] wcn36xx: Differentiate wcn3660 from wcn3620
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 36/38] tpm: use try_get_ops() in tpm-space.c Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 15:05 ` [PATCH 5.10 38/38] nds32: fix access_ok() checks in get/put_user Greg Kroah-Hartman
` (9 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bryan ODonoghue, Loic Poulain, Kalle Valo
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
commit 98d504a82cc75840bec8e3c6ae0e4f411921962b upstream.
The spread of capability between the three WiFi silicon parts wcn36xx
supports is:
wcn3620 - 802.11 a/b/g
wcn3660 - 802.11 a/b/g/n
wcn3680 - 802.11 a/b/g/n/ac
We currently treat wcn3660 as wcn3620 thus limiting it to 2GHz channels.
Fix this regression by ensuring we differentiate between all three parts.
Fixes: 8490987bdb9a ("wcn36xx: Hook and identify RF_IRIS_WCN3680")
Cc: stable@vger.kernel.org
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220125004046.4058284-1-bryan.odonoghue@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/wcn36xx/main.c | 3 +++
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
2 files changed, 4 insertions(+)
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1362,6 +1362,9 @@ static int wcn36xx_platform_get_resource
if (iris_node) {
if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
wcn->rf_id = RF_IRIS_WCN3620;
+ if (of_device_is_compatible(iris_node, "qcom,wcn3660") ||
+ of_device_is_compatible(iris_node, "qcom,wcn3660b"))
+ wcn->rf_id = RF_IRIS_WCN3660;
if (of_device_is_compatible(iris_node, "qcom,wcn3680"))
wcn->rf_id = RF_IRIS_WCN3680;
of_node_put(iris_node);
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -96,6 +96,7 @@ enum wcn36xx_ampdu_state {
#define RF_UNKNOWN 0x0000
#define RF_IRIS_WCN3620 0x3620
+#define RF_IRIS_WCN3660 0x3660
#define RF_IRIS_WCN3680 0x3680
static inline void buff_to_be(u32 *buf, size_t len)
^ permalink raw reply [flat|nested] 65+ messages in thread* [PATCH 5.10 38/38] nds32: fix access_ok() checks in get/put_user
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 37/38] wcn36xx: Differentiate wcn3660 from wcn3620 Greg Kroah-Hartman
@ 2022-03-25 15:05 ` Greg Kroah-Hartman
2022-03-25 18:38 ` [PATCH 5.10 00/38] 5.10.109-rc1 review Pavel Machek
` (8 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Greg Kroah-Hartman @ 2022-03-25 15:05 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Christoph Hellwig, Arnd Bergmann
From: Arnd Bergmann <arnd@arndb.de>
commit 8926d88ced46700bf6117ceaf391480b943ea9f4 upstream.
The get_user()/put_user() functions are meant to check for
access_ok(), while the __get_user()/__put_user() functions
don't.
This broke in 4.19 for nds32, when it gained an extraneous
check in __get_user(), but lost the check it needs in
__put_user().
Fixes: 487913ab18c2 ("nds32: Extract the checking and getting pointer to a macro")
Cc: stable@vger.kernel.org @ v4.19+
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/nds32/include/asm/uaccess.h | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/arch/nds32/include/asm/uaccess.h
+++ b/arch/nds32/include/asm/uaccess.h
@@ -70,9 +70,7 @@ static inline void set_fs(mm_segment_t f
* versions are void (ie, don't return a value as such).
*/
-#define get_user __get_user \
-
-#define __get_user(x, ptr) \
+#define get_user(x, ptr) \
({ \
long __gu_err = 0; \
__get_user_check((x), (ptr), __gu_err); \
@@ -85,6 +83,14 @@ static inline void set_fs(mm_segment_t f
(void)0; \
})
+#define __get_user(x, ptr) \
+({ \
+ long __gu_err = 0; \
+ const __typeof__(*(ptr)) __user *__p = (ptr); \
+ __get_user_err((x), __p, (__gu_err)); \
+ __gu_err; \
+})
+
#define __get_user_check(x, ptr, err) \
({ \
const __typeof__(*(ptr)) __user *__p = (ptr); \
@@ -165,12 +171,18 @@ do { \
: "r"(addr), "i"(-EFAULT) \
: "cc")
-#define put_user __put_user \
+#define put_user(x, ptr) \
+({ \
+ long __pu_err = 0; \
+ __put_user_check((x), (ptr), __pu_err); \
+ __pu_err; \
+})
#define __put_user(x, ptr) \
({ \
long __pu_err = 0; \
- __put_user_err((x), (ptr), __pu_err); \
+ __typeof__(*(ptr)) __user *__p = (ptr); \
+ __put_user_err((x), __p, __pu_err); \
__pu_err; \
})
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2022-03-25 15:05 ` [PATCH 5.10 38/38] nds32: fix access_ok() checks in get/put_user Greg Kroah-Hartman
@ 2022-03-25 18:38 ` Pavel Machek
2022-03-25 21:03 ` Fox Chen
` (7 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Pavel Machek @ 2022-03-25 18:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
slade
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
On Fri 2022-03-25 16:04:44, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 65+ messages in thread* RE: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2022-03-25 18:38 ` [PATCH 5.10 00/38] 5.10.109-rc1 review Pavel Machek
@ 2022-03-25 21:03 ` Fox Chen
2022-03-25 22:57 ` Florian Fainelli
` (6 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Fox Chen @ 2022-03-25 21:03 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, slade, Fox Chen
On Fri, 25 Mar 2022 16:04:44 +0100, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +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/v5.x/stable-review/patch-5.10.109-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-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
5.10.109-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)
Tested-by: Fox Chen <foxhlchen@gmail.com>
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2022-03-25 21:03 ` Fox Chen
@ 2022-03-25 22:57 ` Florian Fainelli
2022-03-25 23:24 ` Shuah Khan
` (5 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Florian Fainelli @ 2022-03-25 22:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, sudipm.mukherjee, slade
On 3/25/22 08:04, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +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/v5.x/stable-review/patch-5.10.109-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-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2022-03-25 22:57 ` Florian Fainelli
@ 2022-03-25 23:24 ` Shuah Khan
2022-03-26 7:05 ` Bagas Sanjaya
` (4 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Shuah Khan @ 2022-03-25 23:24 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, slade,
Shuah Khan
On 3/25/22 9:04 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +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/v5.x/stable-review/patch-5.10.109-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-5.10.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 <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2022-03-25 23:24 ` Shuah Khan
@ 2022-03-26 7:05 ` Bagas Sanjaya
2022-03-26 13:15 ` Naresh Kamboju
` (3 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Bagas Sanjaya @ 2022-03-26 7:05 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, slade
On 25/03/22 22.04, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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.
>
Successfully cross-compiled for arm64 (bcm2711_defconfig, gcc 10.2.0) and
powerpc (ps3_defconfig, gcc 11.2.0).
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2022-03-26 7:05 ` Bagas Sanjaya
@ 2022-03-26 13:15 ` Naresh Kamboju
2022-03-26 14:01 ` Sudip Mukherjee
` (2 subsequent siblings)
46 siblings, 0 replies; 65+ messages in thread
From: Naresh Kamboju @ 2022-03-26 13:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
slade
On Fri, 25 Mar 2022 at 20:40, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +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/v5.x/stable-review/patch-5.10.109-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-5.10.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 <lkft@linaro.org>
## Build
* kernel: 5.10.109-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-5.10.y
* git commit: c02fc5f9e70f4aed2693f783a09af12c2ef87802
* git describe: v5.10.108-39-gc02fc5f9e70f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.108-39-gc02fc5f9e70f
## Test Regressions (compared to v5.10.105)
No test regressions found.
## Metric Regressions (compared to v5.10.105)
No metric regressions found.
## Test Fixes (compared to v5.10.105)
No test fixes found.
## Metric Fixes (compared to v5.10.105)
No metric fixes found.
## Test result summary
total: 95863, pass: 81602, fail: 589, skip: 12715, xfail: 957
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 291 total, 291 passed, 0 failed
* arm64: 41 total, 41 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 39 total, 39 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 37 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 60 total, 51 passed, 9 failed
* riscv: 27 total, 27 passed, 0 failed
* s390: 21 total, 21 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 41 total, 41 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* 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-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* 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
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2022-03-26 13:15 ` Naresh Kamboju
@ 2022-03-26 14:01 ` Sudip Mukherjee
2022-03-27 0:51 ` Guenter Roeck
2022-03-28 14:24 ` Jon Hunter
46 siblings, 0 replies; 65+ messages in thread
From: Sudip Mukherjee @ 2022-03-26 14:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, slade
Hi Greg,
On Fri, Mar 25, 2022 at 04:04:44PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +0000.
> Anything received after that time might be too late.
Build test:
mips (gcc version 11.2.1 20220314): 63 configs -> no new failure
arm (gcc version 11.2.1 20220314): 105 configs -> no new failure
arm64 (gcc version 11.2.1 20220314): 3 configs -> no failure
x86_64 (gcc version 11.2.1 20220314): 4 configs -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
[1]. https://openqa.qa.codethink.co.uk/tests/942
[2]. https://openqa.qa.codethink.co.uk/tests/944
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
--
Regards
Sudip
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2022-03-26 14:01 ` Sudip Mukherjee
@ 2022-03-27 0:51 ` Guenter Roeck
2022-03-28 14:24 ` Jon Hunter
46 siblings, 0 replies; 65+ messages in thread
From: Guenter Roeck @ 2022-03-27 0:51 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee,
slade
On Fri, Mar 25, 2022 at 04:04:44PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 161 pass: 161 fail: 0
Qemu test results:
total: 477 pass: 477 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 65+ messages in thread* Re: [PATCH 5.10 00/38] 5.10.109-rc1 review
2022-03-25 15:04 [PATCH 5.10 00/38] 5.10.109-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2022-03-27 0:51 ` Guenter Roeck
@ 2022-03-28 14:24 ` Jon Hunter
46 siblings, 0 replies; 65+ messages in thread
From: Jon Hunter @ 2022-03-28 14:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, stable, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, slade, linux-tegra
On Fri, 25 Mar 2022 16:04:44 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.109 release.
> There are 38 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 Sun, 27 Mar 2022 15:04:08 +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/v5.x/stable-review/patch-5.10.109-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-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v5.10:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
75 tests: 75 pass, 0 fail
Linux version: 5.10.109-rc1-gc02fc5f9e70f
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 65+ messages in thread