This is a note to let you know that I've just added the patch titled
iio: trigger: sysfs: fix use-after-free on remove
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 78601726d4a59a291acc5a52da1d3a0a6831e4e8 Mon Sep 17 00:00:00 2001
From: Vincent Whitchurch <vincent.whitchurch(a)axis.com>
Date: Thu, 19 May 2022 11:19:25 +0200
Subject: iio: trigger: sysfs: fix use-after-free on remove
Ensure that the irq_work has completed before the trigger is freed.
==================================================================
BUG: KASAN: use-after-free in irq_work_run_list
Read of size 8 at addr 0000000064702248 by task python3/25
Call Trace:
irq_work_run_list
irq_work_tick
update_process_times
tick_sched_handle
tick_sched_timer
__hrtimer_run_queues
hrtimer_interrupt
Allocated by task 25:
kmem_cache_alloc_trace
iio_sysfs_trig_add
dev_attr_store
sysfs_kf_write
kernfs_fop_write_iter
new_sync_write
vfs_write
ksys_write
sys_write
Freed by task 25:
kfree
iio_sysfs_trig_remove
dev_attr_store
sysfs_kf_write
kernfs_fop_write_iter
new_sync_write
vfs_write
ksys_write
sys_write
==================================================================
Fixes: f38bc926d022 ("staging:iio:sysfs-trigger: Use irq_work to properly active trigger")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch(a)axis.com>
Reviewed-by: Lars-Peter Clausen <lars(a)metafoo.de>
Link: https://lore.kernel.org/r/20220519091925.1053897-1-vincent.whitchurch@axis.…
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/trigger/iio-trig-sysfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c b/drivers/iio/trigger/iio-trig-sysfs.c
index 2a4b75897910..3d911c24b265 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -191,6 +191,7 @@ static int iio_sysfs_trigger_remove(int id)
}
iio_trigger_unregister(t->trig);
+ irq_work_sync(&t->work);
iio_trigger_free(t->trig);
list_del(&t->l);
--
2.36.1
This is a note to let you know that I've just added the patch titled
iio: gyro: mpu3050: Fix the error handling in mpu3050_power_up()
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From b2f5ad97645e1deb5ca9bcb7090084b92cae35d2 Mon Sep 17 00:00:00 2001
From: Zheyu Ma <zheyuma97(a)gmail.com>
Date: Tue, 10 May 2022 17:24:31 +0800
Subject: iio: gyro: mpu3050: Fix the error handling in mpu3050_power_up()
The driver should disable regulators when fails at regmap_update_bits().
Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Cc: <Stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20220510092431.1711284-1-zheyuma97@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/gyro/mpu3050-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/gyro/mpu3050-core.c b/drivers/iio/gyro/mpu3050-core.c
index ea387efab62d..f4c2f4cb4834 100644
--- a/drivers/iio/gyro/mpu3050-core.c
+++ b/drivers/iio/gyro/mpu3050-core.c
@@ -874,6 +874,7 @@ static int mpu3050_power_up(struct mpu3050 *mpu3050)
ret = regmap_update_bits(mpu3050->map, MPU3050_PWR_MGM,
MPU3050_PWR_MGM_SLEEP, 0);
if (ret) {
+ regulator_bulk_disable(ARRAY_SIZE(mpu3050->regs), mpu3050->regs);
dev_err(mpu3050->dev, "error setting power mode\n");
return ret;
}
--
2.36.1
This is a note to let you know that I've just added the patch titled
iio: adc: axp288: Override TS pin bias current for some models
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 048058399f19d43cf21de9f5d36cd8144337d004 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Fri, 6 May 2022 11:50:40 +0200
Subject: iio: adc: axp288: Override TS pin bias current for some models
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since commit 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling") we
preserve the bias current set by the firmware at boot. This fixes issues
we were seeing on various models.
Some models like the Nuvision Solo 10 Draw tablet actually need the
old hardcoded 80ųA bias current for battery temperature monitoring
to work properly.
Add a quirk entry for the Nuvision Solo 10 Draw to the DMI quirk table
to restore setting the bias current to 80ųA on this model.
Fixes: 9bcf15f75cac ("iio: adc: axp288: Fix TS-pin handling")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215882
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Link: https://lore.kernel.org/r/20220506095040.21008-1-hdegoede@redhat.com
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
---
drivers/iio/adc/axp288_adc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/iio/adc/axp288_adc.c b/drivers/iio/adc/axp288_adc.c
index a4b8be5b8f88..580361bd9849 100644
--- a/drivers/iio/adc/axp288_adc.c
+++ b/drivers/iio/adc/axp288_adc.c
@@ -196,6 +196,14 @@ static const struct dmi_system_id axp288_adc_ts_bias_override[] = {
},
.driver_data = (void *)(uintptr_t)AXP288_ADC_TS_BIAS_80UA,
},
+ {
+ /* Nuvision Solo 10 Draw */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TMAX"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TM101W610L"),
+ },
+ .driver_data = (void *)(uintptr_t)AXP288_ADC_TS_BIAS_80UA,
+ },
{}
};
--
2.36.1
From: Julian Orth <ju.orth(a)gmail.com>
Not calling the function for dummy contexts will cause the context to
not be reset. During the next syscall, this will cause an error in
__audit_syscall_entry:
WARN_ON(context->context != AUDIT_CTX_UNUSED);
WARN_ON(context->name_count);
if (context->context != AUDIT_CTX_UNUSED || context->name_count) {
audit_panic("unrecoverable error in audit_syscall_entry()");
return;
}
These problematic dummy contexts are created via the following call
chain:
exit_to_user_mode_prepare
-> arch_do_signal_or_restart
-> get_signal
-> task_work_run
-> tctx_task_work
-> io_req_task_submit
-> io_issue_sqe
-> audit_uring_entry
Cc: stable(a)vger.kernel.org
Fixes: 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to io_uring")
Signed-off-by: Julian Orth <ju.orth(a)gmail.com>
[PM: subject line tweaks]
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
---
include/linux/audit.h | 2 +-
kernel/auditsc.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index d06134ac6245..cece70231138 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -339,7 +339,7 @@ static inline void audit_uring_entry(u8 op)
}
static inline void audit_uring_exit(int success, long code)
{
- if (unlikely(!audit_dummy_context()))
+ if (unlikely(audit_context()))
__audit_uring_exit(success, code);
}
static inline void audit_syscall_entry(int major, unsigned long a0,
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ea2ee1181921..f3a2abd6d1a1 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1959,6 +1959,12 @@ void __audit_uring_exit(int success, long code)
{
struct audit_context *ctx = audit_context();
+ if (ctx->dummy) {
+ if (ctx->context != AUDIT_CTX_URING)
+ return;
+ goto out;
+ }
+
if (ctx->context == AUDIT_CTX_SYSCALL) {
/*
* NOTE: See the note in __audit_uring_entry() about the case
--
2.25.1
#regzbot introduced: b9132c32e01976686efa26252cc246944a0d2cab
Hi All!
Seems there is a regression of SRv6 End.DT6 function in VRF mode. In the
following scenario packet is decapsulated successfully on vrf10
interface but not forwarded to vrf10's slave interface:
ip netns exec r4 ip -6 nexthop add id 1004 encap seg6local action
End.DT6 vrftable 10 dev vrf10
ip netns exec r4 ip -6 route add fcff:0:4:200:: nhid 1004
In End.DT6 legacy mode everything works good:
ip netns exec r4 ip -6 nexthop add id 1004 encap seg6local action
End.DT6 table 10 dev vrf10
ip netns exec r4 ip -6 route add fcff:0:4:200:: nhid 1004
The issue impacts even stable v5.18.1. Please help to fix it.
Thanks!
Anton
generic/091, 263 test failed since commit f66f8b94e7f2 ("cifs: when
extending a file with falloc we should make files not-sparse").
FSCTL_ZERO_DATA sets the range of bytes to zero without extending file
size. The VFS_FALLOCATE_FL_KEEP_SIZE flag should be used even on
non-sparse files.
Cc: stable(a)vger.kernel.org
Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org>
---
fs/ksmbd/vfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ksmbd/vfs.c b/fs/ksmbd/vfs.c
index dcdd07c6efff..f194bf764f9f 100644
--- a/fs/ksmbd/vfs.c
+++ b/fs/ksmbd/vfs.c
@@ -1015,7 +1015,9 @@ int ksmbd_vfs_zero_data(struct ksmbd_work *work, struct ksmbd_file *fp,
FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
off, len);
- return vfs_fallocate(fp->filp, FALLOC_FL_ZERO_RANGE, off, len);
+ return vfs_fallocate(fp->filp,
+ FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE,
+ off, len);
}
int ksmbd_vfs_fqar_lseek(struct ksmbd_file *fp, loff_t start, loff_t length,
--
2.25.1
Add a special case to block_rtas_call() to allow the ibm,platform-dump RTAS
call through the RTAS filter if the buffer address is 0.
According to PAPR, ibm,platform-dump is called with a null buffer address
to notify the platform firmware that processing of a particular dump is
finished.
Without this, on a pseries machine with CONFIG_PPC_RTAS_FILTER enabled, an
application such as rtas_errd that is attempting to retrieve a dump will
encounter an error at the end of the retrieval process.
Fixes: bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
Cc: stable(a)vger.kernel.org
Reported-by: Sathvika Vasireddy <sathvika(a)linux.ibm.com>
Signed-off-by: Andrew Donnellan <ajd(a)linux.ibm.com>
---
arch/powerpc/kernel/rtas.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index a6fce3106e02..693133972294 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1071,7 +1071,7 @@ static struct rtas_filter rtas_filters[] __ro_after_init = {
{ "get-time-of-day", -1, -1, -1, -1, -1 },
{ "ibm,get-vpd", -1, 0, -1, 1, 2 },
{ "ibm,lpar-perftools", -1, 2, 3, -1, -1 },
- { "ibm,platform-dump", -1, 4, 5, -1, -1 },
+ { "ibm,platform-dump", -1, 4, 5, -1, -1 }, /* Special cased */
{ "ibm,read-slot-reset-state", -1, -1, -1, -1, -1 },
{ "ibm,scan-log-dump", -1, 0, 1, -1, -1 },
{ "ibm,set-dynamic-indicator", -1, 2, -1, -1, -1 },
@@ -1120,6 +1120,15 @@ static bool block_rtas_call(int token, int nargs,
size = 1;
end = base + size - 1;
+
+ /*
+ * Special case for ibm,platform-dump - NULL buffer
+ * address is used to indicate end of dump processing
+ */
+ if (!strcmp(f->name, "ibm,platform-dump") &&
+ base == 0)
+ return false;
+
if (!in_rmo_buf(base, end))
goto err;
}
--
2.30.2
May peace be with you,
My Greetings in the name of our family, This is the second time i am
contacting you with regards to the charity work. I am Mrs. Fariza
Hamza, an aging widow suffering from longtime illness. I am currently
admitted in a private hospital here in the capital city of
Coted’Ivoire.
I have sum amounts of US$17.500 Million dollars i inherited from my
late husband Late Mr. Mohamed Hamza, the sum will be disclosed to you
for security purpose which he deposited in one of a Bank here and I
need a very honest and God fearing person that can use this funds for
God's work and purpose, 15% out of the total funds will be for your
compensation for doing this work of God. I found your email address
and i decided to contact you.
Please if you would be able to use these funds for the purpose and
God's work kindly reply me back. on ( hamzamrs027(a)gmail.com )
Yours Sister.
Mrs. Fariza Hamza.
Dear Child of God,
Calvary Greetings in the name of the LORD Almighty and Our LORD JESUS
CHRIST the giver of every good thing. Good day and compliments of the
seasons, i know this letter will definitely come to you as a huge
surprise, but I implore you to take the time to go through it
carefully as the decision you make will go off a long way to determine
my future and continued existence. I am Mrs Lila Haber aging widow of
57 years old suffering from long time illness.I have some funds I
inherited from my late husband, the sum of (7.2Million Dollars) and I
needed a very honest and God fearing who can withdraw this money then
use the funds for Charity works. I WISH TO GIVE THIS FUNDS TO YOU FOR
CHARITY WORKS. I found your email address from the internet after
honest prayers to the LORD to bring me a helper and i decided to
contact you if you may be willing and interested to handle these trust
funds in good faith before anything happens to me.
I accept this decision because I do not have any child who will
inherit this money after I die. I want your urgent reply to me so that
I will give you the deposit receipt which the SECURITY COMPANY issued
to me as next of kin for immediate transfer of the money to your
account in your country, to start the good work of God, I want you to
use the 25/percent of the total amount to help yourself in doing the
project. I am desperately in keen need of assistance and I have
summoned up courage to contact you for this task, you must not fail me
and the millions of the poor people in our todays WORLD. This is no
stolen money and there are no dangers involved,100% RISK FREE with
full legal proof. Please if you would be able to use the funds for the
Charity works kindly let me know immediately.I will appreciate your
utmost confidentiality and trust in this matter to accomplish my heart
desire, as I don't want anything that will jeopardize my last wish.
Please kindly respond quickly for further details.
Warmest Regards,
Mrs Lila Haber
In a scenario where livepatch and aggrprobe coexist, if arm_kprobe()
returns an error, ap.post_handler, while has been modified to
p.post_handler, is not rolled back.
When ap.post_handler is not NULL (not rolled back), the caller (e.g.
register_kprobe/enable_kprobe) of arm_kprobe_ftrace() will always fail.
Fixes: 12310e343755 ("kprobes: Propagate error from arm_kprobe_ftrace()")
Signed-off-by: Chuang W <nashuiliang(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
---
kernel/kprobes.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f214f8c088ed..0610b02a3a05 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1300,6 +1300,7 @@ static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)
{
int ret = 0;
struct kprobe *ap = orig_p;
+ kprobe_post_handler_t old_post_handler = NULL;
cpus_read_lock();
@@ -1351,6 +1352,9 @@ static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)
/* Copy the insn slot of 'p' to 'ap'. */
copy_kprobe(ap, p);
+
+ /* save the old post_handler */
+ old_post_handler = ap->post_handler;
ret = add_new_kprobe(ap, p);
out:
@@ -1365,6 +1369,7 @@ static int register_aggr_kprobe(struct kprobe *orig_p, struct kprobe *p)
ret = arm_kprobe(ap);
if (ret) {
ap->flags |= KPROBE_FLAG_DISABLED;
+ ap->post_handler = old_post_handler;
list_del_rcu(&p->list);
synchronize_rcu();
}
--
2.34.1
Hello,
My name is Mr.Cosme Amossou, I apologize for contacting you in this
manner but the situation at hand demands urgent attention from all
presumed beneficiaries. I have an important subject to share with you,
regarding my late client Mr. Peter fund's domicile in his bank. Write
back to me for more detailed information.
Best regards
Mr.Cosme
Hallo Schatz.
Wie geht es Ihnen heute? Ich will mit dir kommunizieren. Mein Name ist
Ella Hazem. Ich bin ledig. Es wird mir eine Ehre sein, mit Ihnen eine
gesunde Lebensfreundschaft aufzubauen. Ich habe recht. Finde neue
Freunde, meine Hobbies sind Lesen, Reisen, Schwimmen und Tanzen. Bitte
schreib mir nochmal, damit ich dir alles über mich erklären kann.
Aufrichtig,
ella
Hello darling.
How are you today? I want to communicate with you. My name is Ella
Hazem. I am single. It will be my honor to establish healthy life
friendship with you. I'm right Make new friends, my hobbies are
reading, traveling, swimming and dancing. Please write me again so
that I can explain everything about myself to you.
Sincerely,
ella
There are two issues in phys_p4d_init():
- The __kernel_physical_mapping_init() does not do boundary-checking for
paddr_end and passes it directly to phys_p4d_init(), phys_p4d_init() does
not do bounds checking either, so if the physical memory to be mapped is
large enough, 'p4d_page + p4d_index(vaddr)' will wrap around to the
beginning entry of the P4D table and its data will be overwritten.
- The for loop body will be executed only when 'vaddr < vaddr_end'
evaluates to true, but if that condition is true, 'paddr >= paddr_end'
will evaluate to false, thus the 'if (paddr >= paddr_end) {}' block will
never be executed and become dead code.
To fix these issues, use 'i < PTRS_PER_P4D' instead of 'vaddr < vaddr_end'
as the for loop condition, this also make it more consistent with the logic
of the phys_{pud,pmt,pte}_init() functions.
Fixes: 432c833218dd ("x86/mm: Handle physical-virtual alignment mismatch in phys_p4d_init()")
Cc: stable(a)vger.kernel.org
Signed-off-by: Yuntao Wang <ytcoode(a)gmail.com>
---
arch/x86/mm/init_64.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 8779d6be6a49..e718c9b3f539 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -674,18 +674,18 @@ static unsigned long __meminit
phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end,
unsigned long page_size_mask, pgprot_t prot, bool init)
{
- unsigned long vaddr, vaddr_end, vaddr_next, paddr_next, paddr_last;
-
- paddr_last = paddr_end;
- vaddr = (unsigned long)__va(paddr);
- vaddr_end = (unsigned long)__va(paddr_end);
+ unsigned long vaddr, vaddr_next, paddr_next, paddr_last;
+ int i;
if (!pgtable_l5_enabled())
return phys_pud_init((pud_t *) p4d_page, paddr, paddr_end,
page_size_mask, prot, init);
- for (; vaddr < vaddr_end; vaddr = vaddr_next) {
- p4d_t *p4d = p4d_page + p4d_index(vaddr);
+ paddr_last = paddr_end;
+ vaddr = (unsigned long)__va(paddr);
+
+ for (i = p4d_index(vaddr); i < PTRS_PER_P4D; i++, vaddr = vaddr_next) {
+ p4d_t *p4d = p4d_page + i;
pud_t *pud;
vaddr_next = (vaddr & P4D_MASK) + P4D_SIZE;
@@ -704,13 +704,13 @@ phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end,
if (!p4d_none(*p4d)) {
pud = pud_offset(p4d, 0);
- paddr_last = phys_pud_init(pud, paddr, __pa(vaddr_end),
+ paddr_last = phys_pud_init(pud, paddr, paddr_end,
page_size_mask, prot, init);
continue;
}
pud = alloc_low_page();
- paddr_last = phys_pud_init(pud, paddr, __pa(vaddr_end),
+ paddr_last = phys_pud_init(pud, paddr, paddr_end,
page_size_mask, prot, init);
spin_lock(&init_mm.page_table_lock);
--
2.36.0
GICD region was overlapping with GICR causing the latter to not map
successfully, and in turn the gic-v3 driver would fail to initialize.
This issue was hidden till commit 2b2cd74a06c3 ("irqchip/gic-v3: Claim
iomem resources") replaced of_iomap() calls with of_io_request_and_map()
that internally called request_mem_region().
Respective console output before this patchset:
[ 0.000000] GICv3: /bus@100000/interrupt-controller@1800000: couldn't map region 0
Fixes: b8545f9d3a54 ("arm64: dts: ti: Add initial support for J721S2 SoC")
Cc: Marc Zyngier <maz(a)kernel.org>
Cc: Robin Murphy <robin.murphy(a)arm.com>
Cc: Nishanth Menon <nm(a)ti.com>
Acked-by: Marc Zyngier <maz(a)kernel.org>
Signed-off-by: Matt Ranostay <mranostay(a)ti.com>
---
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Changes from v1:
* Add missing Fixes: in commit messages
Changes from v2:
* Corrected Fixes: tag to actual commit that introduced the issue
* Fixed word wrapping in commit message
NOTE: incorrect linux stable address was used for v3, resubmitted to only
this list with the Marc's Acked-By
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index be7f39299894..19966f72c5b3 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -33,7 +33,7 @@ gic500: interrupt-controller@1800000 {
ranges;
#interrupt-cells = <3>;
interrupt-controller;
- reg = <0x00 0x01800000 0x00 0x200000>, /* GICD */
+ reg = <0x00 0x01800000 0x00 0x100000>, /* GICD */
<0x00 0x01900000 0x00 0x100000>, /* GICR */
<0x00 0x6f000000 0x00 0x2000>, /* GICC */
<0x00 0x6f010000 0x00 0x1000>, /* GICH */
--
2.36.1
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 024a7ad9eb4df626ca8c77fef4f67fd0ebd559d2 Mon Sep 17 00:00:00 2001
From: Andy Chi <andy.chi(a)canonical.com>
Date: Fri, 13 May 2022 20:16:45 +0800
Subject: [PATCH] ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for
HP machine
The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED
and 0x01 to control micmute LED. Therefore, add a quirk to make it works.
Signed-off-by: Andy Chi <andy.chi(a)canonical.com>
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20220513121648.28584-1-andy.chi@canonical.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ce2cb1986677..ad292df7d805 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9091,6 +9091,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x103c, 0x8995, "HP EliteBook 855 G9", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x103c, 0x89a4, "HP ProBook 440 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89a6, "HP ProBook 450 G9", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x89aa, "HP EliteBook 630 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89ac, "HP EliteBook 640 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89ae, "HP EliteBook 650 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89c3, "Zbook Studio G9", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED),
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 024a7ad9eb4df626ca8c77fef4f67fd0ebd559d2 Mon Sep 17 00:00:00 2001
From: Andy Chi <andy.chi(a)canonical.com>
Date: Fri, 13 May 2022 20:16:45 +0800
Subject: [PATCH] ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for
HP machine
The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED
and 0x01 to control micmute LED. Therefore, add a quirk to make it works.
Signed-off-by: Andy Chi <andy.chi(a)canonical.com>
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20220513121648.28584-1-andy.chi@canonical.com
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ce2cb1986677..ad292df7d805 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9091,6 +9091,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x103c, 0x8995, "HP EliteBook 855 G9", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x103c, 0x89a4, "HP ProBook 440 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89a6, "HP ProBook 450 G9", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x89aa, "HP EliteBook 630 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89ac, "HP EliteBook 640 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89ae, "HP EliteBook 650 G9", ALC236_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x89c3, "Zbook Studio G9", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED),
From: Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
There is a small chance that get_kretprobe(ri) returns NULL in
kretprobe_dispatcher() when another CPU unregisters the kretprobe
right after __kretprobe_trampoline_handler().
To avoid this issue, kretprobe_dispatcher() checks the get_kretprobe()
return value again. And if it is NULL, it returns soon because that
kretprobe is under unregistering process.
This issue has been introduced when the kretprobe is decoupled
from the struct kretprobe_instance by commit d741bf41d7c7
("kprobes: Remove kretprobe hash"). Before that commit, the
struct kretprob_instance::rp directly points the kretprobe
and it is never be NULL.
Reported-by: Yonghong Song <yhs(a)fb.com>
Fixes: d741bf41d7c7 ("kprobes: Remove kretprobe hash")
Cc: stable(a)vger.kernel.org
Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
---
kernel/trace/trace_kprobe.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 93507330462c..a245ea673715 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1718,8 +1718,17 @@ static int
kretprobe_dispatcher(struct kretprobe_instance *ri, struct pt_regs *regs)
{
struct kretprobe *rp = get_kretprobe(ri);
- struct trace_kprobe *tk = container_of(rp, struct trace_kprobe, rp);
+ struct trace_kprobe *tk;
+
+ /*
+ * There is a small chance that get_kretprobe(ri) returns NULL when
+ * the kretprobe is unregister on another CPU between kretprobe's
+ * trampoline_handler and this function.
+ */
+ if (unlikely(!rp))
+ return 0;
+ tk = container_of(rp, struct trace_kprobe, rp);
raw_cpu_inc(*tk->nhit);
if (trace_probe_test_flag(&tk->tp, TP_FLAG_TRACE))
A panic can occur if the endpoint becomes disabled and the
uvcg_video_pump adds the request back to the req_free list after it has
already been queued to the endpoint. The endpoint complete will add the
request back to the req_free list. Invalidate the local request handle
once it's been queued.
<6>[ 246.796704][T13726] configfs-gadget gadget: uvc: uvc_function_set_alt(1, 0)
<3>[ 246.797078][ T26] list_add double add: new=ffffff878bee5c40, prev=ffffff878bee5c40, next=ffffff878b0f0a90.
<6>[ 246.797213][ T26] ------------[ cut here ]------------
<2>[ 246.797224][ T26] kernel BUG at lib/list_debug.c:31!
<6>[ 246.807073][ T26] Call trace:
<6>[ 246.807180][ T26] uvcg_video_pump+0x364/0x38c
<6>[ 246.807366][ T26] process_one_work+0x2a4/0x544
<6>[ 246.807394][ T26] worker_thread+0x350/0x784
<6>[ 246.807442][ T26] kthread+0x2ac/0x320
Fixes: f9897ec0f6d3 ("usb: gadget: uvc: only pump video data if necessary")
Cc: stable(a)vger.kernel.org
Signed-off-by: Dan Vacura <w36195(a)motorola.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
---
V1 -> V2:
- update logic flow per review recommendation
- add review by for Laurent Pinchart
drivers/usb/gadget/function/uvc_video.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
index 93f42c7f800d..c00ce0e91f5d 100644
--- a/drivers/usb/gadget/function/uvc_video.c
+++ b/drivers/usb/gadget/function/uvc_video.c
@@ -428,6 +428,9 @@ static void uvcg_video_pump(struct work_struct *work)
uvcg_queue_cancel(queue, 0);
break;
}
+
+ /* Endpoint now owns the request */
+ req = NULL;
video->req_int_count++;
}
--
2.34.1
A panic can occur if the endpoint becomes disabled and the
uvcg_video_pump adds the request back to the req_free list after it has
already been queued to the endpoint. The endpoint complete will add the
request back to the req_free list. Invalidate the local request handle
once it's been queued.
<6>[ 246.796704][T13726] configfs-gadget gadget: uvc: uvc_function_set_alt(1, 0)
<3>[ 246.797078][ T26] list_add double add: new=ffffff878bee5c40, prev=ffffff878bee5c40, next=ffffff878b0f0a90.
<6>[ 246.797213][ T26] ------------[ cut here ]------------
<2>[ 246.797224][ T26] kernel BUG at lib/list_debug.c:31!
<6>[ 246.807073][ T26] Call trace:
<6>[ 246.807180][ T26] uvcg_video_pump+0x364/0x38c
<6>[ 246.807366][ T26] process_one_work+0x2a4/0x544
<6>[ 246.807394][ T26] worker_thread+0x350/0x784
<6>[ 246.807442][ T26] kthread+0x2ac/0x320
Fixes: f9897ec0f6d3 ("usb: gadget: uvc: only pump video data if necessary")
Cc: stable(a)vger.kernel.org
Signed-off-by: Dan Vacura <w36195(a)motorola.com>
---
drivers/usb/gadget/function/uvc_video.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/function/uvc_video.c b/drivers/usb/gadget/function/uvc_video.c
index 93f42c7f800d..59e2f51b53a5 100644
--- a/drivers/usb/gadget/function/uvc_video.c
+++ b/drivers/usb/gadget/function/uvc_video.c
@@ -427,6 +427,9 @@ static void uvcg_video_pump(struct work_struct *work)
if (ret < 0) {
uvcg_queue_cancel(queue, 0);
break;
+ } else {
+ /* Endpoint now owns the request */
+ req = NULL;
}
video->req_int_count++;
}
--
2.34.1
Hello,
would you like to reach more clients?
As one of the first SEO agencies in Europe, we’ve introduced SEO 360 service (SEO, UX, and SEM), which assures a multidimensional approach to optimising company’s visibility online and increasing website traffic.
We provide a free consultation with our specialist, during which we will conduct a detailed analysis of your website or e-shop, positioning indicators and check the actions and results achieved by your competitors.
Our clients gain notable results by using a dedicated strategy, extensive website analytics, technical optimisation, adding new subpages and link building.
With 14 years of experience and the skills of over 350 specialists working on 3 continents, you can increase your sales and become an industry leader.
Please let us know if you want to learn more about our methods and possible results.
Yours sincerely,
Walker Cooney
commit 1f30fb9166d4f15a1aa19449b9da871fe0ed4796 upstream
[Backport for 4.19: Removed handling of OVS_ACTION_ATTR_DEC_TTL
and OVS_ACTION_ATTR_CHECK_PKT_LEN as these actions do not exist
in this version. BUILD_BUG_ON condition adjusted accordingly.]
While parsing user-provided actions, openvswitch module may dynamically
allocate memory and store pointers in the internal copy of the actions.
So this memory has to be freed while destroying the actions.
Currently there are only two such actions: ct() and set(). However,
there are many actions that can hold nested lists of actions and
ovs_nla_free_flow_actions() just jumps over them leaking the memory.
For example, removal of the flow with the following actions will lead
to a leak of the memory allocated by nf_ct_tmpl_alloc():
actions:clone(ct(commit),0)
Non-freed set() action may also leak the 'dst' structure for the
tunnel info including device references.
Under certain conditions with a high rate of flow rotation that may
cause significant memory leak problem (2MB per second in reporter's
case). The problem is also hard to mitigate, because the user doesn't
have direct control over the datapath flows generated by OVS.
Fix that by iterating over all the nested actions and freeing
everything that needs to be freed recursively.
New build time assertion should protect us from this problem if new
actions will be added in the future.
Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all
attributes has to be explicitly checked. sample() and clone() actions
are mixing extra attributes into the user-provided action list. That
prevents some code generalization too.
Fixes: 34ae932a4036 ("openvswitch: Make tunnel set action attach a metadata dst")
Link: https://mail.openvswitch.org/pipermail/ovs-dev/2022-March/392922.html
Reported-by: Stéphane Graber <stgraber(a)ubuntu.com>
Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org>
Acked-by: Aaron Conole <aconole(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
---
The fix was already backported down to 5.10. This adjusted version will
work on 4.19. The version for 5.4 was sent separately.
net/openvswitch/flow_netlink.c | 61 +++++++++++++++++++++++++++++++---
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 180f5feb7717..eba94cf3d2d0 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2253,6 +2253,36 @@ static struct sw_flow_actions *nla_alloc_flow_actions(int size)
return sfa;
}
+static void ovs_nla_free_nested_actions(const struct nlattr *actions, int len);
+
+static void ovs_nla_free_clone_action(const struct nlattr *action)
+{
+ const struct nlattr *a = nla_data(action);
+ int rem = nla_len(action);
+
+ switch (nla_type(a)) {
+ case OVS_CLONE_ATTR_EXEC:
+ /* The real list of actions follows this attribute. */
+ a = nla_next(a, &rem);
+ ovs_nla_free_nested_actions(a, rem);
+ break;
+ }
+}
+
+static void ovs_nla_free_sample_action(const struct nlattr *action)
+{
+ const struct nlattr *a = nla_data(action);
+ int rem = nla_len(action);
+
+ switch (nla_type(a)) {
+ case OVS_SAMPLE_ATTR_ARG:
+ /* The real list of actions follows this attribute. */
+ a = nla_next(a, &rem);
+ ovs_nla_free_nested_actions(a, rem);
+ break;
+ }
+}
+
static void ovs_nla_free_set_action(const struct nlattr *a)
{
const struct nlattr *ovs_key = nla_data(a);
@@ -2266,25 +2296,46 @@ static void ovs_nla_free_set_action(const struct nlattr *a)
}
}
-void ovs_nla_free_flow_actions(struct sw_flow_actions *sf_acts)
+static void ovs_nla_free_nested_actions(const struct nlattr *actions, int len)
{
const struct nlattr *a;
int rem;
- if (!sf_acts)
+ /* Whenever new actions are added, the need to update this
+ * function should be considered.
+ */
+ BUILD_BUG_ON(OVS_ACTION_ATTR_MAX != 20);
+
+ if (!actions)
return;
- nla_for_each_attr(a, sf_acts->actions, sf_acts->actions_len, rem) {
+ nla_for_each_attr(a, actions, len, rem) {
switch (nla_type(a)) {
- case OVS_ACTION_ATTR_SET:
- ovs_nla_free_set_action(a);
+ case OVS_ACTION_ATTR_CLONE:
+ ovs_nla_free_clone_action(a);
break;
+
case OVS_ACTION_ATTR_CT:
ovs_ct_free_action(a);
break;
+
+ case OVS_ACTION_ATTR_SAMPLE:
+ ovs_nla_free_sample_action(a);
+ break;
+
+ case OVS_ACTION_ATTR_SET:
+ ovs_nla_free_set_action(a);
+ break;
}
}
+}
+
+void ovs_nla_free_flow_actions(struct sw_flow_actions *sf_acts)
+{
+ if (!sf_acts)
+ return;
+ ovs_nla_free_nested_actions(sf_acts->actions, sf_acts->actions_len);
kfree(sf_acts);
}
--
2.34.3
It used to be that mix_interrupt_randomness() would credit 1 bit each
time it ran, and so add_interrupt_randomness() would schedule mix() to
run every 64 interrupts, a fairly arbitrary number, but nonetheless
considered to be a decent enough conservative estimate.
Since e3e33fc2ea7f ("random: do not use input pool from hard IRQs"),
mix() is now able to credit multiple bits, depending on the number of
calls to add(). This was done for reasons separate from this commit, but
it has the nice side effect of enabling this patch to schedule mix()
less often.
Currently the rules are:
a) Credit 1 bit for every 64 calls to add().
b) Schedule mix() once a second that add() is called.
c) Schedule mix() once every 64 calls to add().
Rules (a) and (c) no longer need to be coupled. It's still important to
have _some_ value in (c), so that we don't "over-saturate" the fast
pool, but the once per second we get from rule (b) is a plenty enough
baseline. So, by increasing the 64 in rule (c) to something larger, we
avoid calling queue_work_on() as frequently during irq storms.
This commit changes that 64 in rule (c) to be 1024, which means we
schedule mix() 16 times less often. And it does *not* need to change the
64 in rule (a).
Fixes: 58340f8e952b ("random: defer fast pool mixing to worker")
Cc: stable(a)vger.kernel.org
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Dominik Brodowski <linux(a)dominikbrodowski.net>
Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 655e327d425e..d0e4c89c4fcb 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1009,7 +1009,7 @@ void add_interrupt_randomness(int irq)
if (new_count & MIX_INFLIGHT)
return;
- if (new_count < 64 && !time_is_before_jiffies(fast_pool->last + HZ))
+ if (new_count < 1024 && !time_is_before_jiffies(fast_pool->last + HZ))
return;
if (unlikely(!fast_pool->mix.func))
--
2.35.1
--
Hello,
My name is Steve Dibenedetto.I apologize to have contacted you this way
without a direct relationship. There is an opportunity to collaborate
with me in the sourcing of some materials needed by our company for
production of the different medicines we are researching.
I'm aware that this might be totally outside your professional
specialization, but it will be a great source for generating extra
revenue. I discovered a manufacturer who can supply us at a lower rate
than our company's previous purchases.
I will give you more specific details when/if I receive feedback from
you showing interest.
Warm Regards
Steve Dibenedetto
Production & Control Manager,
Green Field Laboratories
Gothic House, Barker Gate,
Nottingham, NG1 1JU,
United Kingdom.
test_bit(), as any other bitmap op, takes `unsigned long *` as a
second argument (pointer to the actual bitmap), as any bitmap
itself is an array of unsigned longs. However, the ia64_get_irr()
code passes a ref to `u64` as a second argument.
This works with the ia64 bitops implementation due to that they
have `void *` as the second argument and then cast it later on.
This works with the bitmap API itself due to that `unsigned long`
has the same size on ia64 as `u64` (`unsigned long long`), but
from the compiler PoV those two are different.
Define @irr as `unsigned long` to fix that. That implies no
functional changes. Has been hidden for 16 years!
Fixes: a58786917ce2 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations")
Cc: stable(a)vger.kernel.org # 2.6.16+
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Alexander Lobakin <alexandr.lobakin(a)intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Reviewed-by: Yury Norov <yury.norov(a)gmail.com>
---
arch/ia64/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/processor.h b/arch/ia64/include/asm/processor.h
index 7cbce290f4e5..757c2f6d8d4b 100644
--- a/arch/ia64/include/asm/processor.h
+++ b/arch/ia64/include/asm/processor.h
@@ -538,7 +538,7 @@ ia64_get_irr(unsigned int vector)
{
unsigned int reg = vector / 64;
unsigned int bit = vector % 64;
- u64 irr;
+ unsigned long irr;
switch (reg) {
case 0: irr = ia64_getreg(_IA64_REG_CR_IRR0); break;
--
2.36.1
commit 4ddc844eb81da59bfb816d8d52089aba4e59e269 upstream.
in current Linux, MTU policing does not take into account that packets at
the TC ingress have the L2 header pulled. Thus, the same TC police action
(with the same value of tcfp_mtu) behaves differently for ingress/egress.
In addition, the full GSO size is compared to tcfp_mtu: as a consequence,
the policer drops GSO packets even when individual segments have the L2 +
L3 + L4 + payload length below the configured valued of tcfp_mtu.
Improve the accuracy of MTU policing as follows:
- account for mac_len for non-GSO packets at TC ingress.
- compare MTU threshold with the segmented size for GSO packets.
[dcaratti: fix conflicts due to lack of the following commits:
- commit 2ffe0395288a ("net/sched: act_police: add support for
packet-per-second policing")
- commit afe231d32eb5 ("selftests: forwarding: Add tc-police tests")
- commit 53b61f29367d ("selftests: forwarding: Add tc-police tests for
packets per second")]
Link: https://lore.kernel.org/netdev/876d597a0ff55f6ba786f73c5a9fd9eb8d597a03.164…
Signed-off-by: Davide Caratti <dcaratti(a)redhat.com>
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
---
net/sched/act_police.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 8fd23a8b88a5..a7660b602237 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -213,6 +213,20 @@ static int tcf_police_init(struct net *net, struct nlattr *nla,
return err;
}
+static bool tcf_police_mtu_check(struct sk_buff *skb, u32 limit)
+{
+ u32 len;
+
+ if (skb_is_gso(skb))
+ return skb_gso_validate_mac_len(skb, limit);
+
+ len = qdisc_pkt_len(skb);
+ if (skb_at_tc_ingress(skb))
+ len += skb->mac_len;
+
+ return len <= limit;
+}
+
static int tcf_police_act(struct sk_buff *skb, const struct tc_action *a,
struct tcf_result *res)
{
@@ -235,7 +249,7 @@ static int tcf_police_act(struct sk_buff *skb, const struct tc_action *a,
goto inc_overlimits;
}
- if (qdisc_pkt_len(skb) <= p->tcfp_mtu) {
+ if (tcf_police_mtu_check(skb, p->tcfp_mtu)) {
if (!p->rate_present) {
ret = p->tcfp_result;
goto end;
--
2.35.3
Sehr geehrte(r) 🤍 You have unread messages (5) from Christina! View Messages: https://queen22.page.link/photos?s0j8n 🤍,
vielen Dank für Deine Nachricht. Wir werden uns zeitnah darum kümmern.
Schöne Grüße,
das Team vom HOFLADEN Geinberg
Hier deine Nachricht an uns:
🤍 You have unread messages (5) from Christina! View Messages: https://queen22.page.link/photos?s0j8n 🤍
stable(a)vger.kernel.org
xq3ey2
Currently, a problem faced by arm64 is if a kernel image is signed by a
MOK key, loading it via the kexec_file_load() system call would be
rejected with the error "Lockdown: kexec: kexec of unsigned images is
restricted; see man kernel_lockdown.7".
This happens because image_verify_sig uses only the primary keyring that
contains only kernel built-in keys to verify the kexec image.
This patch allows to verify arm64 kernel image signature using not only
.builtin_trusted_keys but also .platform and .secondary_trusted_keys
keyring.
Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification support")
Cc: stable(a)vger.kernel.org # 34d5960af253: kexec: clean up arch_kexec_kernel_verify_sig
Cc: stable(a)vger.kernel.org # 83b7bb2d49ae: kexec, KEYS: make the code in bzImage64_verify_sig generic
Acked-by: Baoquan He <bhe(a)redhat.com>
Cc: kexec(a)lists.infradead.org
Cc: keyrings(a)vger.kernel.org
Cc: linux-security-module(a)vger.kernel.org
Co-developed-by: Michal Suchanek <msuchanek(a)suse.de>
Signed-off-by: Michal Suchanek <msuchanek(a)suse.de>
Acked-by: Will Deacon <will(a)kernel.org>
Signed-off-by: Coiby Xu <coxu(a)redhat.com>
---
arch/arm64/kernel/kexec_image.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 9ec34690e255..5ed6a585f21f 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -14,7 +14,6 @@
#include <linux/kexec.h>
#include <linux/pe.h>
#include <linux/string.h>
-#include <linux/verification.h>
#include <asm/byteorder.h>
#include <asm/cpufeature.h>
#include <asm/image.h>
@@ -130,18 +129,10 @@ static void *image_load(struct kimage *image,
return NULL;
}
-#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
-static int image_verify_sig(const char *kernel, unsigned long kernel_len)
-{
- return verify_pefile_signature(kernel, kernel_len, NULL,
- VERIFYING_KEXEC_PE_SIGNATURE);
-}
-#endif
-
const struct kexec_file_ops kexec_image_ops = {
.probe = image_probe,
.load = image_load,
#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
- .verify_sig = image_verify_sig,
+ .verify_sig = kexec_kernel_verify_pe_sig,
#endif
};
--
2.35.3
Hi Greg, Sasha,
I think we're finally at a good point to begin backporting the work I've
done on random.c during the last 6 months. I've been maintaining
branches for this incrementally as code has been merged into mainline,
in order to make this moment easier than otherwise.
Assuming that Linus merges my PR for 5.19 [1] today, all of these
patches are (or will be in a few hours) in Linus' tree. I've tried to
backport most of the general scaffolding and design of the current state
of random.c, while not backporting any new features or unusual
functionality changes that might invite trouble. So, for example, the
backports switch to using a cryptographic hash function, but they don't
have changes like warning when the cycle counter is zero, attempting to
use jitter on early uses of /dev/urandom, reseeding on suspend/hibernate
notifications, or the vmgenid driver. Hopefully that strikes an okay
balance between getting the core backported so that fixes are
backportable, but not going too far by backporting new "nice to have"
but unessential features.
In this git repo [2], there are three branches: linux-5.15.y,
linux-5.17.y, and linux-5.18.y, which contain backports for everything
up to and including [1].
You'll probably want to backport this to earlier kernels as well. Given
that there hasn't been overly much work on the rng in the last few
years, it shouldn't be too hard to take my 5.15.y branch and fill in the
missing pieces there to bring it back. Given how much changes, you could
probably just take every random.c change for backporting to before 5.15.
There is one snag, which is that some of the work I did during the 5.17
cycle depends on crypto I added for WireGuard, which landed in 5.6. So
for 5.4 and prior, that will need backports. Fortunately, I've already
done this in [3], in the branch backport-5.4.y, which I've kept up to
date for a few years now. This occasion might mark the perfect excuse
we've been waiting for to just backport WireGuard too to 5.4 (which
might make the Android work a bit easier also) :-D.
Let me know if you have any questions, and feel free to poke me on IRC.
And if all of the above sounds terrible to you, and you'd rather just
not take any of this into stable, I guess that's a valid path to take
too.
Regards,
Jason
[1] https://lore.kernel.org/lkml/20220522214457.37108-1-Jason@zx2c4.com/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/wireguard-linux.git/
Commit 787af64d05cd ("mm: page_alloc: validate buddy before check its migratetype.")
added buddy check code. But unfortunately, this fix isn't backported to
linux-5.17.y and the former stable branches. The reason is it added wrong
fixes message:
Fixes: 1dd214b8f21c ("mm: page_alloc: avoid merging non-fallbackable
pageblocks with others")
Actually, this issue is involved by commit:
commit d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks")
For RISC-V arch, the first 2M is reserved for sbi, so the start PFN is 512,
but it got buddy PFN 0 for PFN 0x2000:
0 = 0x2000 ^ (1 << 12)
With the illegal buddy PFN 0, it got an illegal buddy page, which caused
crash in __get_pfnblock_flags_mask().
With the patch, it can avoid the calling of get_pageblock_migratetype() if
it isn't buddy page.
Fixes: d9dddbf55667 ("mm/page_alloc: prevent merging between isolated and other pageblocks")
Cc: stable(a)vger.kernel.org
Reported-by: zjb194813(a)alibaba-inc.com
Reported-by: tianhu.hh(a)alibaba-inc.com
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b1caa1c6c887..5b423caa68fd 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1129,6 +1129,9 @@ static inline void __free_one_page(struct page *page,
buddy_pfn = __find_buddy_pfn(pfn, order);
buddy = page + (buddy_pfn - pfn);
+
+ if (!page_is_buddy(page, buddy, order))
+ goto done_merging;
buddy_mt = get_pageblock_migratetype(buddy);
if (migratetype != buddy_mt
--
2.17.1
The quilt patch titled
Subject: mm: lru_cache_disable: use synchronize_rcu_expedited
has been removed from the -mm tree. Its filename was
mm-lru_cache_disable-use-synchronize_rcu_expedited.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Marcelo Tosatti <mtosatti(a)redhat.com>
Subject: mm: lru_cache_disable: use synchronize_rcu_expedited
Date: Mon, 30 May 2022 12:51:56 -0300
commit ff042f4a9b050 ("mm: lru_cache_disable: replace work queue
synchronization with synchronize_rcu") replaced lru_cache_disable's usage
of work queues with synchronize_rcu.
Some users reported large performance regressions due to this commit, for
example:
https://lore.kernel.org/all/20220521234616.GO1790663@paulmck-ThinkPad-P17-G…
Switching to synchronize_rcu_expedited fixes the problem.
Link: https://lkml.kernel.org/r/YpToHCmnx/HEcVyR@fuller.cnet
Fixes: ff042f4a9b050 ("mm: lru_cache_disable: replace work queue synchronization with synchronize_rcu")
Signed-off-by: Marcelo Tosatti <mtosatti(a)redhat.com>
Tested-by: Stefan Wahren <stefan.wahren(a)i2se.com>
Tested-by: Michael Larabel <Michael(a)MichaelLarabel.com>
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Nicolas Saenz Julienne <nsaenzju(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Minchan Kim <minchan(a)kernel.org>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Juri Lelli <juri.lelli(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Paul E. McKenney <paulmck(a)kernel.org>
Cc: Phil Elwell <phil(a)raspberrypi.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/swap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/swap.c~mm-lru_cache_disable-use-synchronize_rcu_expedited
+++ a/mm/swap.c
@@ -881,7 +881,7 @@ void lru_cache_disable(void)
* lru_disable_count = 0 will have exited the critical
* section when synchronize_rcu() returns.
*/
- synchronize_rcu();
+ synchronize_rcu_expedited();
#ifdef CONFIG_SMP
__lru_add_drain_all(true);
#else
_
Patches currently in -mm which might be from mtosatti(a)redhat.com are
This is the start of the stable review cycle for the 5.10.123 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +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.123-r…
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
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.123-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 72 ++++++
arch/x86/kvm/vmx/vmx.h | 2 +
arch/x86/kvm/x86.c | 3 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 3 +
tools/arch/x86/include/asm/cpufeatures.h | 1 +
tools/arch/x86/include/asm/msr-index.h | 25 +++
17 files changed, 676 insertions(+), 41 deletions(-)
Currently we remove EA inode from mbcache as soon as its xattr refcount
drops to zero. However there can be pending attempts to reuse the inode
and thus refcount handling code has to handle the situation when
refcount increases from zero anyway. So save some work and just keep EA
inode in mbcache until it is getting evicted. At that moment we are sure
following iget() of EA inode will fail anyway (or wait for eviction to
finish and load things from the disk again) and so removing mbcache
entry at that moment is fine and simplifies the code a bit.
CC: stable(a)vger.kernel.org
Fixes: 82939d7999df ("ext4: convert to mbcache2")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/ext4/inode.c | 2 ++
fs/ext4/xattr.c | 24 ++++++++----------------
fs/ext4/xattr.h | 1 +
3 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3dce7d058985..7450ee734262 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -177,6 +177,8 @@ void ext4_evict_inode(struct inode *inode)
trace_ext4_evict_inode(inode);
+ if (EXT4_I(inode)->i_flags & EXT4_EA_INODE_FL)
+ ext4_evict_ea_inode(inode);
if (inode->i_nlink) {
/*
* When journalling data dirty buffers are tracked only in the
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 042325349098..7fc40fb1e6b3 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -436,6 +436,14 @@ static int ext4_xattr_inode_iget(struct inode *parent, unsigned long ea_ino,
return err;
}
+/* Remove entry from mbcache when EA inode is getting evicted */
+void ext4_evict_ea_inode(struct inode *inode)
+{
+ if (EA_INODE_CACHE(inode))
+ mb_cache_entry_delete(EA_INODE_CACHE(inode),
+ ext4_xattr_inode_get_hash(inode), inode->i_ino);
+}
+
static int
ext4_xattr_inode_verify_hashes(struct inode *ea_inode,
struct ext4_xattr_entry *entry, void *buffer,
@@ -976,10 +984,8 @@ int __ext4_xattr_set_credits(struct super_block *sb, struct inode *inode,
static int ext4_xattr_inode_update_ref(handle_t *handle, struct inode *ea_inode,
int ref_change)
{
- struct mb_cache *ea_inode_cache = EA_INODE_CACHE(ea_inode);
struct ext4_iloc iloc;
s64 ref_count;
- u32 hash;
int ret;
inode_lock(ea_inode);
@@ -1002,14 +1008,6 @@ static int ext4_xattr_inode_update_ref(handle_t *handle, struct inode *ea_inode,
set_nlink(ea_inode, 1);
ext4_orphan_del(handle, ea_inode);
-
- if (ea_inode_cache) {
- hash = ext4_xattr_inode_get_hash(ea_inode);
- mb_cache_entry_create(ea_inode_cache,
- GFP_NOFS, hash,
- ea_inode->i_ino,
- true /* reusable */);
- }
}
} else {
WARN_ONCE(ref_count < 0, "EA inode %lu ref_count=%lld",
@@ -1022,12 +1020,6 @@ static int ext4_xattr_inode_update_ref(handle_t *handle, struct inode *ea_inode,
clear_nlink(ea_inode);
ext4_orphan_add(handle, ea_inode);
-
- if (ea_inode_cache) {
- hash = ext4_xattr_inode_get_hash(ea_inode);
- mb_cache_entry_delete(ea_inode_cache, hash,
- ea_inode->i_ino);
- }
}
}
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h
index 77efb9a627ad..060b7a2f485c 100644
--- a/fs/ext4/xattr.h
+++ b/fs/ext4/xattr.h
@@ -178,6 +178,7 @@ extern void ext4_xattr_inode_array_free(struct ext4_xattr_inode_array *array);
extern int ext4_expand_extra_isize_ea(struct inode *inode, int new_extra_isize,
struct ext4_inode *raw_inode, handle_t *handle);
+extern void ext4_evict_ea_inode(struct inode *inode);
extern const struct xattr_handler *ext4_xattr_handlers[];
--
2.35.3
Do not reclaim entries that are currently used by somebody from a
shrinker. Firstly, these entries are likely useful. Secondly, we will
need to keep such entries to protect pending increment of xattr block
refcount.
CC: stable(a)vger.kernel.org
Fixes: 82939d7999df ("ext4: convert to mbcache2")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/mbcache.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/mbcache.c b/fs/mbcache.c
index 97c54d3a2227..cfc28129fb6f 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -288,7 +288,7 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
while (nr_to_scan-- && !list_empty(&cache->c_list)) {
entry = list_first_entry(&cache->c_list,
struct mb_cache_entry, e_list);
- if (entry->e_referenced) {
+ if (entry->e_referenced || atomic_read(&entry->e_refcnt) > 2) {
entry->e_referenced = 0;
list_move_tail(&entry->e_list, &cache->c_list);
continue;
@@ -302,6 +302,14 @@ static unsigned long mb_cache_shrink(struct mb_cache *cache,
spin_unlock(&cache->c_list_lock);
head = mb_cache_entry_head(cache, entry->e_key);
hlist_bl_lock(head);
+ /* Now a reliable check if the entry didn't get used... */
+ if (atomic_read(&entry->e_refcnt) > 2) {
+ hlist_bl_unlock(head);
+ spin_lock(&cache->c_list_lock);
+ list_add_tail(&entry->e_list, &cache->c_list);
+ cache->c_entry_count++;
+ continue;
+ }
if (!hlist_bl_unhashed(&entry->e_hash_list)) {
hlist_bl_del_init(&entry->e_hash_list);
atomic_dec(&entry->e_refcnt);
--
2.35.3
commit f2e19b36593caed4c977c2f55aeba7408aeb2132 upstream.
The transaction buffer is allocated by using the size of the packet buf,
and subtracting two which seem intended to remove the two tags which are
not present in the target structure. This calculation leads to under
counting memory because of differences between the packet contents and the
target structure. The aid_len field is a u8 in the packet, but a u32 in
the structure, resulting in at least 3 bytes always being under counted.
Further, the aid data is a variable length field in the packet, but fixed
in the structure, so if this field is less than the max, the difference is
added to the under counting.
The last validation check for transaction->params_len is also incorrect
since it employs the same accounting error.
To fix, perform validation checks progressively to safely reach the
next field, to determine the size of both buffers and verify both tags.
Once all validation checks pass, allocate the buffer and copy the data.
This eliminates freeing memory on the error path, as those checks are
moved ahead of memory allocation.
Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
Cc: stable(a)vger.kernel.org
Signed-off-by: Martin Faltesek <mfaltesek(a)google.com>
Reviewed-by: Guenter Roeck <groeck(a)chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
Change-Id: I22f9d58293b64566c43a7ba254d9e0e8c4dc35fe
---
drivers/nfc/st21nfca/se.c | 61 +++++++++++++++++++--------------------
1 file changed, 30 insertions(+), 31 deletions(-)
This patch cleanly applies in stable kernels 4.9 through 5.4.
The following difference between upstream and 4.9 though 5.4
caused the upstream patch to fail applying:
< - transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
---
> - transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
> - skb->len - 2, GFP_KERNEL);
This is the only change made in this patch from the original.
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index ccaace2a5b0e..d41636504246 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -304,6 +304,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
int r = 0;
struct device *dev = &hdev->ndev->dev;
struct nfc_evt_transaction *transaction;
+ u32 aid_len;
+ u8 params_len;
pr_debug("connectivity gate event: %x\n", event);
@@ -312,51 +314,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
r = nfc_se_connectivity(hdev->ndev, host);
break;
case ST21NFCA_EVT_TRANSACTION:
- /*
- * According to specification etsi 102 622
+ /* According to specification etsi 102 622
* 11.2.2.4 EVT_TRANSACTION Table 52
* Description Tag Length
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
+ *
+ * The key differences are aid storage length is variably sized
+ * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
+ * is u8 in the packet, but u32 in the structure, and the tags in
+ * the packet are not included in nfc_evt_transaction.
+ *
+ * size in bytes: 1 1 5-16 1 1 0-255
+ * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
+ * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
+ * example: 0x81 5-16 X 0x82 0-255 X
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
- skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+ if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
- transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
- skb->len - 2, GFP_KERNEL);
- if (!transaction)
- return -ENOMEM;
-
- transaction->aid_len = skb->data[1];
+ aid_len = skb->data[1];
- /* Checking if the length of the AID is valid */
- if (transaction->aid_len > sizeof(transaction->aid)) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
+ return -EPROTO;
- memcpy(transaction->aid, &skb->data[2],
- transaction->aid_len);
+ params_len = skb->data[aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
- if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG) {
- devm_kfree(dev, transaction);
+ /* Verify PARAMETERS tag is (82), and final check that there is enough
+ * space in the packet to read everything.
+ */
+ if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
+ (skb->len < aid_len + 4 + params_len))
return -EPROTO;
- }
- transaction->params_len = skb->data[transaction->aid_len + 3];
+ transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
- /* Total size is allocated (skb->len - 2) minus fixed array members */
- if (transaction->params_len > ((skb->len - 2) -
- sizeof(struct nfc_evt_transaction))) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ transaction->aid_len = aid_len;
+ transaction->params_len = params_len;
- memcpy(transaction->params, skb->data +
- transaction->aid_len + 4, transaction->params_len);
+ memcpy(transaction->aid, &skb->data[2], aid_len);
+ memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
base-commit: 9d6e67bf50908cc661972969e8f073ec1d1bc97d
--
2.36.1.476.g0c4daa206d-goog
Please backport 5446ff1a6716 ("arm64: dts: imx8mn-beacon: Enable
RTS-CTS on UART3") to 5.15+
This fixes an issue where attempting to use hardware handshaking on
the DB9 port fails.
Thank you,
adam
Please port 4ce01ce36d77 ("arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3")
to 5.10+
This fixes an issue where attempting to use hardware handshaking on
the DB9 port fails.
[Public]
Hi,
The following revert commit went into 5.19:
commit 1039188806d4 ("Revert "drm/amd/display: Fix DCN3 B0 DP Alt Mapping")
The original commit was mistaken and causes USB-C monitors and monitors behind docks to not light up properly.
Can you please bring this into 5.15.y and later?
Thanks,
Hi,
Please apply upstream commit b577d0cd2104 ("9p: missing chunk of
"fs/9p: Don't update file type when updating file attributes"") to
stable versions v4.9, v4.14, v4.19, v5.4, and v5.10.
It fixes an issue found by syzbot:
https://syzkaller.appspot.com/bug?id=7830d7214570b38391194d814a625dbbfd569e…
The commit applies cleanly to all the versions listed above.
Please also add:
Reported-by: syzbot+16342c5db3ef64c0f60a(a)syzkaller.appspotmail.com
Tested-by: Tadeusz Struk <tadeusz.struk(a)linaro.org>
Thanks,
Tadeusz
This is the start of the stable review cycle for the 5.18.5 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +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.18.5-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.18.5-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 72 ++++++
arch/x86/kvm/vmx/vmx.h | 2 +
arch/x86/kvm/x86.c | 3 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 3 +
tools/arch/x86/include/asm/cpufeatures.h | 1 +
tools/arch/x86/include/asm/msr-index.h | 25 +++
17 files changed, 676 insertions(+), 41 deletions(-)
Greetings beloved.
Good morning my beloved how are you doing today? My name is Mrs. Rabi
Affason Marcus; Please I want to confirm if you get my previous mail
concerning the Humanitarian Gesture Project that I need your
assistance to execute? Please I wait for your candid response.
I'm announcing the release of the 5.18.5 kernel.
All users of the 5.18 kernel series must upgrade.
The updated 5.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.18.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 72 ++
arch/x86/kvm/vmx/vmx.h | 2
arch/x86/kvm/x86.c | 3
drivers/base/cpu.c | 8
include/linux/cpu.h | 3
tools/arch/x86/include/asm/cpufeatures.h | 1
tools/arch/x86/include/asm/msr-index.h | 25 +
17 files changed, 675 insertions(+), 40 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.18.5
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
I'm announcing the release of the 5.15.48 kernel.
All users of the 5.15 kernel series must upgrade.
The updated 5.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 72 ++
arch/x86/kvm/vmx/vmx.h | 2
arch/x86/kvm/x86.c | 3
drivers/base/cpu.c | 8
include/linux/cpu.h | 3
tools/arch/x86/include/asm/cpufeatures.h | 1
tools/arch/x86/include/asm/msr-index.h | 25 +
17 files changed, 675 insertions(+), 40 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.15.48
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
I'm announcing the release of the 5.10.123 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 72 ++
arch/x86/kvm/vmx/vmx.h | 2
arch/x86/kvm/x86.c | 3
drivers/base/cpu.c | 8
include/linux/cpu.h | 3
tools/arch/x86/include/asm/cpufeatures.h | 1
tools/arch/x86/include/asm/msr-index.h | 25 +
17 files changed, 675 insertions(+), 40 deletions(-)
Greg Kroah-Hartman (1):
Linux 5.10.123
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
I'm announcing the release of the 5.4.199 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 9
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx/vmx.c | 75 +++
arch/x86/kvm/vmx/vmx.h | 3
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
16 files changed, 663 insertions(+), 41 deletions(-)
Gayatri Kammela (1):
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 5.4.199
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
I'm announcing the release of the 4.19.248 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 11
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx.c | 77 +++
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
15 files changed, 664 insertions(+), 41 deletions(-)
Gayatri Kammela (2):
x86/cpu: Add Elkhart Lake to Intel family
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 4.19.248
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
I'm announcing the release of the 4.14.284 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/admin-guide/hw-vuln/index.rst | 1
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 25 +
arch/x86/include/asm/msr-index.h | 25 +
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++-
arch/x86/kernel/cpu/common.c | 52 +-
arch/x86/kvm/vmx.c | 77 +++
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
15 files changed, 678 insertions(+), 41 deletions(-)
Gayatri Kammela (2):
x86/cpu: Add Elkhart Lake to Intel family
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 4.14.284
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Kan Liang (2):
x86/CPU: Add more Icelake model numbers
x86/cpu: Add Comet Lake to the Intel CPU models header
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Rajneesh Bhardwaj (2):
x86/cpu: Add Cannonlake to Intel family
x86/CPU: Add Icelake model number
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
I'm announcing the release of the 4.9.319 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/ABI/testing/sysfs-devices-system-cpu | 1
Documentation/hw-vuln/index.rst | 1
Documentation/hw-vuln/processor_mmio_stale_data.rst | 246 ++++++++++++++++++++
Documentation/kernel-parameters.txt | 36 ++
Makefile | 2
arch/x86/include/asm/cpufeatures.h | 1
arch/x86/include/asm/intel-family.h | 25 ++
arch/x86/include/asm/msr-index.h | 25 ++
arch/x86/include/asm/nospec-branch.h | 2
arch/x86/kernel/cpu/bugs.c | 235 ++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 +++-
arch/x86/kvm/vmx.c | 77 ++++++
arch/x86/kvm/x86.c | 4
drivers/base/cpu.c | 8
include/linux/cpu.h | 4
15 files changed, 678 insertions(+), 41 deletions(-)
Gayatri Kammela (2):
x86/cpu: Add Elkhart Lake to Intel family
x86/cpu: Add another Alder Lake CPU to the Intel family
Greg Kroah-Hartman (1):
Linux 4.9.319
Guenter Roeck (1):
cpu/speculation: Add prototype for cpu_show_srbds()
Josh Poimboeuf (1):
x86/speculation/mmio: Print SMT warning
Kan Liang (2):
x86/CPU: Add more Icelake model numbers
x86/cpu: Add Comet Lake to the Intel CPU models header
Pawan Gupta (10):
Documentation: Add documentation for Processor MMIO Stale Data
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
x86/speculation: Add a common function for MD_CLEAR mitigation update
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
x86/speculation/srbds: Update SRBDS mitigation selection
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
KVM: x86/speculation: Disable Fill buffer clear within guests
Rajneesh Bhardwaj (2):
x86/cpu: Add Cannonlake to Intel family
x86/CPU: Add Icelake model number
Tony Luck (1):
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui (1):
x86/cpu: Add Jasper Lake to Intel family
This is the start of the stable review cycle for the 4.19.248 release.
There are 16 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.248-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.19.248-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add Elkhart Lake to Intel family
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 11 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx.c | 77 ++++++-
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
15 files changed, 665 insertions(+), 42 deletions(-)
--
Benötigen Sie ein Geschäftsdarlehen oder ein Darlehen jeglicher Art?
Wenn ja, kontaktieren Sie uns
*Vollständiger Name:
* Benötigte Menge:
*Leihdauer:
*Mobiltelefon:
*Land:
This is the start of the stable review cycle for the 5.15.48 release.
There are 11 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +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.15.48-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.15.48-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 72 ++++++
arch/x86/kvm/vmx/vmx.h | 2 +
arch/x86/kvm/x86.c | 3 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 3 +
tools/arch/x86/include/asm/cpufeatures.h | 1 +
tools/arch/x86/include/asm/msr-index.h | 25 +++
17 files changed, 676 insertions(+), 41 deletions(-)
Hi, All
With the 4.14.281 version[1], there were three mmc related changes merged,
but that causes one boot failure with the X15 Android builds, a problem
similar to one reported before here[2].
After being confirmed with Ulf Hansson, and verified with the X15 Android build,
it needs to have the following four commits cherry-picked to the 4.14
branch as well.
4f32b45c9a2c mmc: core: Allow host controllers to require R1B for CMD6
5fc615c1e3eb mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for erase/trim/discard
d091259b8d7a mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep command
23161bed631a mmc: sdhci-omap: Fix busy detection by enabling
MMC_CAP_NEED_RSP_BUSY
The above four commits are from the 4.19 branch, as they are a little
easier to be cherry-picked
into the 4.14 branch, compared to the commits from the mainline branch.
(I have confirmed that the four commits are all in 4.19, 5.4, 5.10 and
mainline branches already).
Saying that, there will be still one merge conflict reported when
cherry picking the commit of
4f32b45c9a2c, it's easy to resolve though.
To avoid the merge conflict, it could be done like this as well:
1. revert the 327b6689898b commit from 4.14 first, so that the commits in step#2
could be cherry-picked without any problem
327b6689898b mmc: core: Default to generic_cmd6_time as
timeout in __mmc_switch()
2. git cherry-pick the following commits from 4.19 into the 4.14 branch
4f32b45c9a2c mmc: core: Allow host controllers to require R1B for CMD6
5fc615c1e3eb mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for
erase/trim/discard
d091259b8d7a mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC
sleep command
23161bed631a mmc: sdhci-omap: Fix busy detection by enabling
MMC_CAP_NEED_RSP_BUSY
26c6f614cf02 mmc: mmc: core: Default to generic_cmd6_time as
timeout in __mmc_switch()
The last commit of 26c6f614cf02 is for the revert in step#1.
I am not sure which way is more convenient for the maintenance work
here, so just list both of them here
for your information.
And please let me know if there is anything else I could help on this
cherry pick work here.
[1]: https://lore.kernel.org/lkml/16534624745741@kroah.com/T/
[2]: https://lore.kernel.org/lkml/CA+G9fYuqAQfhzF2BzHr7vMHx68bo8-jT+ob_F3eHQ3=oF…
--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android
This is the start of the stable review cycle for the 5.4.199 release.
There are 15 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +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.4.199-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.199-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 9 +
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx/vmx.c | 75 ++++++-
arch/x86/kvm/vmx/vmx.h | 3 +
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
16 files changed, 664 insertions(+), 42 deletions(-)
This is the start of the stable review cycle for the 4.14.284 release.
There are 20 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.284-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.284-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Kan Liang <kan.liang(a)linux.intel.com>
x86/cpu: Add Comet Lake to the Intel CPU models header
Kan Liang <kan.liang(a)linux.intel.com>
x86/CPU: Add more Icelake model numbers
Rajneesh Bhardwaj <rajneesh.bhardwaj(a)linux.intel.com>
x86/CPU: Add Icelake model number
Rajneesh Bhardwaj <rajneesh.bhardwaj(a)intel.com>
x86/cpu: Add Cannonlake to Intel family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add Elkhart Lake to Intel family
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/admin-guide/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 25 +++
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx.c | 77 ++++++-
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
15 files changed, 679 insertions(+), 42 deletions(-)
Den 2022-06-14 kl. 20:12, skrev Greg Kroah-Hartman:
> On Tue, Jun 14, 2022 at 10:08:27AM -0700, Guenter Roeck wrote:
>> On Tue, Jun 14, 2022 at 08:36:08AM -0700, Guenter Roeck wrote:
>>> On Mon, Jun 13, 2022 at 08:19:49PM +0200, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 5.15.47 release.
>>>> There are 251 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Wed, 15 Jun 2022 18:18:03 +0000.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Build results:
>>> total: 159 pass: 159 fail: 0
>>> Qemu test results:
>>> total: 488 pass: 488 fail: 0
>>>
>>
>> I spoke a bit too early. I see the following backtrace in some qemu arm
>> boot tests.
>>
>> BUG: spinlock bad magic on CPU#0, kdevtmpfs/15
>> lock: noop_backing_dev_info+0x6c/0x3b0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> CPU: 0 PID: 15 Comm: kdevtmpfs Not tainted 5.15.47-rc2-00252-g677f0128d0ed #1
>> Hardware name: ARM RealView Machine (Device Tree Support)
>> [<c01101d0>] (unwind_backtrace) from [<c010bc0c>] (show_stack+0x10/0x14)
>> [<c010bc0c>] (show_stack) from [<c0a10ae4>] (dump_stack_lvl+0x68/0x90)
>> [<c0a10ae4>] (dump_stack_lvl) from [<c0191250>] (do_raw_spin_lock+0xbc/0x124)
>> [<c0191250>] (do_raw_spin_lock) from [<c02eb578>] (__mark_inode_dirty+0x1cc/0x704)
>> [<c02eb578>] (__mark_inode_dirty) from [<c02e6a74>] (simple_setattr+0x44/0x5c)
>> [<c02e6a74>] (simple_setattr) from [<c02d7a18>] (notify_change+0x400/0x45c)
>> [<c02d7a18>] (notify_change) from [<c0a19ef8>] (devtmpfsd+0x1f8/0x2b8)
>> [<c0a19ef8>] (devtmpfsd) from [<c014cf3c>] (kthread+0x150/0x17c)
>> [<c014cf3c>] (kthread) from [<c0100120>] (ret_from_fork+0x14/0x34)
>> Exception stack(0xd00dbfb0 to 0xd00dbff8)
>> bfa0: 00000000 00000000 00000000 00000000
>> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>
>> This bisects to commit bc5d960d4e58 ("writeback: Fix inode->i_io_list not
>> be protected by inode->i_lock error"). The problem is also seen in the
>> mainline kernel. v5.15.y.queue and later are affected. Reverting the patch
>> here and in mainline fixes the problem.
>
> Thanks for letting me know. Hopefully it gets fixed in upstream...
>
I "think" this is the suggested fix:
https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git/commit/?h…
--
Thomas
The patch titled
Subject: mm/memory-failure: disable unpoison once hw error happens
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
mm-memory-failure-disable-unpoison-once-hw-error-happens.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: zhenwei pi <pizhenwei(a)bytedance.com>
Subject: mm/memory-failure: disable unpoison once hw error happens
Date: Wed, 15 Jun 2022 17:32:09 +0800
Currently unpoison_memory(unsigned long pfn) is designed for soft
poison(hwpoison-inject) only. Since 17fae1294ad9d, the KPTE gets cleared
on a x86 platform once hardware memory corrupts.
Unpoisoning a hardware corrupted page puts page back buddy only, the
kernel has a chance to access the page with *NOT PRESENT* KPTE. This
leads BUG during accessing on the corrupted KPTE.
Suggested by David&Naoya, disable unpoison mechanism when a real HW error
happens to avoid BUG like this:
Unpoison: Software-unpoisoned page 0x61234
BUG: unable to handle page fault for address: ffff888061234000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 2c01067 P4D 2c01067 PUD 107267063 PMD 10382b063 PTE 800fffff9edcb062
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 4 PID: 26551 Comm: stress Kdump: loaded Tainted: G M OE 5.18.0.bm.1-amd64 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...
RIP: 0010:clear_page_erms+0x7/0x10
Code: ...
RSP: 0000:ffffc90001107bc8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000901 RCX: 0000000000001000
RDX: ffffea0001848d00 RSI: ffffea0001848d40 RDI: ffff888061234000
RBP: ffffea0001848d00 R08: 0000000000000901 R09: 0000000000001276
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000140dca R15: 0000000000000001
FS: 00007fd8b2333740(0000) GS:ffff88813fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff888061234000 CR3: 00000001023d2005 CR4: 0000000000770ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
prep_new_page+0x151/0x170
get_page_from_freelist+0xca0/0xe20
? sysvec_apic_timer_interrupt+0xab/0xc0
? asm_sysvec_apic_timer_interrupt+0x1b/0x20
__alloc_pages+0x17e/0x340
__folio_alloc+0x17/0x40
vma_alloc_folio+0x84/0x280
__handle_mm_fault+0x8d4/0xeb0
handle_mm_fault+0xd5/0x2a0
do_user_addr_fault+0x1d0/0x680
? kvm_read_and_reset_apf_flags+0x3b/0x50
exc_page_fault+0x78/0x170
asm_exc_page_fault+0x27/0x30
Link: https://lkml.kernel.org/r/20220615093209.259374-2-pizhenwei@bytedance.com
Fixes: 847ce401df392 ("HWPOISON: Add unpoisoning support")
Fixes: 17fae1294ad9d ("x86/{mce,mm}: Unmap the entire page if the whole page is affected and poisoned")
Signed-off-by: zhenwei pi <pizhenwei(a)bytedance.com>
Acked-by: David Hildenbrand <david(a)redhat.com>
Acked-by: Naoya Horiguchi <naoya.horiguchi(a)nec.com>
Cc: Oscar Salvador <osalvador(a)suse.de>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
Documentation/vm/hwpoison.rst | 3 ++-
drivers/base/memory.c | 2 +-
include/linux/mm.h | 1 +
mm/hwpoison-inject.c | 2 +-
mm/madvise.c | 2 +-
mm/memory-failure.c | 12 ++++++++++++
6 files changed, 18 insertions(+), 4 deletions(-)
--- a/Documentation/vm/hwpoison.rst~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/Documentation/vm/hwpoison.rst
@@ -120,7 +120,8 @@ Testing
unpoison-pfn
Software-unpoison page at PFN echoed into this file. This way
a page can be reused again. This only works for Linux
- injected failures, not for real memory failures.
+ injected failures, not for real memory failures. Once any hardware
+ memory failure happens, this feature is disabled.
Note these injection interfaces are not stable and might change between
kernel versions
--- a/drivers/base/memory.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/drivers/base/memory.c
@@ -558,7 +558,7 @@ static ssize_t hard_offline_page_store(s
if (kstrtoull(buf, 0, &pfn) < 0)
return -EINVAL;
pfn >>= PAGE_SHIFT;
- ret = memory_failure(pfn, 0);
+ ret = memory_failure(pfn, MF_SW_SIMULATED);
if (ret == -EOPNOTSUPP)
ret = 0;
return ret ? ret : count;
--- a/include/linux/mm.h~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/include/linux/mm.h
@@ -3232,6 +3232,7 @@ enum mf_flags {
MF_MUST_KILL = 1 << 2,
MF_SOFT_OFFLINE = 1 << 3,
MF_UNPOISON = 1 << 4,
+ MF_SW_SIMULATED = 1 << 5,
};
extern int memory_failure(unsigned long pfn, int flags);
extern void memory_failure_queue(unsigned long pfn, int flags);
--- a/mm/hwpoison-inject.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/mm/hwpoison-inject.c
@@ -48,7 +48,7 @@ static int hwpoison_inject(void *data, u
inject:
pr_info("Injecting memory failure at pfn %#lx\n", pfn);
- err = memory_failure(pfn, 0);
+ err = memory_failure(pfn, MF_SW_SIMULATED);
return (err == -EOPNOTSUPP) ? 0 : err;
}
--- a/mm/madvise.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/mm/madvise.c
@@ -1112,7 +1112,7 @@ static int madvise_inject_error(int beha
} else {
pr_info("Injecting memory failure for pfn %#lx at process virtual address %#lx\n",
pfn, start);
- ret = memory_failure(pfn, MF_COUNT_INCREASED);
+ ret = memory_failure(pfn, MF_COUNT_INCREASED | MF_SW_SIMULATED);
if (ret == -EOPNOTSUPP)
ret = 0;
}
--- a/mm/memory-failure.c~mm-memory-failure-disable-unpoison-once-hw-error-happens
+++ a/mm/memory-failure.c
@@ -69,6 +69,8 @@ int sysctl_memory_failure_recovery __rea
atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
+static bool hw_memory_failure __read_mostly = false;
+
static bool __page_handle_poison(struct page *page)
{
int ret;
@@ -1768,6 +1770,9 @@ int memory_failure(unsigned long pfn, in
mutex_lock(&mf_mutex);
+ if (!(flags & MF_SW_SIMULATED))
+ hw_memory_failure = true;
+
p = pfn_to_online_page(pfn);
if (!p) {
res = arch_memory_failure(pfn, flags);
@@ -2103,6 +2108,13 @@ int unpoison_memory(unsigned long pfn)
mutex_lock(&mf_mutex);
+ if (hw_memory_failure) {
+ unpoison_pr_info("Unpoison: Disabled after HW memory failure %#lx\n",
+ pfn, &unpoison_rs);
+ ret = -EOPNOTSUPP;
+ goto unlock_mutex;
+ }
+
if (!PageHWPoison(p)) {
unpoison_pr_info("Unpoison: Page was already unpoisoned %#lx\n",
pfn, &unpoison_rs);
_
Patches currently in -mm which might be from pizhenwei(a)bytedance.com are
mm-memory-failure-disable-unpoison-once-hw-error-happens.patch
From: Paolo Bonzini <pbonzini(a)redhat.com>
[ Upstream commit 6cd88243c7e03845a450795e134b488fc2afb736 ]
If a vCPU is outside guest mode and is scheduled out, it might be in the
process of making a memory access. A problem occurs if another vCPU uses
the PV TLB flush feature during the period when the vCPU is scheduled
out, and a virtual address has already been translated but has not yet
been accessed, because this is equivalent to using a stale TLB entry.
To avoid this, only report a vCPU as preempted if sure that the guest
is at an instruction boundary. A rescheduling request will be delivered
to the host physical CPU as an external interrupt, so for simplicity
consider any vmexit *not* instruction boundary except for external
interrupts.
It would in principle be okay to report the vCPU as preempted also
if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
vmentry/vmexit overhead unnecessarily, and optimistic spinning is
also unlikely to succeed. However, leave it for later because right
now kvm_vcpu_check_block() is doing memory accesses. Even
though the TLB flush issue only applies to virtual memory address,
it's very much preferrable to be conservative.
Reported-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/svm/svm.c | 2 ++
arch/x86/kvm/vmx/vmx.c | 1 +
arch/x86/kvm/x86.c | 22 ++++++++++++++++++++++
4 files changed, 28 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 49d814b2a341..a35f5e23fc2a 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -642,6 +642,7 @@ struct kvm_vcpu_arch {
u64 ia32_misc_enable_msr;
u64 smbase;
u64 smi_count;
+ bool at_instruction_boundary;
bool tpr_access_reporting;
bool xsaves_enabled;
u64 ia32_xss;
@@ -1271,6 +1272,8 @@ struct kvm_vcpu_stat {
u64 nested_run;
u64 directed_yield_attempted;
u64 directed_yield_successful;
+ u64 preemption_reported;
+ u64 preemption_other;
u64 guest_mode;
};
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 26f2da1590ed..5b51156712f7 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4263,6 +4263,8 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu,
static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu)
{
+ if (to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_INTR)
+ vcpu->arch.at_instruction_boundary = true;
}
static void svm_sched_in(struct kvm_vcpu *vcpu, int cpu)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 16a660a0ed5f..08f9f05a6cb2 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6390,6 +6390,7 @@ static void handle_external_interrupt_irqoff(struct kvm_vcpu *vcpu)
return;
handle_interrupt_nmi_irqoff(vcpu, gate_offset(desc));
+ vcpu->arch.at_instruction_boundary = true;
}
static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 23905ba3058a..fbf10fa99507 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -277,6 +277,8 @@ const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = {
STATS_DESC_COUNTER(VCPU, nested_run),
STATS_DESC_COUNTER(VCPU, directed_yield_attempted),
STATS_DESC_COUNTER(VCPU, directed_yield_successful),
+ STATS_DESC_COUNTER(VCPU, preemption_reported),
+ STATS_DESC_COUNTER(VCPU, preemption_other),
STATS_DESC_ICOUNTER(VCPU, guest_mode)
};
@@ -4368,6 +4370,19 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
struct kvm_memslots *slots;
static const u8 preempted = KVM_VCPU_PREEMPTED;
+ /*
+ * The vCPU can be marked preempted if and only if the VM-Exit was on
+ * an instruction boundary and will not trigger guest emulation of any
+ * kind (see vcpu_run). Vendor specific code controls (conservatively)
+ * when this is true, for example allowing the vCPU to be marked
+ * preempted if and only if the VM-Exit was due to a host interrupt.
+ */
+ if (!vcpu->arch.at_instruction_boundary) {
+ vcpu->stat.preemption_other++;
+ return;
+ }
+
+ vcpu->stat.preemption_reported++;
if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
return;
@@ -9936,6 +9951,13 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
vcpu->arch.l1tf_flush_l1d = true;
for (;;) {
+ /*
+ * If another guest vCPU requests a PV TLB flush in the middle
+ * of instruction emulation, the rest of the emulation could
+ * use a stale page translation. Assume that any code after
+ * this point can start executing an instruction.
+ */
+ vcpu->arch.at_instruction_boundary = false;
if (kvm_vcpu_running(vcpu)) {
r = vcpu_enter_guest(vcpu);
} else {
--
2.35.1
test_bit(), as any other bitmap op, takes `unsigned long *` as a
second argument (pointer to the actual bitmap), as any bitmap
itself is an array of unsigned longs. However, the ia64_get_irr()
code passes a ref to `u64` as a second argument.
This works with the ia64 bitops implementation due to that they
have `void *` as the second argument and then cast it later on.
This works with the bitmap API itself due to that `unsigned long`
has the same size on ia64 as `u64` (`unsigned long long`), but
from the compiler PoV those two are different.
Define @irr as `unsigned long` to fix that. That implies no
functional changes. Has been hidden for 16 years!
Fixes: a58786917ce2 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations")
Cc: stable(a)vger.kernel.org # 2.6.16+
Reported-by: kernel test robot <lkp(a)intel.com>
Signed-off-by: Alexander Lobakin <alexandr.lobakin(a)intel.com>
---
arch/ia64/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/processor.h b/arch/ia64/include/asm/processor.h
index 7cbce290f4e5..757c2f6d8d4b 100644
--- a/arch/ia64/include/asm/processor.h
+++ b/arch/ia64/include/asm/processor.h
@@ -538,7 +538,7 @@ ia64_get_irr(unsigned int vector)
{
unsigned int reg = vector / 64;
unsigned int bit = vector % 64;
- u64 irr;
+ unsigned long irr;
switch (reg) {
case 0: irr = ia64_getreg(_IA64_REG_CR_IRR0); break;
--
2.36.1
Dear Mr/Mrs,
Let me start by introducing myself. I am Lei Wang, Executive Director and
Chief Financial Officer of Bank of China (Hong Kong).
I will need you to assist me in executing this Business Project from Hong
Kong to your country. Please endeavor to observe utmost discretion in all
matters concerning this issue and If you are interested please get back to
me so I can provide you with more details of this operation.
Kind Regards,
Lei Wang
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f2e19b36593caed4c977c2f55aeba7408aeb2132 Mon Sep 17 00:00:00 2001
From: Martin Faltesek <mfaltesek(a)google.com>
Date: Mon, 6 Jun 2022 21:57:29 -0500
Subject: [PATCH] nfc: st21nfca: fix incorrect sizing calculations in
EVT_TRANSACTION
The transaction buffer is allocated by using the size of the packet buf,
and subtracting two which seem intended to remove the two tags which are
not present in the target structure. This calculation leads to under
counting memory because of differences between the packet contents and the
target structure. The aid_len field is a u8 in the packet, but a u32 in
the structure, resulting in at least 3 bytes always being under counted.
Further, the aid data is a variable length field in the packet, but fixed
in the structure, so if this field is less than the max, the difference is
added to the under counting.
The last validation check for transaction->params_len is also incorrect
since it employs the same accounting error.
To fix, perform validation checks progressively to safely reach the
next field, to determine the size of both buffers and verify both tags.
Once all validation checks pass, allocate the buffer and copy the data.
This eliminates freeing memory on the error path, as those checks are
moved ahead of memory allocation.
Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
Cc: stable(a)vger.kernel.org
Signed-off-by: Martin Faltesek <mfaltesek(a)google.com>
Reviewed-by: Guenter Roeck <groeck(a)chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 8e1113ce139b..df8d27cf2956 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -300,6 +300,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
int r = 0;
struct device *dev = &hdev->ndev->dev;
struct nfc_evt_transaction *transaction;
+ u32 aid_len;
+ u8 params_len;
pr_debug("connectivity gate event: %x\n", event);
@@ -308,50 +310,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
r = nfc_se_connectivity(hdev->ndev, host);
break;
case ST21NFCA_EVT_TRANSACTION:
- /*
- * According to specification etsi 102 622
+ /* According to specification etsi 102 622
* 11.2.2.4 EVT_TRANSACTION Table 52
* Description Tag Length
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
+ *
+ * The key differences are aid storage length is variably sized
+ * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
+ * is u8 in the packet, but u32 in the structure, and the tags in
+ * the packet are not included in nfc_evt_transaction.
+ *
+ * size in bytes: 1 1 5-16 1 1 0-255
+ * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
+ * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
+ * example: 0x81 5-16 X 0x82 0-255 X
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
- skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+ if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
- transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
- if (!transaction)
- return -ENOMEM;
-
- transaction->aid_len = skb->data[1];
+ aid_len = skb->data[1];
- /* Checking if the length of the AID is valid */
- if (transaction->aid_len > sizeof(transaction->aid)) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
+ return -EPROTO;
- memcpy(transaction->aid, &skb->data[2],
- transaction->aid_len);
+ params_len = skb->data[aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
- if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG) {
- devm_kfree(dev, transaction);
+ /* Verify PARAMETERS tag is (82), and final check that there is enough
+ * space in the packet to read everything.
+ */
+ if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
+ (skb->len < aid_len + 4 + params_len))
return -EPROTO;
- }
- transaction->params_len = skb->data[transaction->aid_len + 3];
+ transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
- /* Total size is allocated (skb->len - 2) minus fixed array members */
- if (transaction->params_len > ((skb->len - 2) -
- sizeof(struct nfc_evt_transaction))) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ transaction->aid_len = aid_len;
+ transaction->params_len = params_len;
- memcpy(transaction->params, skb->data +
- transaction->aid_len + 4, transaction->params_len);
+ memcpy(transaction->aid, &skb->data[2], aid_len);
+ memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f2e19b36593caed4c977c2f55aeba7408aeb2132 Mon Sep 17 00:00:00 2001
From: Martin Faltesek <mfaltesek(a)google.com>
Date: Mon, 6 Jun 2022 21:57:29 -0500
Subject: [PATCH] nfc: st21nfca: fix incorrect sizing calculations in
EVT_TRANSACTION
The transaction buffer is allocated by using the size of the packet buf,
and subtracting two which seem intended to remove the two tags which are
not present in the target structure. This calculation leads to under
counting memory because of differences between the packet contents and the
target structure. The aid_len field is a u8 in the packet, but a u32 in
the structure, resulting in at least 3 bytes always being under counted.
Further, the aid data is a variable length field in the packet, but fixed
in the structure, so if this field is less than the max, the difference is
added to the under counting.
The last validation check for transaction->params_len is also incorrect
since it employs the same accounting error.
To fix, perform validation checks progressively to safely reach the
next field, to determine the size of both buffers and verify both tags.
Once all validation checks pass, allocate the buffer and copy the data.
This eliminates freeing memory on the error path, as those checks are
moved ahead of memory allocation.
Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
Cc: stable(a)vger.kernel.org
Signed-off-by: Martin Faltesek <mfaltesek(a)google.com>
Reviewed-by: Guenter Roeck <groeck(a)chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>
Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 8e1113ce139b..df8d27cf2956 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -300,6 +300,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
int r = 0;
struct device *dev = &hdev->ndev->dev;
struct nfc_evt_transaction *transaction;
+ u32 aid_len;
+ u8 params_len;
pr_debug("connectivity gate event: %x\n", event);
@@ -308,50 +310,48 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev *hdev, u8 host,
r = nfc_se_connectivity(hdev->ndev, host);
break;
case ST21NFCA_EVT_TRANSACTION:
- /*
- * According to specification etsi 102 622
+ /* According to specification etsi 102 622
* 11.2.2.4 EVT_TRANSACTION Table 52
* Description Tag Length
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
+ *
+ * The key differences are aid storage length is variably sized
+ * in the packet, but fixed in nfc_evt_transaction, and that the aid_len
+ * is u8 in the packet, but u32 in the structure, and the tags in
+ * the packet are not included in nfc_evt_transaction.
+ *
+ * size in bytes: 1 1 5-16 1 1 0-255
+ * offset: 0 1 2 aid_len + 2 aid_len + 3 aid_len + 4
+ * member name: aid_tag(M) aid_len aid params_tag(M) params_len params
+ * example: 0x81 5-16 X 0x82 0-255 X
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
- skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+ if (skb->len < 2 || skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
- transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
- if (!transaction)
- return -ENOMEM;
-
- transaction->aid_len = skb->data[1];
+ aid_len = skb->data[1];
- /* Checking if the length of the AID is valid */
- if (transaction->aid_len > sizeof(transaction->aid)) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ if (skb->len < aid_len + 4 || aid_len > sizeof(transaction->aid))
+ return -EPROTO;
- memcpy(transaction->aid, &skb->data[2],
- transaction->aid_len);
+ params_len = skb->data[aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
- if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG) {
- devm_kfree(dev, transaction);
+ /* Verify PARAMETERS tag is (82), and final check that there is enough
+ * space in the packet to read everything.
+ */
+ if ((skb->data[aid_len + 2] != NFC_EVT_TRANSACTION_PARAMS_TAG) ||
+ (skb->len < aid_len + 4 + params_len))
return -EPROTO;
- }
- transaction->params_len = skb->data[transaction->aid_len + 3];
+ transaction = devm_kzalloc(dev, sizeof(*transaction) + params_len, GFP_KERNEL);
+ if (!transaction)
+ return -ENOMEM;
- /* Total size is allocated (skb->len - 2) minus fixed array members */
- if (transaction->params_len > ((skb->len - 2) -
- sizeof(struct nfc_evt_transaction))) {
- devm_kfree(dev, transaction);
- return -EINVAL;
- }
+ transaction->aid_len = aid_len;
+ transaction->params_len = params_len;
- memcpy(transaction->params, skb->data +
- transaction->aid_len + 4, transaction->params_len);
+ memcpy(transaction->aid, &skb->data[2], aid_len);
+ memcpy(transaction->params, &skb->data[aid_len + 4], params_len);
r = nfc_se_transaction(hdev->ndev, host, transaction);
break;
How are you doing today? I'm the Chief Executive Officer of the First International Bank of Israel. I have a very lucrative deal to discuss with you.
I will await your response to proceed with the details.
Regards.
Smadar Barber-Tsadik
When ext4_xattr_block_set() decides to remove xattr block the following
race can happen:
CPU1 CPU2
ext4_xattr_block_set() ext4_xattr_release_block()
new_bh = ext4_xattr_block_cache_find()
lock_buffer(bh);
ref = le32_to_cpu(BHDR(bh)->h_refcount);
if (ref == 1) {
...
mb_cache_entry_delete();
unlock_buffer(bh);
ext4_free_blocks();
...
ext4_forget(..., bh, ...);
jbd2_journal_revoke(..., bh);
ext4_journal_get_write_access(..., new_bh, ...)
do_get_write_access()
jbd2_journal_cancel_revoke(..., new_bh);
Later the code in ext4_xattr_block_set() finds out the block got freed
and cancels reusal of the block but the revoke stays canceled and so in
case of block reuse and journal replay the filesystem can get corrupted.
If the race works out slightly differently, we can also hit assertions
in the jbd2 code.
Fix the problem by making sure that once matching mbcache entry is
found, code dropping the last xattr block reference (or trying to modify
xattr block in place) waits until the mbcache entry reference is
dropped. This way code trying to reuse xattr block is protected from
someone trying to drop the last reference to xattr block.
Reported-by: Ritesh Harjani <ritesh.list(a)gmail.com>
CC: stable(a)vger.kernel.org
Fixes: 82939d7999df ("ext4: convert to mbcache2")
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/ext4/xattr.c | 67 +++++++++++++++++++++++++++++++++----------------
1 file changed, 45 insertions(+), 22 deletions(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index aadfae53d055..0c42c0e22cd2 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -439,9 +439,16 @@ static int ext4_xattr_inode_iget(struct inode *parent, unsigned long ea_ino,
/* Remove entry from mbcache when EA inode is getting evicted */
void ext4_evict_ea_inode(struct inode *inode)
{
- if (EA_INODE_CACHE(inode))
- mb_cache_entry_delete(EA_INODE_CACHE(inode),
- ext4_xattr_inode_get_hash(inode), inode->i_ino);
+ struct mb_cache_entry *oe;
+
+ if (!EA_INODE_CACHE(inode))
+ return;
+ /* Wait for entry to get unused so that we can remove it */
+ while ((oe = mb_cache_entry_try_delete(EA_INODE_CACHE(inode),
+ ext4_xattr_inode_get_hash(inode), inode->i_ino))) {
+ mb_cache_entry_wait_unused(oe);
+ mb_cache_entry_put(EA_INODE_CACHE(inode), oe);
+ }
}
static int
@@ -1229,6 +1236,7 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
if (error)
goto out;
+retry_ref:
lock_buffer(bh);
hash = le32_to_cpu(BHDR(bh)->h_hash);
ref = le32_to_cpu(BHDR(bh)->h_refcount);
@@ -1238,9 +1246,18 @@ ext4_xattr_release_block(handle_t *handle, struct inode *inode,
* This must happen under buffer lock for
* ext4_xattr_block_set() to reliably detect freed block
*/
- if (ea_block_cache)
- mb_cache_entry_delete(ea_block_cache, hash,
- bh->b_blocknr);
+ if (ea_block_cache) {
+ struct mb_cache_entry *oe;
+
+ oe = mb_cache_entry_try_delete(ea_block_cache, hash,
+ bh->b_blocknr);
+ if (oe) {
+ unlock_buffer(bh);
+ mb_cache_entry_wait_unused(oe);
+ mb_cache_entry_put(ea_block_cache, oe);
+ goto retry_ref;
+ }
+ }
get_bh(bh);
unlock_buffer(bh);
@@ -1867,9 +1884,20 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
* ext4_xattr_block_set() to reliably detect modified
* block
*/
- if (ea_block_cache)
- mb_cache_entry_delete(ea_block_cache, hash,
- bs->bh->b_blocknr);
+ if (ea_block_cache) {
+ struct mb_cache_entry *oe;
+
+ oe = mb_cache_entry_try_delete(ea_block_cache,
+ hash, bs->bh->b_blocknr);
+ if (oe) {
+ /*
+ * Xattr block is getting reused. Leave
+ * it alone.
+ */
+ mb_cache_entry_put(ea_block_cache, oe);
+ goto clone_block;
+ }
+ }
ea_bdebug(bs->bh, "modifying in-place");
error = ext4_xattr_set_entry(i, s, handle, inode,
true /* is_block */);
@@ -1885,6 +1913,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
goto cleanup;
goto inserted;
}
+clone_block:
unlock_buffer(bs->bh);
ea_bdebug(bs->bh, "cloning");
s->base = kmalloc(bs->bh->b_size, GFP_NOFS);
@@ -1991,18 +2020,13 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
lock_buffer(new_bh);
/*
* We have to be careful about races with
- * freeing, rehashing or adding references to
- * xattr block. Once we hold buffer lock xattr
- * block's state is stable so we can check
- * whether the block got freed / rehashed or
- * not. Since we unhash mbcache entry under
- * buffer lock when freeing / rehashing xattr
- * block, checking whether entry is still
- * hashed is reliable. Same rules hold for
- * e_reusable handling.
+ * adding references to xattr block. Once we
+ * hold buffer lock xattr block's state is
+ * stable so we can check the additional
+ * reference fits.
*/
- if (hlist_bl_unhashed(&ce->e_hash_list) ||
- !ce->e_reusable) {
+ ref = le32_to_cpu(BHDR(new_bh)->h_refcount) + 1;
+ if (ref > EXT4_XATTR_REFCOUNT_MAX) {
/*
* Undo everything and check mbcache
* again.
@@ -2017,9 +2041,8 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
new_bh = NULL;
goto inserted;
}
- ref = le32_to_cpu(BHDR(new_bh)->h_refcount) + 1;
BHDR(new_bh)->h_refcount = cpu_to_le32(ref);
- if (ref >= EXT4_XATTR_REFCOUNT_MAX)
+ if (ref == EXT4_XATTR_REFCOUNT_MAX)
ce->e_reusable = 0;
ea_bdebug(new_bh, "reusing; refcount now=%d",
ref);
--
2.35.3
commit <88467db6e2f46a2e79b1b67ce6873c284e4cf417> upstream
Backport from upstream to match function amdgpu_vm_bo_update_mapping
change.
Migration range from system memory to VRAM, if system page can not be
locked or unmapped, we do partial migration and leave some pages in
system memory. Several bugs found to copy pages and update GPU mapping
for this situation:
1. copy to vram should use migrate->npage which is total pages of range
as npages, not migrate->cpages which is number of pages can be migrated.
2. After partial copy, set VRAM res cursor as j + 1, j is number of
system pages copied plus 1 page to skip copy.
3. copy to ram, should collect all continuous VRAM pages and copy
together.
4. Call amdgpu_vm_update_range, should pass in offset as bytes, not
as number of pages.
Signed-off-by: Philip Yang <Philip.Yang(a)amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index ed5385137f48..9d5324b6298c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -299,7 +299,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, struct svm_range *prange,
struct migrate_vma *migrate, struct dma_fence **mfence,
dma_addr_t *scratch)
{
- uint64_t npages = migrate->cpages;
+ uint64_t npages = migrate->npages;
struct device *dev = adev->dev;
struct amdgpu_res_cursor cursor;
dma_addr_t *src;
@@ -346,7 +346,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, struct svm_range *prange,
mfence);
if (r)
goto out_free_vram_pages;
- amdgpu_res_next(&cursor, j << PAGE_SHIFT);
+ amdgpu_res_next(&cursor, (j + 1) << PAGE_SHIFT);
j = 0;
} else {
amdgpu_res_next(&cursor, PAGE_SIZE);
@@ -593,7 +593,7 @@ svm_migrate_copy_to_ram(struct amdgpu_device *adev, struct svm_range *prange,
continue;
}
src[i] = svm_migrate_addr(adev, spage);
- if (i > 0 && src[i] != src[i - 1] + PAGE_SIZE) {
+ if (j > 0 && src[i] != src[i - 1] + PAGE_SIZE) {
r = svm_migrate_copy_memory_gart(adev, dst + i - j,
src + i - j, j,
FROM_VRAM_TO_RAM,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index f2805ba74c80..6d108dbbabdc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1275,7 +1275,7 @@ svm_range_map_to_gpu(struct amdgpu_device *adev, struct amdgpu_vm *vm,
r = amdgpu_vm_bo_update_mapping(adev, bo_adev, vm, false, false,
NULL, last_start,
prange->start + i, pte_flags,
- last_start - prange->start,
+ (last_start - prange->start) << PAGE_SHIFT,
NULL, dma_addr,
&vm->last_update,
&table_freed);
--
2.35.1
From: He Ying <heying24(a)huawei.com>
[ Upstream commit a1b29ba2f2c171b9bea73be993bfdf0a62d37d15 ]
The following KASAN warning was reported in our kernel.
BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
Read of size 4 at addr d216f958 by task ps/14437
CPU: 3 PID: 14437 Comm: ps Tainted: G O 5.10.0 #1
Call Trace:
[daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
[daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
[daa63908] [c035d6bc] kasan_report+0x1ac/0x218
[daa63948] [c00496e8] get_wchan+0x188/0x250
[daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
[daa63b98] [c0455ac8] proc_single_show+0x98/0x170
[daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
[daa63c38] [c03cb47c] seq_read+0x1dc/0x290
[daa63d68] [c037fc94] vfs_read+0x164/0x510
[daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
[daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
--- interrupt: c00 at 0x8fa8f4
LR = 0x8fa8cc
The buggy address belongs to the page:
page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
flags: 0x0()
raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
^
d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35ddff ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.
As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.
Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: Wanming Hu <huwanming(a)huaweil.com>
Signed-off-by: He Ying <heying24(a)huawei.com>
Signed-off-by: Chen Jingwen <chenjingwen6(a)huawei.com>
Reviewed-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20220121014418.155675-1-heying24@huawei.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/powerpc/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 984813a4d5dc..a75d20f23dac 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2160,12 +2160,12 @@ static unsigned long ___get_wchan(struct task_struct *p)
return 0;
do {
- sp = *(unsigned long *)sp;
+ sp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD) ||
task_is_running(p))
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
+ ip = READ_ONCE_NOCHECK(((unsigned long *)sp)[STACK_FRAME_LR_SAVE]);
if (!in_sched_functions(ip))
return ip;
}
--
2.35.1
--
--
CONGRATULATION
This is to inform you that your name was among the 18 listed
beneficiaries to benefit from this second batch of overdue Scam
victims compensation payment for the year 2022.
The payment was approved after the meeting held on May 25 with (G20)
and (UN) on World Economic Forum Annual Meeting 2022 and it was sign
that 18 listed beneficiaries will receive US$1,000,000.00 each as
their overdue scam victim compensation payment and your name and
contact email was included as one of the beneficiary, So contact Mr.
Steven Schnall Of Quontic Bank Of New York to receive your approved
compensation payment.
Person to contact: Mr. Steven Schnall (Quontic Bank CEO)
E-mail: quontiinfo(a)gmail.com
E-mail: quonticbnk22(a)msgden.net
Note instructions have been given to Quontic Bank Of New York to
release your Scam victims compensation Fund US$1,000,000.00 to you VIA
direct transfer or by ATM CARD.
Thanks,
Yours In Service
UN Secretary General
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d251b718bf53..5482f47cb07d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2995,8 +2995,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 87d522eefbb4..de6c66521744 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3036,8 +3036,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3d45ce134227..d3a2eb8ee04e 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3193,8 +3193,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 287444e52ccf..4b445dddb798 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3329,8 +3329,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ]
A KVM device cleanup happens in either of two callbacks:
1) destroy() which is called when the VM is being destroyed;
2) release() which is called when a device fd is closed.
Most KVM devices use 1) but Book3s's interrupt controller KVM devices
(XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during
the machine execution. The error handling in kvm_ioctl_create_device()
assumes destroy() is always defined which leads to NULL dereference as
discovered by Syzkaller.
This adds a checks for destroy!=NULL and adds a missing release().
This is not changing kvm_destroy_devices() as devices with defined
release() should have been removed from the KVM devices list by then.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
virt/kvm/kvm_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9cd8ca2d8bc1..c5dbac10c372 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3644,8 +3644,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
kvm_put_kvm_no_destroy(kvm);
mutex_lock(&kvm->lock);
list_del(&dev->vm_node);
+ if (ops->release)
+ ops->release(dev);
mutex_unlock(&kvm->lock);
- ops->destroy(dev);
+ if (ops->destroy)
+ ops->destroy(dev);
return ret;
}
--
2.35.1
From: Paolo Bonzini <pbonzini(a)redhat.com>
[ Upstream commit 6cd88243c7e03845a450795e134b488fc2afb736 ]
If a vCPU is outside guest mode and is scheduled out, it might be in the
process of making a memory access. A problem occurs if another vCPU uses
the PV TLB flush feature during the period when the vCPU is scheduled
out, and a virtual address has already been translated but has not yet
been accessed, because this is equivalent to using a stale TLB entry.
To avoid this, only report a vCPU as preempted if sure that the guest
is at an instruction boundary. A rescheduling request will be delivered
to the host physical CPU as an external interrupt, so for simplicity
consider any vmexit *not* instruction boundary except for external
interrupts.
It would in principle be okay to report the vCPU as preempted also
if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the
vmentry/vmexit overhead unnecessarily, and optimistic spinning is
also unlikely to succeed. However, leave it for later because right
now kvm_vcpu_check_block() is doing memory accesses. Even
though the TLB flush issue only applies to virtual memory address,
it's very much preferrable to be conservative.
Reported-by: Jann Horn <jannh(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/svm/svm.c | 2 ++
arch/x86/kvm/vmx/vmx.c | 1 +
arch/x86/kvm/x86.c | 22 ++++++++++++++++++++++
4 files changed, 28 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index c4b4c0839dbd..db5d454cdf8f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -646,6 +646,7 @@ struct kvm_vcpu_arch {
u64 ia32_misc_enable_msr;
u64 smbase;
u64 smi_count;
+ bool at_instruction_boundary;
bool tpr_access_reporting;
bool xsaves_enabled;
bool xfd_no_write_intercept;
@@ -1283,6 +1284,8 @@ struct kvm_vcpu_stat {
u64 nested_run;
u64 directed_yield_attempted;
u64 directed_yield_successful;
+ u64 preemption_reported;
+ u64 preemption_other;
u64 guest_mode;
};
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index fd3a00c892c7..0b8364f8415c 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -4182,6 +4182,8 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu,
static void svm_handle_exit_irqoff(struct kvm_vcpu *vcpu)
{
+ if (to_svm(vcpu)->vmcb->control.exit_code == SVM_EXIT_INTR)
+ vcpu->arch.at_instruction_boundary = true;
}
static void svm_sched_in(struct kvm_vcpu *vcpu, int cpu)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index c87be7c52cc2..39a908e3da5a 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6550,6 +6550,7 @@ static void handle_external_interrupt_irqoff(struct kvm_vcpu *vcpu)
return;
handle_interrupt_nmi_irqoff(vcpu, gate_offset(desc));
+ vcpu->arch.at_instruction_boundary = true;
}
static void vmx_handle_exit_irqoff(struct kvm_vcpu *vcpu)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5204283da798..8445d1d35c79 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -287,6 +287,8 @@ const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = {
STATS_DESC_COUNTER(VCPU, nested_run),
STATS_DESC_COUNTER(VCPU, directed_yield_attempted),
STATS_DESC_COUNTER(VCPU, directed_yield_successful),
+ STATS_DESC_COUNTER(VCPU, preemption_reported),
+ STATS_DESC_COUNTER(VCPU, preemption_other),
STATS_DESC_ICOUNTER(VCPU, guest_mode)
};
@@ -4573,6 +4575,19 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
struct kvm_memslots *slots;
static const u8 preempted = KVM_VCPU_PREEMPTED;
+ /*
+ * The vCPU can be marked preempted if and only if the VM-Exit was on
+ * an instruction boundary and will not trigger guest emulation of any
+ * kind (see vcpu_run). Vendor specific code controls (conservatively)
+ * when this is true, for example allowing the vCPU to be marked
+ * preempted if and only if the VM-Exit was due to a host interrupt.
+ */
+ if (!vcpu->arch.at_instruction_boundary) {
+ vcpu->stat.preemption_other++;
+ return;
+ }
+
+ vcpu->stat.preemption_reported++;
if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
return;
@@ -10261,6 +10276,13 @@ static int vcpu_run(struct kvm_vcpu *vcpu)
vcpu->arch.l1tf_flush_l1d = true;
for (;;) {
+ /*
+ * If another guest vCPU requests a PV TLB flush in the middle
+ * of instruction emulation, the rest of the emulation could
+ * use a stale page translation. Assume that any code after
+ * this point can start executing an instruction.
+ */
+ vcpu->arch.at_instruction_boundary = false;
if (kvm_vcpu_running(vcpu)) {
r = vcpu_enter_guest(vcpu);
} else {
--
2.35.1