| Age | Commit message (Collapse) | Author |
|---|
|
panic() is __noreturn, so the else after panic_try_start() is dead. Drop
it so the force_cpu path can be added cleanly on top.
Link: https://lore.kernel.org/20260916182957.7788-3-brads@mainlining.org
Signed-off-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Guenetr Roeck <linux@roeck-us.net>
Cc: Sashiko <sashiko-bot@kernel.org>
Cc: Wang Jinchao <wangjinchao600@gmail.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: <stable@vger.kernel.org>
|
|
Patch series "panic: fix panic_force_cpu= redirect races and NMI bypass",
v7.
The panic_force_cpu= parameter redirects a panic to a specific CPU so the
crash kernel runs there. The redirect code in panic_try_force_cpu() had
two races and an NMI bypass, all found by Sashiko. This series closes
them and kills one more hack that the rework turned up.
Panic from NMI still goes through the redirect path first, so the crash
kernel ends up on the CPU the admin asked for. The redirect buffer is a
static 1KB now, no initcall, no fallback message.
This patch (of 6):
The cmpxchg() in panic_try_force_cpu() makes sure that only one CPU tries
to redirect panic() to the requested CPU. It is similar to the cmpxchg()
in panic_try_start() which makes sure that only one CPU does the panic().
In both situations, only the winner of cmpxchg() should proceed further.
Other CPUs should go offline.
There is a bug because the cmpxchg loser returns false and falls through
into vpanic(). Two non-target CPUs A and B panic, the requested CPU is C:
cpu A cpu B
---------- ----------
panic() panic()
vpanic() vpanic()
panic_try_force_cpu() panic_try_force_cpu()
cmpxchg wins cmpxchg fails
redirect = A old_cpu = A
IPI -> C return false <- BUG
return true panic_try_start() wins
panic_smp_self_stop() __crash_kexec() on B
(A stops) (target C bypassed)
The loser must stop, not fall through. It cannot just return true,
though. A CPU that already won the redirect cmpxchg can reenter
panic_try_force_cpu() on the same CPU, for example a nested NMI during the
message formatting, before the IPI is sent:
cpu A (1st) cpu A (nested)
---------- ----------
panic()
vpanic()
panic_try_force_cpu()
cmpxchg wins (redirect = A)
vsnprintf(msg) ...
<-- NMI, nested panic -->
panic()
vpanic()
panic_try_force_cpu()
cmpxchg fails
old_cpu == A (this CPU)
return true <- would halt
panic_smp_self_stop()
(IPI never sent, panic abandoned)
Check old_cpu against this_cpu so a second call from the same CPU returns
false and falls through to panic_try_start() instead.
Also fix the panic_in_progress() check. We must not redirect when
panic_cpu is already assigned. Return true to stop when the panic is on
another CPU, false to proceed when it is this one.
Update the panic_try_force_cpu() doc comment for the new return value
semantics.
Link: https://lore.kernel.org/20260916182957.7788-1-brads@mainlining.org
Link: https://lore.kernel.org/20260916182957.7788-2-brads@mainlining.org
Fixes: 2e171ab29f91 ("panic: add panic_force_cpu= parameter to redirect panic to a specific CPU")
Signed-off-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260705164123.18746-1-include@grrlz.net
Closes: https://sashiko.dev/#/patchset/20260707172252.4842-1-include@grrlz.net
Reviewed-by: Petr Mladek <pmladek@suse.com>
Cc: Guenetr Roeck <linux@roeck-us.net>
Cc: Wang Jinchao <wangjinchao600@gmail.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
Cc: <stable@vger.kernel.org>
|
|
I assume that the ordering should be done in default (C) locale as other
gives more lines shuffled. Fix the ordering accordingly. With that being
said, clearly make at the top header how it should be sorted.
Note, I took some empirical assumptions that people usually put their
names in accordance with the First name(s) Last Name(s) split based on the
records around (before and after the move). I hope I made no or little
amount of mistakes. In any case it's just a dozen of names to update.
Link: https://lore.kernel.org/20260915084248.3460260-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: AngeloGiaocchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: Mathias Brugger <matthias.bgg@gmail.com>
|
|
In iomem_map_sanity_check() a piece of code resembles the content of the
resource_overlaps(). Replace open coded piece with the call to the
existing helper.
Link: https://lore.kernel.org/20260915085353.3518153-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>
|
|
Mounting a crafted OCFS2 image can corrupt kernel memory. When the
local quota file header of such an image claims zero chunks, the first
quota entry allocated during the mount gets a chunk number taken from a
kernel pointer, and releasing that entry clears a bit far outside the
chunk bitmap.
The write will corrupt the data stored at that address, and the
corruption may lead to a system crash or damage unrelated data.
Mounting requires CAP_SYS_ADMIN, so it takes an untrusted image, such
as removable media or a loop mount of a file from elsewhere.
Since the chunk number comes from a kernel pointer, the address of the
bit that gets cleared differs from boot to boot, and the issue has been
reported under several titles:
- BUG: unable to handle kernel paging request in ocfs2_local_release_dquot
- KASAN: use-after-free Write in ocfs2_local_release_dquot
- KASAN: slab-out-of-bounds Write in ocfs2_local_release_dquot
- KASAN: slab-use-after-free Write in ocfs2_local_release_dquot
- KFENCE: use-after-free write in ocfs2_local_release_dquot
Note that none of these is a use-after-free in the quota code: the
chunk and its buffer head are alive. The bit that gets cleared lies
far outside the bitmap. KASAN and KFENCE name each report based on the
object occupying that address, which explains why the same issue is
reported under so many different titles. In the report I sent, the
address fell in a free page, which KASAN labels use-after-free.
There are known reproducers. Both a syzkaller and a C reproducer are
available from the Google Drive link [1] in my report thread. The
issue was found by our modified syzkaller, not a theoretical thing
found by an LLM. I have not seen it outside fuzzing, so it is not
affecting me in the real world.
The local quota file in OCFS2 is divided into chunks, and each chunk
begins with a header block holding a bitmap of the quota entries that
chunk has handed out. Chunks are numbered from zero, and that number is
used to convert the file offset of an entry back into a bit position in
the bitmap. ocfs2_local_quota_add_chunk() appends a new chunk to the
in-memory list and numbers it one past the chunk that was last:
list_add_tail(&chunk->qc_chunk, &oinfo->dqi_chunk);
chunk->qc_num = list_entry(chunk->qc_chunk.prev,
struct ocfs2_quota_chunk,
qc_chunk)->qc_num + 1;
The predecessor is looked up after the new chunk is added to the list, so
if the list was empty, the prev pointer is the list head itself. The head
is the dqi_chunk member of struct ocfs2_mem_dqinfo and is not a chunk, so
reading qc_num through it lands 16 bytes past the start of the head, on
the dqi_gqinode pointer that follows it. The first chunk of the file is
then numbered with the lower half of a kernel pointer instead of 0.
The list is empty when the local quota file header claims the file has no
chunks. ocfs2_local_read_info() takes dqi_chunks from that header without
validating it, so an image with dqi_chunks == 0 takes this path when the
first quota entry is allocated.
ocfs2_create_local_dquot() turns the bad number into a file offset with
ol_dqblk_off(), which shifts a 32-bit block number left by the block size
bits, so the top bits of such a large block number are lost.
ocfs2_local_release_dquot() turns the offset back into a bit index with
ol_dqblk_chunk_off(), using the full chunk number, so the lost bits push
that index far outside the bitmap, and clearing it corrupts unrelated
memory.
Compute the chunk number before putting the chunk on the list, and use 0
when the list is empty.
Link: https://lore.kernel.org/20260914034940.4070970-1-r772577952@gmail.com
Link: https://drive.google.com/drive/folders/1-LzPTgOALEc3eOjmgM6oOfRKkYXJ-bnO?usp=drive_link [1]
Fixes: 9e33d69f553a ("ocfs2: Implementation of local and global quota file handling")
Signed-off-by: Jiaming Zhang <r772577952@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Closes: https://lore.kernel.org/lkml/CANypQFZ05tpth0Xc33gmP6jgPnkY4VuezyHcsajV-SqCsmN_gg@mail.gmail.com/
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Assisted-by: Claude Code:claude-opus-5
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Jun Piao <piaojun@huawei.com>
Cc: Heming Zhao <heming.zhao@suse.com>
Cc: <stable@vger.kernel.org>
|
|
CPU_DONT_CARE was added by the original listener cpumask code in 2006
(f9fd8914c1ac) and has never had a single user, not even in the
commit that introduced it. It survived every refactor of the listener
path since, including the recent handler folds.
Kill it, twenty years is enough.
Link: https://lore.kernel.org/20260915180623.22058-1-brads@mainlining.org
Signed-off-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Balbir Singh <balbirs@nvidia.com>
|
|
We found and validated an issue in lib/decompress_unlz4.c. The bug is
reachable by a root user through kexec_file_load() with a crafted external
initrd.
unlz4() reads the compressed chunk length from an in-memory initrd and
passes it to LZ4_decompress_safe(). It only checks the chunk length
against the allocation size when the input is filled by a callback.
Reject an in-memory chunk that extends past the remaining input before
calling the LZ4 decoder. This prevents malformed initrds from making
the decoder read past the mapped archive.
Link: https://lore.kernel.org/59c6555c27aa7ba18ee227f9f02c78d15a37605f.1789219453.git.zhilinz@nebusec.ai
Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel")
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: VEGA <vega@nebusec.ai>
Assisted-by: LLM
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
|
|
A use-after-free vulnerability was identified in mport_mm_close() in
drivers/rapidio/devices/rio_mport_cdev.c, identical to the pattern
previously addressed in dma_req_free().
This is observable from userspace when an application creates an mmap
mapping via the RapidIO character device and subsequently unmaps it (or
terminates, triggering exit_mmap()). During munmap, mport_mm_close() is
invoked and drops the mapping reference via kref_put().
If kref_put() drops the last reference, mport_release_mapping() is called,
which frees the underlying rio_mport_mapping structure. The subsequent
mutex_unlock() then dereferences map->md to unlock buf_mutex, leading to a
use-after-free:
mport_mm_close()
-> mutex_lock(&map->md->buf_mutex);
...
-> kref_put(&map->ref, mport_release_mapping); /* map is freed */
-> mutex_unlock(&map->md->buf_mutex); /* UAF: map used */
Fix this by caching map->md before kref_put() and using the cached pointer
for mutex unlocking, ensuring that freed memory is not accessed.
Link: https://lore.kernel.org/20260914042327.49798-1-james010kim@gmail.com
Fixes: e8de370188d0 ("rapidio: add mport char device driver")
Signed-off-by: James Kim <james010kim@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexandre Bounine <alex.bou9@gmail.com>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: <stable@vger.kernel.org>
|
|
Patches sent from andrey.golovko@gmail.com carry the authorship of my
commits, but some of the tags I gave on other people's patches use
andrey@golovko.me. Map the second address onto the first so the two do
not look like two different contributors.
Link: https://lore.kernel.org/20260912162630.7731-1-andrey.golovko@gmail.com
Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
The run-length path rejects a block when dbufCount+t equals dbufSize, but
the loop that follows writes exactly t bytes starting at dbufCount, so a
block that fills the buffer exactly is legal. bzip2 allows it too: its
decompressor bounds a block at 100000 * blockSize100k and checks that
limit per byte appended. Use > instead of >=.
bzip2's encoder stops filling a block 19 bytes early, so nothing it
produces ever reaches the limit and the bug stays hidden. Compressors
that use the full block size do reach it: an lbzip2 -9 image whose block
ends on a run fails to decode, and a self-extracting kernel built that way
does not boot.
This code came from busybox, which fixed the same line in 2013 in commit
932e233a491b ("bunzip2: fix off-by-one check").
I ran into this because my system uses lbzip2 as /bin/bzip2 -- a common
thing on Gentoo I believe. As far as I can tell, anyone using lbzip2
as their system bzip2 would run into this and it's only because it's
very uncommon these days to compress a kernel with bzip2 that no one
has noticed. I only noticed because I was adding support for various
compression formats on alpha.
Link: https://lore.kernel.org/20260912-b4-bunzip2-blocksize-fix-v1-1-c7384bbfc954@gmail.com
Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression")
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alain Knaff <alain@knaff.lu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <stable@vger.kernel.org>
|
|
These are the only two entries in the file that map a British spelling to
an American one:
initalised||initialized
initalise||initialize
doc-guide/checkpatch.rst asks that British and American spellings be left
alone, so correcting the missing "i" should not also change the variety of
English. Following checkpatch here silently rewrites "initalised" to
"initialized" in files that otherwise use British forms; arch/arm64 alone
has 58 uses of "initialised" against 132 of "initialized", so both are
clearly in use.
Map them to the British forms instead, so the misspelling is still caught
while the spelling variety is left to the author.
Link: https://lore.kernel.org/20260907091324.32211-1-hemanth.selam@gmail.com
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Suggested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Assisted-by: Cursor:claude-opus-5
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Jonathan Corbet <corbet@lwn.net>
|
|
In xbc_verify_tree(), the loop iterating through all nodes to check that
xbc_nodes[i].next < xbc_node_num and xbc_nodes[i].child < xbc_node_num is
a defensive sanity check against implementation regressions (such an
out-of-bounds index cannot be produced by malformed input).
Running this check in the kernel adds unnecessary boot-time overhead.
Split this check out into xbc_sanity_check_tree() for userspace, so that
it continues to run during userspace bootconfig validation (e.g. when
applying or testing bootconfig with tools/bootconfig), but is omitted in
the kernel to speed up initialization.
Link: https://lore.kernel.org/178913600409.248794.12941798680046327623.stgit@devnote2
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Closes: https://lore.kernel.org/all/20260905141637.1547429-1-ekffu200098@gmail.com/
Reviewed-by: Sang-Heon Jeon <ekffu200098@gmail.com>
|
|
Nigel Kirkland <nkirkland2304@gmail.com> says:
This patch set contains important bug fixes related to cleanup
handling in both normal and error paths, and refactoring of duplicate
code.
The patches were cut against Martin's 7.4/scsi-queue tree.
Link: https://patch.msgid.link/20261013001648.62289-1-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Update lpfc version to 15.0.0.1
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20261013001648.62289-9-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The domain controller FC_ID can change whenever a fabric switch with an
ISL link is replaced or the admin reconfigures the fabric switch with
active links. In such situations, reference count updates should be
applied to the correct nodelist structure.
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Link: https://patch.msgid.link/20261013001648.62289-8-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The lpfc_set_disctmo() routine is not used for all cases when the driver
needs to restart discovery on the fc_disctmo timer. Not doing so, makes
discovery timer actions invisible in some cases as they do not get
logged. This patch substitutes calls on fc_disctmo to use
lpfc_set_disctmo() in lpfc_els_rcv_rscn().
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20261013001648.62289-7-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The lpfc_els_abort() routine has a code path that cancels outstanding
I/Os on the ELS ring when attempted aborts fail. The failed aborts are
queued to a drv_cmpl_list and then cancelled after the ELS
pring->txcmplq is fully traversed. However if the abort failure returns
IOCB_ABORTING, then the driver should not have cancelled it. Doing so
starts two threads working on the same iocb and ndlp, leading to
unintended race conditions.
Fix by capturing the IOCB_ABORTING return value in lpfc_els_abort() and
not adding it to the list of IOCBs for cancelling. We should allow the
IOCB scheduled for abort to complete naturally. This avoids
simultaneous threads acting on the same IOCB and ndlp objects.
The lpfc_free_iocb_list() is moved to execute after
lpfc_sli4_hba_unset() allowing the routine to flush I/O before freeing
it. And, in lpfc_pci_remove_one_s4() a call to flush the phba->wq is
added. This makes the unload logic consistent with offline handling
logic.
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20261013001648.62289-6-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
The current initial kref count drop logic for an ndlp that fails FDISC
assumes that the ndlp has never registered with transport layer and thus
the lpfc_dev_loss_tmo_callbk never called. However, a failed FDISC can
occur after a successful transport layer registration too. So,
lpfc_dev_loss_tmo_callbk can occur and there is a potential
use-after-free on the ndlp.
Check ndlp->fc4_xpt_flags if previously registered with an upper layer
transport and check ndlp->nlp_flags if there is a LPFC_EVT_DEV_LOSS work
pending. If not previously registered nor LPFC_EVT_DEV_LOSS work pending,
then set the NLP_DROPPED flag as before and decrement the initial kref on
FDISC error. However, if ndlp has been previously registered, then let the
pre-existing logic for each transport's respective dev_loss_tmo_callbk
perform the initial kref decrement.
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Link: https://patch.msgid.link/20261013001648.62289-5-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
A kernel oops at dma_unmap_sg_attrs() may occur due to a race between an
aborted SCSI I/O completion and a SCSI error handler issued TUR using
the same repurposed scsi_cmnd structure.
The LPFC_DRIVER_ABORTED cmd_flag is set when inflight I/Os are aborted
via lpfc_sli_abort_taskmgmt(), and this flag is not cleared until after
scsi_done() is called. The inflight I/O test is changed to check SCSI
I/O for either LFPC_IO_ON_TXCMPLQ or LPFC_DRIVER_ABORTED. If either
cmd_flag is set, then the I/O should still be counted.
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20261013001648.62289-4-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
It is possible that a dev_loss_tmo callback fires during an HBA reset.
The ELS pring structure is cleared by the HBA reset path and the
dev_loss_tmo callback executing lpfc_els_abort() could be using a stale
ELS pring pointer. To significantly reduce exposure, check if HBA_SETUP
flag is set before proceeding to use the ELS pring pointer in
lpfc_els_abort(). There is no point to issue aborts when the SLI port is
not setup anyways.
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Reveiwed-by: Ewan D. Milne <emilne@redhat.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20261013001648.62289-3-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
In lpfc_cmpl_ct_cmd_vmid(), there is an early call to
lpfc_ct_free_iocb() when cmd is SLI_CTAS_DALLAPP_ID. Within
lpfc_ct_free_iocb() the cmdiocb->rsp_dmabuf will be freed. This means
any ctrsp ptr dereference for SLI_CT_RESPONSE_FS_RJT or even
ctrsp->ReasonCode and ctrsp->Explanation when handling a CT LS_RJT
response is a use-after-free.
Remove the early lpfc_ct_free_iocb call for SLI_CTAS_DALLAPP_ID. There
already is a free_res label that calls lpfc_ct_free_iocb so there
doesn't need to be an early lpfc_ct_free_iocb at the start of
lpfc_cmpl_ct_cmd_vmid.
Signed-off-by: Nigel Kirkland <nkirkland2304@gmail.com>
Tested-by: Ewan D. Milne <emilne@redhat.com>
Link: https://patch.msgid.link/20261013001648.62289-2-nkirkland2304@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Bart Van Assche <bvanassche@acm.org> says:
Hi Martin,
This patch series enables compiler-based lock context analysis for the
scsi_debug driver. Conditional locking is eliminated across command
response and error injection functions so that static analysis can verify
lock acquisitions and releases. Internal locking helper functions are
annotated with __acquires(),__releases(), __acquires_shared() and
__releases_shared() attributes. An error-path lock leak in
resp_write_same() is fixed. Finally, lock context analysis is enabled in
drivers/scsi/Makefile.
Please consider this patch series for the next merge window.
Thanks,
Bart.
Link: https://patch.msgid.link/cover.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Enable lock context analysis now that all lock context analysis warnings
have been fixed.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@linux.dev>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/46613e281866679cff455c3cbab842e48ad2a3d3.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Prepare the scsi_debug driver for enabling compiler-based lock context
analysis:
- Annotate the lock and unlock helper functions with __acquires,
__releases, __acquires_shared, and __releases_shared.
- Add __acquire() and __release() calls in the paths that do not match
the __acquires() / __releases() annotations.
- Annotate sdeb_meta_{read,write}_{,un}lock() with __context_unsafe()
because adding __acquire() and __release() calls in these functions
is not possible without triggering undefined behavior (taking the
address of a member of a structure with a NULL pointer as base
address).
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/1775809e31b535cc42f3f79e75f28666e74a98f7.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Prepare for enabling lock context analysis by eliminating conditional
locking.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/bd623851c07c80b3f1bff493e66dc268656e9883.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Prepare for enabling lock context analysis by eliminating conditional
locking.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/ef20891477dd7eac3874945660caec278893a619.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Split this function to remove conditional locking. This patch prepares
for enabling context analysis.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@linux.dev>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/eea4ce8d6ddc86a401570f09a559a3b3c50e78ff.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Move the inner logic of corrupt_lbas() into a new helper function
__corrupt_lbas() and call it from separate locked and unlocked branches
in corrupt_lbas(). This patch prepares for enabling context analysis.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@linux.dev>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/fe8629d9d7d0a54e8c5c14539953b40c09a6855a.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Since the Clang thread-safety analyzer does not support conditional
locking, split the function resp_write_same() such that all locking
statements end up in the same branch of an if-statement.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@linux.dev>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/1127ce1be450f0c4503845b41eaa24c27aba373a.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
If fetch_to_dev_buffer() fails in resp_write_same(), the function jumps
to 'out' without releasing the data write lock acquired earlier via
sdeb_data_write_lock(). Jump to 'unlock' instead so that
sdeb_data_write_unlock() is called on the error path. This bug has been
discovered by building the scsi_debug driver with Clang and modified
lock context annotations. The modified lock context annotations are
available in patch "scsi: scsi_debug: Improve lock context annotations".
Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: John Garry <john.garry@linux.dev>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/271ea11d3bc147d950a89419181f0c3f5a1ebf3b.1791924924.git.bvanassche@acm.org
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
__iscsi_complete_pdu() fetches the task for five response types from one
place and checks only that the index resolved:
case ISCSI_OP_LOGOUT_RSP:
case ISCSI_OP_LOGIN_RSP:
case ISCSI_OP_TEXT_RSP:
case ISCSI_OP_SCSI_TMFUNC_RSP:
case ISCSI_OP_NOOP_IN:
task = iscsi_itt_to_task(conn, hdr->itt);
if (!task)
return ISCSI_ERR_BAD_ITT;
iscsi_itt_to_task() bounds the index against cmds_max and looks at
nothing else, so a target can name any slot in the pool, including one
that has never been used. task->conn is then NULL, and both
iscsi_nop_out_rsp() and iscsi_complete_task() dereference it. One
unsolicited NOP-In is enough; a Text Response carrying the same ITT
crashes in iscsi_complete_task() instead.
Require the task to be in flight and not a SCSI command, the way
iscsi_itt_to_ctask() does for the command opcodes.
[ 6.298634] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI
[ 6.298642] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
[ 6.298652] CPU: 1 UID: 0 PID: 111 Comm: iscsistart Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy)
[ 6.298654] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 6.298656] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160
[ 6.298691] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00
[ 6.298698] RSP: 0018:ffff88806c907be8 EFLAGS: 00010206
[ 6.298701] RAX: dffffc0000000000 RBX: ffff888006116800 RCX: 0000000000000020
[ 6.298702] RDX: 000000000000000c RSI: ffff88800525d578 RDI: 0000000000000060
[ 6.298703] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 6.298706] R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000
[ 6.298706] R13: 000000000000002e R14: ffff8880056eb440 R15: ffff888006116800
[ 6.298707] FS: 00007fc02d1c2740(0000) GS:ffff8880b29bc000(0000) knlGS:0000000000000000
[ 6.298710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6.298711] CR2: 000055fe3b56ddf8 CR3: 00000000053b9004 CR4: 0000000000770ef0
[ 6.298712] PKRU: 55555554
[ 6.298713] Call Trace:
[ 6.298714] <IRQ>
[ 6.298714] __iscsi_complete_pdu+0x13a8/0x22a0
[ 6.298758] iscsi_complete_pdu+0x54/0xa0
[ 6.298759] iscsi_tcp_hdr_recv_done+0x870/0x2c80
[ 6.298778] iscsi_tcp_recv_skb+0x31e/0xec0
[ 6.298800] iscsi_sw_tcp_recv+0x12f/0x390
[ 6.298804] __tcp_read_sock+0x1ab/0x810
[ 6.298812] iscsi_sw_tcp_data_ready+0x18b/0x510
[ 6.298814] tcp_rcv_established+0x1f56/0x3a00
[ 6.298842] tcp_v4_do_rcv+0x449/0x960
[ 6.298847] tcp_v4_rcv+0x2245/0x3bc0
Fixes: 7996a778ff8c ("[SCSI] iscsi: add libiscsi")
Cc: stable@vger.kernel.org
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Link: https://patch.msgid.link/20261007015842.634893-4-yhlee@isslab.korea.ac.kr
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
A Reject PDU carries a copy of the header it rejects, and
iscsi_handle_reject() takes the ITT out of that copy to find the task to
clean up:
memcpy(&rejected_pdu, data, sizeof(struct iscsi_hdr));
...
task = iscsi_itt_to_task(conn, rejected_pdu.itt);
That value is whatever the target put there. iscsi_itt_to_task() bounds
the index against cmds_max and checks nothing else, so any task in the
pool can be named, and iscsi_nop_out_rsp() then completes it.
An index that has never been used gives a NULL task->conn: the pool is
zeroed at session setup and conn is assigned only when a task is
allocated. If the task was used and returned, iscsi_complete_task() hits
its WARN_ON_ONCE(task->state == ISCSI_TASK_FREE) and the refcount
underflows. An in-flight SCSI command is completed as successful - a 1
MiB read returned 1048576 with none of its buffer written and no
warning.
Validate the reflected ITT the way iscsi_itt_to_ctask() validates a
command ITT, and require the task to be in flight and not a SCSI
command.
[ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI
[ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
[ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy)
[ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 6.251616] RIP: 0010:iscsi_nop_out_rsp.constprop.0+0x46/0x160
[ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00
[ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206
[ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25
[ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060
[ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504
[ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000
[ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000
[ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000
[ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0
[ 6.255439] PKRU: 55555554
[ 6.255564] Call Trace:
[ 6.255674] <IRQ>
[ 6.255768] __iscsi_complete_pdu+0x18bf/0x22a0
[ 6.256733] iscsi_complete_pdu+0x54/0xa0
[ 6.256905] iscsi_tcp_data_recv_done+0xf4/0x250
[ 6.257103] iscsi_tcp_recv_skb+0x31e/0xec0
[ 6.257680] iscsi_sw_tcp_recv+0x12f/0x390
[ 6.258061] __tcp_read_sock+0x1ab/0x810
[ 6.258853] iscsi_sw_tcp_data_ready+0x18b/0x510
[ 6.259808] tcp_data_queue+0x1f13/0x4cd0
[ 6.260567] tcp_rcv_established+0x8a5/0x3a00
[ 6.261931] tcp_v4_do_rcv+0x449/0x960
[ 6.262269] tcp_v4_rcv+0x2245/0x3bc0
Fixes: 8afa1439fcff ("[SCSI] libiscsi: handle immediate command rejections")
Cc: stable@vger.kernel.org
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Link: https://patch.msgid.link/20261007015842.634893-3-yhlee@isslab.korea.ac.kr
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
A transport that implements parse_pdu_itt hands libiscsi an index taken
from the PDU, and both lookups bound it from above only:
if (i >= session->cmds_max)
i and cmds_max are both int, so a negative index passes and
session->cmds[i] is read from before the array.
be2iscsi produces one. beiscsi_parse_pdu() assigns the raw tag,
*index = (int)itt;
and beiscsi_complete_pdu() forwards an unsolicited NOP-In from the
hardware async ring without replacing its ITT, so the value is the
target's. It also reports the session's own age rather than the one in
the tag, which leaves the age comparison in iscsi_verify_itt() with
nothing to reject.
Bound the index from below in both lookups.
Fixes: bfead3b2cb46 ("[SCSI] be2iscsi: Adding msix and mcc_rings V3")
Cc: stable@vger.kernel.org
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Link: https://patch.msgid.link/20261007015842.634893-2-yhlee@isslab.korea.ac.kr
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Separate configfs opens can concurrently update the discovery AuthMethod
parameter. Both callers may free the same value in
iscsi_update_param_value(), causing a double-free.
Protect the lookup and replacement with the discovery TPG access lock,
as used by the other TPG configfs parameter updates.
Fixes: e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")
Signed-off-by: Linfeng Sun <linfeng.sun.dev@gmail.com>
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Link: https://patch.msgid.link/20260811124843.6817-1-linfeng.sun.dev@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
target_do_delayed_work() takes dev->delayed_cmd_lock with a plain
spin_lock(). It runs from system_percpu_wq, so interrupts stay enabled
while the lock is held. Every other acquisition of that lock uses
spin_lock_irqsave(): target_handle_task_attr() and
transport_complete_ordered_sync() in target_core_transport.c, and
target_non_ordered_release() in target_core_device.c.
That was safe while every caller of transport_complete_task_attr() ran
in process context: target_complete_ok_work() from target_completion_wq,
transport_complete_qf() from dev->qf_work_queue, and
transport_generic_request_failure() from the submit and execute paths.
Since commit 06933066d88a ("scsi: target: Add support for completing
commands from backend context") that is no longer true. With
complete_type=1 on a fabric that sets direct_compl_supp,
target_complete() runs target_complete_ok_work() inline in the backend's
completion context, which target_complete_cmd_with_sense() documents as
"May be called from interrupt context". For iblock that is the bio
end_io.
target_complete_ok_work() starts with transport_complete_task_attr(),
which takes delayed_cmd_lock in two ways:
- Every ORDERED command is put on dev->delayed_cmd_list by
target_handle_task_attr() and dispatched from there by
target_do_delayed_work(), which marks it SCF_TASK_ORDERED_SYNC. Its
completion therefore goes through transport_complete_ordered_sync().
- A SIMPLE command that completes while an ORDERED command is pending
drops the last reference to the killed dev->non_ordered, and
percpu_ref_put() then runs target_non_ordered_release() in the
completing context.
Both take the lock and, if commands are waiting, call
schedule_work(&dev->delayed_cmd_work), which queues on system_percpu_wq,
i.e. on the CPU that took the completion. Further completions for the
same queue are typically delivered there too, so one arriving while the
work holds the lock spins on it forever.
Reaching this needs complete_type=1, which is not the default
(vhost-scsi, the only fabric with direct_compl_supp, defaults to
TARGET_QUEUE_COMPL), a backend whose I/O completes from interrupt
context, and ORDERED commands from the initiator. Linux virtio_scsi
guests send only VIRTIO_SCSI_S_SIMPLE and never take the ordered path;
any guest that uses the ORDERED task attribute, which vhost-scsi
accepts, does.
target_do_delayed_work() is a work item and always runs in process
context, so spin_lock_irq() is sufficient.
Found by inspection; no runtime report. A single ORDERED command goes
through both acquisitions, so with CONFIG_PROVE_LOCKING the first one
completed through direct completion should produce an inconsistent lock
state report on delayed_cmd_lock (hardirq or softirq, depending on where
the backend completes).
Fixes: 06933066d88a ("scsi: target: Add support for completing commands from backend context")
Signed-off-by: Yu Zhang <yuz08559@gmail.com>
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Link: https://patch.msgid.link/20260927091329.13482-1-yuz08559@gmail.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
QEMU emulates a UFS host controller and logical units, but the kernel
tree does not mention it, so developers without UFS hardware have no
documented way to exercise the UFS core.
Add a short section with the required kernel options, an example QEMU
command line, and what the emulation does not cover.
Signed-off-by: Stanley Jhu <stanleyjhu@google.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Link: https://patch.msgid.link/20261012120059.1371653-1-stanleyjhu@google.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
st_remove() drops the probe reference on the scsi_tape with kref_put()
and only afterwards removes its index from st_index_idr. If that was the
last reference, scsi_tape_release() frees the structure while it is
still published in the idr.
scsi_tape_get(), called from st_open(), looks up the tape in
st_index_idr and takes a reference under st_ref_mutex and
st_index_lock. remove_cdevs() does not wait for opens that are already
past chrdev_open(), so an open that is blocked on st_ref_mutex while
st_remove() holds it can take the mutex as soon as st_remove() drops it,
find the freed tpnt in the idr and call kref_get() on it:
BUG: KASAN: slab-use-after-free in st_open
Write of size 4 ...
st_open (drivers/scsi/st.c:254 drivers/scsi/st.c:1291)
chrdev_open
...
Freed by task ...:
kfree
st_remove (drivers/scsi/st.c:4512)
Remove the index from the idr before dropping the reference, all under
st_ref_mutex. A concurrent scsi_tape_get() now either runs first and
holds a valid reference that keeps the tape alive, or runs afterwards
and finds nothing, so st_open() fails with -ENXIO.
This restores the ordering st_remove() had before the conversion to
st_index_idr, where the tape was unpublished from scsi_tapes[] before
the final kref_put().
Fixes: 6c648d95a6af ("[SCSI] st: get rid of scsi_tapes array")
Cc: stable@vger.kernel.org
Reported-by: Dingisoul <dingiso.kernel@gmail.com>
Closes: https://lore.kernel.org/linux-scsi/20261007211520.1428497-1-dingiso.kernel@gmail.com/
Tested-by: Dingisoul <dingiso.kernel@gmail.com>
Signed-off-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20261013202548.249628-1-loberman@redhat.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
While the C11 allows us to define variables in the code, we do not do
this style (see more at [1]). Move the declaration to the top of the
function.
Link: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/ [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20261013095924.959455-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
set_location() saves the current tape location before switching
partitions, so that switch_partition() can return to it later. It reads
the location with READ POSITION but stores it in the st_partstat of
STp->partition, ignoring the partition the drive reports.
The two differ after a device reset. When the reset is recovered with
MTREW, MTSEEK or MTEOM, st_ioctl() sets STp->partition = 0 and calls
switch_partition() to return to STp->new_partition. A drive that was in
partition 1 is still there, so set_location() files the partition 1
position under partition 0. The next switch to partition 0 locates to
that block: if partition 0 holds less data, MTSETPART fails with EIO
(BLANK CHECK), otherwise the tape is silently positioned at the wrong
block.
IBM ULTRIUM-TD5 (LTO-5), LU reset in partition 1 at block 1025:
st 12:0:0:0: [st0] Visited block 1025 for partition 0 saved.
...
st 12:0:0:0: [st0] Setting block to 1025 and partition to 0.
st 12:0:0:0: [st0] Error: 402, cmd: 2b 2 0 0 0 4
st 12:0:0:0: [st0] Sense Key : Blank Check [current]
st 12:0:0:0: [st0] Add. Sense: End-of-data detected
Store the location in the st_partstat of the partition reported by READ
POSITION. With the fix:
st 12:0:0:0: [st0] Visited block 1025 for partition 1 saved.
This is a pre-existing issue. It was not caught when testing the recent
st reset series because the partition test was only run on scsi_debug:
on the LTO drive it was skipped, since can-partitions is off in the test
harness's stinit.conf, as is normal for LTO. scsi_debug hides the
problem because its emulated tape returns to the beginning of partition
0 on an LU reset. It was found while validating a backport of that
series to RHEL 9.8, when the partition tests were run on real hardware
with can-partitions enabled. The same failure then reproduced on
unmodified RHEL 9.8 and on upstream, and the fix makes the test pass on
v7.3-rc3 and RHEL 9.8 with an LTO-5.
The harness (https://gitlab.com/loberman/tapetest, test X03) now refuses
to silently skip the partition tests on hardware.
Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset")
Assisted-by: Claude
Signed-off-by: Laurence Oberman <loberman@redhat.com>
Link: https://patch.msgid.link/20261006164250.773840-1-loberman@redhat.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
Bean Huo and Stanley Jhu have been contributing to and reviewing changes
in the UFS subsystem for a number of years, and would like to help share
the review load going forward.
Add both as reviewers (R:) for the UFS subsystem.
Signed-off-by: Bean Huo <beanhuo@micron.com>
Acked-by: Stanley Jhu <stanleyjhu@google.com>
Link: https://patch.msgid.link/20261006082907.3405554-1-beanhuo@iokpp.de
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
scsifront_do_response() validates the rqid in a backend response against
VSCSIIF_MAX_REQS before using it to index info->shadow[], but then
dereferences the entry to test ->inflight without checking that the slot
is populated. Shadow slots are NULL before a command is submitted (the
host private area is zeroed at allocation) and are reset to NULL in
_scsifront_put_rqid() once a request completes, so an in-range rqid that
does not correspond to an outstanding request makes the frontend
dereference a NULL pointer.
A malicious or buggy backend can thus crash the guest by returning a
response whose rqid is in range but not in flight -- for example a
spurious response before any command has been issued, or a duplicate of
one already completed. The ring has only VSCSIIF_MAX_REQS (16) slots,
so before the first command every in-range rqid selects a NULL slot.
Reject a response whose shadow slot is not populated.
Fixes: 6d1c2f48f3fc ("xen/scsifront: harden driver against malicious backend")
Cc: stable@vger.kernel.org
Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://patch.msgid.link/20261005123555.253995-1-yhlee@isslab.korea.ac.kr
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux
Pull NIOS2 fix from Dinh Nguyen:
- Fix __wsum type degradation in csum_fold()
* tag 'nios2_update_for_v7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
nios2: fix __wsum type degradation in csum_fold()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull power supply fixes from Sebastian Reichel:
"power-supply core:
- prevent unregistering a power supply while a callback runs
power-supply drivers:
- generic-adc-battery: Fix temperature IIO channel conversion
- ds2780: Fix ds2780_get_capacity() returning raw value
- max17042_battery: Fix vmin assigned instead of vmax in DT parsing
- Fix maintenance charge table kernel-doc"
* tag 'for-v7.3-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply:
power: supply: core: prevent unregistering a power supply while a callback runs
power: supply: generic-adc-battery: Fix temperature IIO channel conversion
power: supply: ds2780: Fix ds2780_get_capacity() returning raw value
power: supply: Fix maintenance charge table kernel-doc
power: supply: max17042_battery: Fix vmin assigned instead of vmax in DT parsing
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull bootconfig fix from Masami Hiramatsu:
- bootconfig: give the footer size static_assert a message
Add a message to static_assert() macro because it is required for
the compiler before C23. This fixes a warning.
* tag 'bootconfig-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
bootconfig: give the footer size static_assert a message
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
Pull turbostat fixes from Len Brown.
* tag 'turbostat-2026.09.28' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
turbostat 2026.09.28
tools/power turbostat: Fix add_counter issue if > 24 counters.
tools/power turbostat: Fix PMT error path fd handling
tools/power turbostat: Fix CWF PMT off-by-one
tools/power turbostat: Fix fd_perf leak on reset
tools/power turbostat: Sanity check GFX%rc6 and SAM%mc6 percentages
tools/power turbostat: add NULL check after calloc()
tools/power turbostat: Warn, but don't Err on out-dated perf systems
tools/power turbostat: Read complete CPU lists
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
intel-pinctrl for v7.4-1
* Enable pure platform device enumeration for the Intel pin control
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Pull kvm fixes from Paolo Bonzini:
"More x86 fixes:
- Fix a WARN if the SS bit is set in #NPF exit codes.
The AMD manual is unclear about whether it can be set when the
guest uses CET but the SupervisorShadowStackEn feature (which KVM
does not use) is disabled. However, Hyper-V has started using CET
now that KVM supports GMET (it wants the two feature in pairs), and
that dissolves all the doubts: the SS bit *is* reported and not
clearing it causes a WARN and/or a UBSAN splat.
- If creating a vCPU ultimately fails, clear its entry in the AVIC
Physical ID table used by hardware to perform IPI Virtualization
and delivered posted IRQs.
I.e. plug the same use-after-free hole related to IPI
virtualization and posted IRQs that was fixed for APICv by commit
b41f2ca6c0601 ("KVM: VMX: Fix stale PID-pointer table entry left
after vCPU free").
- Use set_page_dirty_lock() instead of set_page_dirty() when marking
a page dirty after writing back SNP firmware's desired CPUID state
to userspace.
Using set_page_dirty() is unsafe if the page/folio isn't locked (as
pointed out by its function comment's big DANGER warning, which no
one reads given the number of bugs of this exact nature).
- When checking for an MMIO generation match, use the memslots for
the current vCPU context (non-SMM vs. SMM), as a misbehaving guest
can coerce KVM into incorrectly identifying a write as MMIO in
order to bypass KVM's write-tracking"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
KVM: x86: Use active memslots for the per-vCPU MMIO cache
KVM: SEV: Fix page dirtying in sev_gmem_post_populate()
KVM: SVM: Clear AVIC Physical ID table entry if vCPU creation fails
KVM: SVM: Use "is AVIC-addressable" helper to sanity check load()/put()
KVM: SVM: Add paranoid helper for checking if vCPU is AVIC-addressable
|
|
csum_fold() shifts a bitwise __wsum type, which sparse reports as
"restricted __wsum degrades to integer". Sparse only checks the body of
a static inline once something instantiates it, so this went unnoticed
until a recent block layer change added the first csum_fold() caller to
a file built on this architecture.
Force cast to a __u32 for the shift, as the other architectures do.
Fixes: eea9507a69d6 ("nios2: Library functions")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609222053.5gjiJjtb-lkp@intel.com/
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
stm32_gpiolib_register_bank() walks the "gpio-ranges" property with
fwnode_property_get_reference_args(). As documented in
drivers/base/property.c:
* The caller is responsible for calling fwnode_handle_put() on the
* returned @args->fwnode pointer.
The returned reference is never put. The function calls the helper
twice, once directly and then repeatedly in a while loop, and each
call overwrites args, so only the last reference is even reachable
and all the earlier ones are leaked for good.
Put the reference as soon as args.args[] has been consumed, both for
the initial call and for every iteration of the loop.
Found by code review.
Cc: stable@vger.kernel.org
Fixes: bb949ed9b16b ("pinctrl: stm32: Switch to use for_each_gpiochip_node() helper")
Signed-off-by: Ma Ke <make_ruc2021@163.com>
Reviewed-by: Antonio Borneo <antonio.borneo@foss.st.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
virtgpu_freeze() waits for the control and cursor queues to drain and
then deletes the virtqueues, but nothing tells the device to stop first.
del_vqs() frees the vring backing, but does not provide a generic device
quiesce operation. In particular, modern virtio-pci keeps enabled queues
active until the device is reset, so the device is left DRIVER_OK with
its queues pointing at memory that has been freed and may be reused while
the guest is suspended. virtio_device_restore() only resets the device
later, on resume.
Reset the device before deleting the virtqueues, the way
virtio_gpu_deinit() already does on removal.
Fixes: cad6a879a7fb ("drm/virtio: Freeze and restore hooks to support suspend and resume")
Cc: stable@vger.kernel.org
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/20260926202040.1313385-1-oss.patchbox@gmail.com
|
