From: Ritesh Harjani <riteshh(a)linux.ibm.com>
commit cc16eecae687912238ee6efbff71ad31e2bc414e upstream.
jbd2_journal_wait_updates() is called with j_state_lock held. But if
there is a commit in progress, then this transaction might get committed
and freed via jbd2_journal_commit_transaction() ->
jbd2_journal_free_transaction(), when we release j_state_lock.
So check for journal->j_running_transaction everytime we release and
acquire j_state_lock to avoid use-after-free issue.
Link: https://lore.kernel.org/r/948c2fed518ae739db6a8f7f83f1d58b504f87d0.16444971…
Fixes: 4f98186848707f53 ("jbd2: refactor wait logic for transaction updates into a common function")
Cc: stable(a)kernel.org
Reported-and-tested-by: syzbot+afa2ca5171d93e44b348(a)syzkaller.appspotmail.com
Reviewed-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Ritesh Harjani <riteshh(a)linux.ibm.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
[backport to 4.9-4.19 in original jbd2_journal_commit_transaction()
location before the refactor in
4f9818684870 "jbd2: refactor wait logic for transaction updates into a
common function"]
Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com>
Fixes: 1da177e4c3f41524
Cc: stable(a)kernel.org # 4.9.x - 4.19.x
---
While marked for 5.17 stable, it looks like this fix also applies to the
original location in jbd2_journal_commit_transaction() before it was
refactored to use jbd2_journal_wait_updates(). This applies the same
change there.
fs/jbd2/commit.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index 97760cb9bcd7..66e776eb5ea7 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -382,6 +382,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
int csum_size = 0;
LIST_HEAD(io_bufs);
LIST_HEAD(log_bufs);
+ DEFINE_WAIT(wait);
if (jbd2_journal_has_csum_v2or3(journal))
csum_size = sizeof(struct jbd2_journal_block_tail);
@@ -434,22 +435,25 @@ void jbd2_journal_commit_transaction(journal_t *journal)
stats.run.rs_running = jbd2_time_diff(commit_transaction->t_start,
stats.run.rs_locked);
- spin_lock(&commit_transaction->t_handle_lock);
- while (atomic_read(&commit_transaction->t_updates)) {
- DEFINE_WAIT(wait);
+ while (1) {
+ commit_transaction = journal->j_running_transaction;
+ if (!commit_transaction)
+ break;
+ spin_lock(&commit_transaction->t_handle_lock);
prepare_to_wait(&journal->j_wait_updates, &wait,
TASK_UNINTERRUPTIBLE);
- if (atomic_read(&commit_transaction->t_updates)) {
+ if (!atomic_read(&commit_transaction->t_updates)) {
spin_unlock(&commit_transaction->t_handle_lock);
- write_unlock(&journal->j_state_lock);
- schedule();
- write_lock(&journal->j_state_lock);
- spin_lock(&commit_transaction->t_handle_lock);
+ finish_wait(&journal->j_wait_updates, &wait);
+ break;
}
+ spin_unlock(&commit_transaction->t_handle_lock);
+ write_unlock(&journal->j_state_lock);
+ schedule();
finish_wait(&journal->j_wait_updates, &wait);
+ write_lock(&journal->j_state_lock);
}
- spin_unlock(&commit_transaction->t_handle_lock);
J_ASSERT (atomic_read(&commit_transaction->t_outstanding_credits) <=
journal->j_max_transaction_buffers);
--
2.25.1
Hi,
Kernel test bot reported that the ia64 build error on stable 4.19.y because
of the commit d3380de483d5 ("ia64: kprobes: Use generic kretprobe trampoline
handler").
I also found that this commit was involved by the backporting of commit
f5f96e3643dc ("ia64: kprobes: Fix to pass correct trampoline address to the
handler"), and this 2nd commit was backported wrong way. Actually, this 2nd
commit aimed to use dereference_function_descriptor() in kprobes@ia64, but
the comment (and Fixes tag) points the 1st commit. Thus I guess this mistake
happened.
So I re-backport the upstream commit a7fe2378454c ("ia64: kprobes: Fix to
pass correct trampoline address to the handler") correctly, without involving
the 1st commit.
Thank you,
---
Masami Hiramatsu (3):
Revert "ia64: kprobes: Fix to pass correct trampoline address to the handler"
Revert "ia64: kprobes: Use generic kretprobe trampoline handler"
ia64: kprobes: Fix to pass correct trampoline address to the handler
arch/ia64/kernel/kprobes.c | 78 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 75 insertions(+), 3 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
Hi Greg,
Here are two custom backports to v4.19 for some powerpc issues we've discovered.
Both were fixed upstream as part of a large non-backportable rewrite. Other stable
kernel versions are not affected.
cheers
Michael Ellerman (1):
powerpc/64s: Unmerge EX_LR and EX_DAR
Nicholas Piggin (1):
powerpc/64/interrupt: Temporarily save PPR on stack to fix register
corruption due to SLB miss
arch/powerpc/include/asm/exception-64s.h | 37 ++++++++++++++----------
1 file changed, 22 insertions(+), 15 deletions(-)
--
2.35.1
Hi all,
Commit 3db09e762dc79584a69c10d74a6b98f89a9979f8 upstream ("net/sched:
cls_u32: fix netns refcount changes in u32_change()") fixes a crash
and seems like a good candidate for stable trees.
The change fixes 35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before
call_rcu()"), which was added in 4.14, so I think it might make sense
to cherry-pick the fix to 4.14+.
Let me know what you think.
Thanks,
-Robert
From: Lin Ma <linma(a)zju.edu.cn>
commit 0b9111922b1f399aba6ed1e1b8f2079c3da1aed8 upstream.
There is a possible race condition (use-after-free) like below
(USE) | (FREE)
dev_queue_xmit |
__dev_queue_xmit |
__dev_xmit_skb |
sch_direct_xmit | ...
xmit_one |
netdev_start_xmit | tty_ldisc_kill
__netdev_start_xmit | 6pack_close
sp_xmit | kfree
sp_encaps |
|
According to the patch "defer ax25 kfree after unregister_netdev", this
patch reorder the kfree after the unregister_netdev to avoid the possible
UAF as the unregister_netdev() is well synchronized and won't return if
there is a running routine.
Signed-off-by: Lin Ma <linma(a)zju.edu.cn>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Xu Jia <xujia39(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Ovidiu Panait <ovidiu.panait(a)windriver.com>
---
These commits are part of CVE-2022-1195 patchset.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2056381
[1] https://github.com/torvalds/linux/commit/3e0588c291d6ce225f2b891753ca41d45b…
[2] https://github.com/torvalds/linux/commit/b2f37aead1b82a770c48b5d583f35ec22a…
[3] https://github.com/torvalds/linux/commit/0b9111922b1f399aba6ed1e1b8f2079c3d…
[4] https://github.com/torvalds/linux/commit/81b1d548d00bcd028303c4f3150fa753b9…
Commits [1] and [2] are already present in 5.4-stable, this patchset includes
backports for [3] and [4] (clean cherry-picks from 5.10 stable).
drivers/net/hamradio/6pack.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 02d6f3ad9aca..82507a688efe 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -679,9 +679,11 @@ static void sixpack_close(struct tty_struct *tty)
del_timer_sync(&sp->tx_t);
del_timer_sync(&sp->resync_t);
- /* Free all 6pack frame buffers. */
+ /* Free all 6pack frame buffers after unreg. */
kfree(sp->rbuff);
kfree(sp->xbuff);
+
+ free_netdev(sp->dev);
}
/* Perform I/O control on an active 6pack channel. */
--
2.36.0
Even if SPI_NOR_NO_ERASE was specified at flash declaration, the erase
type of size nor->info->sector_size was incorrectly set as supported.
Don't set erase types when SPI_NOR_NO_ERASE is set.
Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR")
Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com>
Cc: stable(a)vger.kernel.org
---
v2:
- add comment, update commit message, split change in individual commit
- add fixes tag and cc to stable.
drivers/mtd/spi-nor/core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index b4f141ad9c9c..64cf7b9df621 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2392,6 +2392,10 @@ static void spi_nor_no_sfdp_init_params(struct spi_nor *nor)
SPINOR_OP_PP, SNOR_PROTO_8_8_8_DTR);
}
+ /* Skip setting erase types when SPI_NOR_NO_ERASE is set. */
+ if (nor->info->flags & SPI_NOR_NO_ERASE)
+ return;
+
/*
* Sector Erase settings. Sort Erase Types in ascending order, with the
* smallest erase size starting at BIT(0).
--
2.25.1