| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup
Disable the delayed work before clearing BAR mappings and doorbells to
avoid running the handler after resources have been torn down.
Unable to handle kernel paging request at virtual address ffff800083f46004
[...]
Internal error: Oops: 0000000096000007 [#1] SMP
[...]
Call trace:
epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P)
process_one_work+0x154/0x3b0
worker_thread+0x2c8/0x400
kthread+0x148/0x210
ret_from_fork+0x10/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown
epf_ntb_epc_destroy() duplicates the teardown that the caller is
supposed to perform later. This leads to an oops when .allow_link fails
or when .drop_link is performed. The following is an example oops of the
former case:
Unable to handle kernel paging request at virtual address dead000000000108
[...]
[dead000000000108] address between user and kernel address ranges
Internal error: Oops: 0000000096000044 [#1] SMP
[...]
Call trace:
pci_epc_remove_epf+0x78/0xe0 (P)
pci_primary_epc_epf_link+0x88/0xa8
configfs_symlink+0x1f4/0x5a0
vfs_symlink+0x134/0x1d8
do_symlinkat+0x88/0x138
__arm64_sys_symlinkat+0x74/0xe0
[...]
Remove the helper, and drop pci_epc_put(). EPC device refcounting is
tied to the configfs EPC group lifetime, and pci_epc_put() in the
.drop_link path is sufficient. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Drop WARN on large size for KVM_MEMORY_ENCRYPT_REG_REGION
Drop the WARN in sev_pin_memory() on npages overflowing an int, as the
WARN is comically trivially to trigger from userspace, e.g. by doing:
struct kvm_enc_region range = {
.addr = 0,
.size = -1ul,
};
__vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
Note, the checks in sev_mem_enc_register_region() that presumably exist to
verify the incoming address+size are completely worthless, as both "addr"
and "size" are u64s and SEV is 64-bit only, i.e. they _can't_ be greater
than ULONG_MAX. That wart will be cleaned up in the near future.
if (range->addr > ULONG_MAX || range->size > ULONG_MAX)
return -EINVAL;
Opportunistically add a comment to explain why the code calculates the
number of pages the "hard" way, e.g. instead of just shifting @ulen. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: do not expire session on binding failure
When a multichannel session binding request fails (e.g. wrong password),
the error path unconditionally sets sess->state = SMB2_SESSION_EXPIRED.
However, during binding, sess points to the target session looked up via
ksmbd_session_lookup_slowpath() -- which belongs to another connection's
user. This allows a remote attacker to invalidate any active session by
simply sending a binding request with a wrong password (DoS).
Fix this by skipping session expiration when the failed request was
a binding attempt, since the session does not belong to the current
connection. The reference taken by ksmbd_session_lookup_slowpath() is
still correctly released via ksmbd_user_session_put(). |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: unset conn->binding on failed binding request
When a multichannel SMB2_SESSION_SETUP request with
SMB2_SESSION_REQ_FLAG_BINDING fails ksmbd sets conn->binding = true
but never clears it on the error path. This leaves the connection in
a binding state where all subsequent ksmbd_session_lookup_all() calls
fall back to the global sessions table. This fix it by clearing
conn->binding = false in the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: cadence-quadspi: Implement refcount to handle unbind during busy
driver support indirect read and indirect write operation with
assumption no force device removal(unbind) operation. However
force device removal(removal) is still available to root superuser.
Unbinding driver during operation causes kernel crash. This changes
ensure driver able to handle such operation for indirect read and
indirect write by implementing refcount to track attached devices
to the controller and gracefully wait and until attached devices
remove operation completed before proceed with removal operation. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode
w/ "mode=lfs" mount option, generic/299 will cause system panic as below:
------------[ cut here ]------------
kernel BUG at fs/f2fs/segment.c:2835!
Call Trace:
<TASK>
f2fs_allocate_data_block+0x6f4/0xc50
f2fs_map_blocks+0x970/0x1550
f2fs_iomap_begin+0xb2/0x1e0
iomap_iter+0x1d6/0x430
__iomap_dio_rw+0x208/0x9a0
f2fs_file_write_iter+0x6b3/0xfa0
aio_write+0x15d/0x2e0
io_submit_one+0x55e/0xab0
__x64_sys_io_submit+0xa5/0x230
do_syscall_64+0x84/0x2f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0010:new_curseg+0x70f/0x720
The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may
trigger foreground gc only if it allocates any physical block, it will be
a little bit later when there is multiple threads writing data w/
aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so
f2fs_map_blocks() does block allocations aggressively.
In order to fix this issue, let's give a chance to trigger foreground
gc in prior to block allocation in f2fs_map_blocks(). |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: spi-nor: sst: Fix SST write failure
'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation
to `sst_nor_write_data()`")' introduced a bug where only one byte of data
is written, regardless of the number of bytes passed to
sst_nor_write_data(), causing a kernel crash during the write operation.
Ensure the correct number of bytes are written as passed to
sst_nor_write_data().
Call trace:
[ 57.400180] ------------[ cut here ]------------
[ 57.404842] While writing 2 byte written 1 bytes
[ 57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74
[ 57.418464] Modules linked in:
[ 57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30
[ 57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT)
[ 57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 57.444557] pc : sst_nor_write_data+0x6c/0x74
[ 57.448911] lr : sst_nor_write_data+0x6c/0x74
[ 57.453264] sp : ffff80008232bb40
[ 57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001
[ 57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000
[ 57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000
[ 57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006
[ 57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580
[ 57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4
[ 57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530
[ 57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001
[ 57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000
[ 57.527916] Call trace:
[ 57.530354] sst_nor_write_data+0x6c/0x74
[ 57.534361] sst_nor_write+0xb4/0x18c
[ 57.538019] mtd_write_oob_std+0x7c/0x88
[ 57.541941] mtd_write_oob+0x70/0xbc
[ 57.545511] mtd_write+0x68/0xa8
[ 57.548733] mtdchar_write+0x10c/0x290
[ 57.552477] vfs_write+0xb4/0x3a8
[ 57.555791] ksys_write+0x74/0x10c
[ 57.559189] __arm64_sys_write+0x1c/0x28
[ 57.563109] invoke_syscall+0x54/0x11c
[ 57.566856] el0_svc_common.constprop.0+0xc0/0xe0
[ 57.571557] do_el0_svc+0x1c/0x28
[ 57.574868] el0_svc+0x30/0xcc
[ 57.577921] el0t_64_sync_handler+0x120/0x12c
[ 57.582276] el0t_64_sync+0x190/0x194
[ 57.585933] ---[ end trace 0000000000000000 ]---
[pratyush@kernel.org: add Cc stable tag] |
| In the Linux kernel, the following vulnerability has been resolved:
net: gro: fix outer network offset
The udp GRO complete stage assumes that all the packets inserted the RX
have the `encapsulation` flag zeroed. Such assumption is not true, as a
few H/W NICs can set such flag when H/W offloading the checksum for
an UDP encapsulated traffic, the tun driver can inject GSO packets with
UDP encapsulation and the problematic layout can also be created via
a veth based setup.
Due to the above, in the problematic scenarios, udp4_gro_complete() uses
the wrong network offset (inner instead of outer) to compute the outer
UDP header pseudo checksum, leading to csum validation errors later on
in packet processing.
Address the issue always clearing the encapsulation flag at GRO completion
time. Such flag will be set again as needed for encapsulated packets by
udp_gro_complete(). |
| The vulnerability in the Tassos Framework Plugin allows users to delete arbitrary files on the affected sites. |
| Discourse is an open-source discussion platform. In versions prior to 2026.1.4, 2026.3.1, 2026.4.1 and 2026.5.0-latest.1, outdated cached AI summaries can leak removed content to anonymous and unprivileged users who cannot regenerate summaries. This issue has been fixed in versions 2026.1.4, 2026.3.1, 2026.4.1 and 2026.5.0-latest.1. To work around this issue, restrict summary generation by tightening the allowed groups on the summarization Personas. |
| Improper Access Control in the SICK ICR890-4 could allow an unauthenticated remote attacker to gather information about the system and download data via the REST API by accessing
unauthenticated endpoints. |
| Improper Access Control in the SICK ICR890-4 could allow an unauthenticated remote attacker to affect the availability of the device by changing settings of the device such as the IP
address based on missing access control. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Limit NVMe request size to 2 MiB
The HBA firmware reports NVMe MDTS values based on the underlying drive
capability. However, because the driver allocates a fixed 4K buffer for
the PRP list, accommodating at most 512 entries, the driver supports a
maximum I/O transfer size of 2 MiB.
Limit max_hw_sectors to the smaller of the reported MDTS and the 2 MiB
driver limit to prevent issuing oversized I/O that may lead to a kernel
oops. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: afs: revert mmap_prepare() change
Partially reverts commit 9d5403b1036c ("fs: convert most other
generic_file_*mmap() users to .mmap_prepare()").
This is because the .mmap invocation establishes a refcount, but
.mmap_prepare is called at a point where a merge or an allocation failure
might happen after the call, which would leak the refcount increment.
Functionality is being added to permit the use of .mmap_prepare in this
case, but in the interim, we need to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix rxkad crypto unalignment handling
Fix handling of a packet with a misaligned crypto length. Also handle
non-ENOMEM errors from decryption by aborting. Further, remove the
WARN_ON_ONCE() so that it can't be remotely triggered (a trace line can
still be emitted). |
| In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Hold mm structure across iommu_sva_unbind_device()
Some tests trigger a crash in iommu_sva_unbind_device() due to
accessing iommu_mm after the associated mm structure has been
freed.
Fix this by taking an explicit reference to the mm structure
after successfully binding the device, and releasing it only
after the device is unbound. This ensures the mm remains valid
for the entire SVA bind/unbind lifetime. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: Drop __initconst from gates
Since commit 8ceff24a754a ("clk: mediatek: clk-gate: Refactor
mtk_clk_register_gate to use mtk_gate struct") the mtk_gate structs
are no longer just used for initialization/registration, but also at
runtime. So drop __initconst annotations. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: drop extent cache after doing PARTIAL_VALID1 zeroout
When splitting an unwritten extent in the middle and converting it to
initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and
EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.
Assume we have an unwritten file and buffered write in the middle of it
without dioread_nolock enabled, it will allocate blocks as written
extent.
0 A B N
[UUUUUUUUUUUU] on-disk extent U: unwritten extent
[UUUUUUUUUUUU] extent status tree
[--DDDDDDDD--] D: valid data
|<- ->| ----> this range needs to be initialized
ext4_split_extent() first try to split this extent at B with
EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but
ext4_split_extent_at() failed to split this extent due to temporary lack
of space. It zeroout B to N and leave the entire extent as unwritten.
0 A B N
[UUUUUUUUUUUU] on-disk extent
[UUUUUUUUUUUU] extent status tree
[--DDDDDDDDZZ] Z: zeroed data
ext4_split_extent() then try to split this extent at A with
EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and
leave an written extent from A to N.
0 A B N
[UUWWWWWWWWWW] on-disk extent W: written extent
[UUUUUUUUUUUU] extent status tree
[--DDDDDDDDZZ]
Finally ext4_map_create_blocks() only insert extent A to B to the extent
status tree, and leave an stale unwritten extent in the status tree.
0 A B N
[UUWWWWWWWWWW] on-disk extent W: written extent
[UUWWWWWWWWUU] extent status tree
[--DDDDDDDDZZ]
Fix this issue by always cached extent status entry after zeroing out
the second part. |
| Vulnerability in the Oracle Financials Common Modules product of Oracle E-Business Suite (component: Common Components). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financials Common Modules. While the vulnerability is in Oracle Financials Common Modules, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Financials Common Modules accessible data as well as unauthorized update, insert or delete access to some of Oracle Financials Common Modules accessible data. CVSS 3.1 Base Score 8.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N). |
