🚨 CVE-2026-64047
In the Linux kernel, the following vulnerability has been resolved:
net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring
When an sk_msg scatterlist ring wraps (sg.end < sg.start),
tls_push_record() chains the tail portion of the ring to the head
using sg_chain(). An extra entry in the sg array is reserved for
this:
struct sk_msg_sg {
[...]
/* The extra two elements:
* 1) used for chaining the front and sections when the list becomes
* partitioned (e.g. end < start). The crypto APIs require the
* chaining;
* 2) to chain tailer SG entries after the message.
*/
struct scatterlist data[MAX_MSG_FRAGS + 2];
The current code uses MAX_SKB_FRAGS + 1 as the ring size:
sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
MAX_SKB_FRAGS - msg_pl->sg.start + 1,
msg_pl->sg.data);
This places the chain pointer at
sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =
&data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =
data[start + (MAX_SKB_FRAGS - start + 1) - 1] =
data[MAX_SKB_FRAGS]
instead of the true last entry. This is likely due to a "race" of
the commit under Fixes landing close to
commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")
Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested
by Sabrina).
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring
When an sk_msg scatterlist ring wraps (sg.end < sg.start),
tls_push_record() chains the tail portion of the ring to the head
using sg_chain(). An extra entry in the sg array is reserved for
this:
struct sk_msg_sg {
[...]
/* The extra two elements:
* 1) used for chaining the front and sections when the list becomes
* partitioned (e.g. end < start). The crypto APIs require the
* chaining;
* 2) to chain tailer SG entries after the message.
*/
struct scatterlist data[MAX_MSG_FRAGS + 2];
The current code uses MAX_SKB_FRAGS + 1 as the ring size:
sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
MAX_SKB_FRAGS - msg_pl->sg.start + 1,
msg_pl->sg.data);
This places the chain pointer at
sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =
&data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =
data[start + (MAX_SKB_FRAGS - start + 1) - 1] =
data[MAX_SKB_FRAGS]
instead of the true last entry. This is likely due to a "race" of
the commit under Fixes landing close to
commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")
Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested
by Sabrina).
🎖@cveNotify
🚨 CVE-2026-64048
In the Linux kernel, the following vulnerability has been resolved:
net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot
On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is
reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt()
populates V2 entries starting at index 1, so when no V1 device is
selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] ==
NULL and ism_chid[0] == 0.
smc_v2_determine_accepted_chid() then matches the peer's CHID against
the array starting from index 0 using the CHID alone. A malicious
peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches
the empty slot, ini->ism_selected becomes 0, and the subsequent
ism_dev[0]->lgr_lock dereference in smc_conn_create() faults at
offsetof(struct smcd_dev, lgr_lock) == 0x68:
BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh+0x79/0xe0
Write of size 4 at addr 0000000000000068 by task exploit/144
Call Trace:
_raw_spin_lock_bh
smc_conn_create (net/smc/smc_core.c:1997)
__smc_connect (net/smc/af_smc.c:1447)
smc_connect (net/smc/af_smc.c:1720)
__sys_connect
__x64_sys_connect
do_syscall_64
Require ism_dev[i] to be non-NULL before accepting a CHID match.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot
On the SMC-D client, slot 0 of ini->ism_dev[]/ini->ism_chid[] is
reserved for an SMC-Dv1 device. smc_find_ism_v2_device_clnt()
populates V2 entries starting at index 1, so when no V1 device is
selected slot 0 is left in its kzalloc()'ed state with ism_dev[0] ==
NULL and ism_chid[0] == 0.
smc_v2_determine_accepted_chid() then matches the peer's CHID against
the array starting from index 0 using the CHID alone. A malicious
peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches
the empty slot, ini->ism_selected becomes 0, and the subsequent
ism_dev[0]->lgr_lock dereference in smc_conn_create() faults at
offsetof(struct smcd_dev, lgr_lock) == 0x68:
BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh+0x79/0xe0
Write of size 4 at addr 0000000000000068 by task exploit/144
Call Trace:
_raw_spin_lock_bh
smc_conn_create (net/smc/smc_core.c:1997)
__smc_connect (net/smc/af_smc.c:1447)
smc_connect (net/smc/af_smc.c:1720)
__sys_connect
__x64_sys_connect
do_syscall_64
Require ism_dev[i] to be non-NULL before accepting a CHID match.
🎖@cveNotify
🚨 CVE-2026-64049
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx
Before a5xx Adreno driver will not try fetching UBWC params (because
those generations didn't support UBWC anyway), however it's still
possible to query UBWC-related params from the userspace, triggering
possible NULL pointer dereference. Check for UBWC config in
adreno_get_param() and return sane defaults if there is none.
Patchwork: https://patchwork.freedesktop.org/patch/717778/
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/adreno: fix userspace-triggered crash on a2xx-a4xx
Before a5xx Adreno driver will not try fetching UBWC params (because
those generations didn't support UBWC anyway), however it's still
possible to query UBWC-related params from the userspace, triggering
possible NULL pointer dereference. Check for UBWC config in
adreno_get_param() and return sane defaults if there is none.
Patchwork: https://patchwork.freedesktop.org/patch/717778/
🎖@cveNotify
🚨 CVE-2026-64050
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: don't mix devm and drmm functions
Mixing devm and drmm functions will result in a use-after-free on msm
driver teardown if userspace keeps a reference on the drm device:
The WB connector data will be destroyed because of the use of
devm_kzalloc()), while the usersoace still can try interacting with the
WB connector (which uses drmm_ functions).
Change dpu_writeback_init() to use drmm_.
Patchwork: https://patchwork.freedesktop.org/patch/722656/
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: don't mix devm and drmm functions
Mixing devm and drmm functions will result in a use-after-free on msm
driver teardown if userspace keeps a reference on the drm device:
The WB connector data will be destroyed because of the use of
devm_kzalloc()), while the usersoace still can try interacting with the
WB connector (which uses drmm_ functions).
Change dpu_writeback_init() to use drmm_.
Patchwork: https://patchwork.freedesktop.org/patch/722656/
🎖@cveNotify
🚨 CVE-2026-64051
In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Add overflow check to remap_pfn_range during mmap
The call to remap_pfn_range in qaic_gem_object_mmap is susceptible to
(re)mapping beyond the VMA if the BO is too large. This can cause use
after free issues when munmap() unmaps only the VMA region and not the
additional mappings. To prevent this, check the remaining size of the
VMA before remapping and truncate the remapped length if sg->length is
too large.
[jhugo: fix braces from checkpatch --strict]
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
accel/qaic: Add overflow check to remap_pfn_range during mmap
The call to remap_pfn_range in qaic_gem_object_mmap is susceptible to
(re)mapping beyond the VMA if the BO is too large. This can cause use
after free issues when munmap() unmaps only the VMA region and not the
additional mappings. To prevent this, check the remaining size of the
VMA before remapping and truncate the remapped length if sg->length is
too large.
[jhugo: fix braces from checkpatch --strict]
🎖@cveNotify
🚨 CVE-2026-64052
In the Linux kernel, the following vulnerability has been resolved:
block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()
pin_user_pages_fast() can partially succeed and return the number of
pages that were actually pinned. However, the bio_integrity_map_user()
does not handle this partial pinning. This leads to a general protection
fault since bvec_from_pages() dereferences an unpinned page address,
which is 0.
To fix this, add a check to verify that all requested memory is pinned.
If partial pinning occurs, unpin the memory and return -EFAULT.
Kernel Oops:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
RIP: 0010:bio_integrity_map_user.cold+0x1b0/0x9d6
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
block: bio-integrity: Fix null-ptr-deref in bio_integrity_map_user()
pin_user_pages_fast() can partially succeed and return the number of
pages that were actually pinned. However, the bio_integrity_map_user()
does not handle this partial pinning. This leads to a general protection
fault since bvec_from_pages() dereferences an unpinned page address,
which is 0.
To fix this, add a check to verify that all requested memory is pinned.
If partial pinning occurs, unpin the memory and return -EFAULT.
Kernel Oops:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
RIP: 0010:bio_integrity_map_user.cold+0x1b0/0x9d6
🎖@cveNotify
🚨 CVE-2026-64053
In the Linux kernel, the following vulnerability has been resolved:
block: don't overwrite bip_vcnt in bio_integrity_copy_user()
bio_integrity_add_page() already sets bip_vcnt to 1 for the bounce
segment. Overwriting it with nr_vecs breaks bip_vcnt <= bip_max_vcnt
on WRITE (bip_max_vcnt is 1), so the gap-merge checks in block/blk.h
read past the bip_vec[] flex array. On READ the read is in bounds
but lands on a saved user bvec instead of the bounce.
The line was added for split propagation, but bio_integrity_clone()
doesn't copy bip_vcnt and BIP_CLONE_FLAGS excludes BIP_COPY_USER.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
block: don't overwrite bip_vcnt in bio_integrity_copy_user()
bio_integrity_add_page() already sets bip_vcnt to 1 for the bounce
segment. Overwriting it with nr_vecs breaks bip_vcnt <= bip_max_vcnt
on WRITE (bip_max_vcnt is 1), so the gap-merge checks in block/blk.h
read past the bip_vec[] flex array. On READ the read is in bounds
but lands on a saved user bvec instead of the bounce.
The line was added for split propagation, but bio_integrity_clone()
doesn't copy bip_vcnt and BIP_CLONE_FLAGS excludes BIP_COPY_USER.
🎖@cveNotify
🚨 CVE-2026-64054
In the Linux kernel, the following vulnerability has been resolved:
net: shaper: reject duplicate leaves in GROUP request
net_shaper_nl_group_doit() does not deduplicate NET_SHAPER_A_LEAVES
entries. When userspace supplies the same leaf handle twice, the same
old-parent pointer lands twice in old_nodes[]. The cleanup loop double
frees the parent. Of course the same parent may still be in old_nodes[]
twice if we are moving multiple of its leaves.
Note that this patch also implicitly fixes the fact that the
i >= leaves_count path forgets to set ret.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: shaper: reject duplicate leaves in GROUP request
net_shaper_nl_group_doit() does not deduplicate NET_SHAPER_A_LEAVES
entries. When userspace supplies the same leaf handle twice, the same
old-parent pointer lands twice in old_nodes[]. The cleanup loop double
frees the parent. Of course the same parent may still be in old_nodes[]
twice if we are moving multiple of its leaves.
Note that this patch also implicitly fixes the fact that the
i >= leaves_count path forgets to set ret.
🎖@cveNotify
🚨 CVE-2026-64055
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Carry over frag counter
The gmac_rx() NAPI poll function assembles packets in an
SKB from a ring buffer.
If the ring buffer gets completely emptied during a poll cycle,
we exit gmac_rx(), but the packet is not yet completely
assembled in the SKB, yet the fragment counter frag_nr is
reset to zero on the next invocation.
Solve this by making the RX fragment counter a part of the
port struct, and carry it over between invocations.
Reset the fragment counter only right after calling
napi_gro_frags(), on error (after calling napi_free_frags())
or if stopping the port.
Reset it in some place where not strictly necessary just to
emphasize what is going on.
This was found by Sashiko during normal patch review.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Carry over frag counter
The gmac_rx() NAPI poll function assembles packets in an
SKB from a ring buffer.
If the ring buffer gets completely emptied during a poll cycle,
we exit gmac_rx(), but the packet is not yet completely
assembled in the SKB, yet the fragment counter frag_nr is
reset to zero on the next invocation.
Solve this by making the RX fragment counter a part of the
port struct, and carry it over between invocations.
Reset the fragment counter only right after calling
napi_gro_frags(), on error (after calling napi_free_frags())
or if stopping the port.
Reset it in some place where not strictly necessary just to
emphasize what is going on.
This was found by Sashiko during normal patch review.
🎖@cveNotify
🚨 CVE-2026-64056
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Make RX SKB per-port
The SKB used to assemble packets from fragments in gmac_rx()
is static local, but the Gemini has two ethernet ports, meaning
there can be races between the ports on a bad day if a device
is using both.
Make the RX SKB a per-port variable and carry it over between
invocations in the port struct instead.
Zero the pointer once we call napi_gro_frags(), on error (after
calling napi_free_frags()) or if the port is stopped.
Zero it in some place where not strictly necessary just to
emphasize what is going on.
This was found by Sashiko during normal patch review.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Make RX SKB per-port
The SKB used to assemble packets from fragments in gmac_rx()
is static local, but the Gemini has two ethernet ports, meaning
there can be races between the ports on a bad day if a device
is using both.
Make the RX SKB a per-port variable and carry it over between
invocations in the port struct instead.
Zero the pointer once we call napi_gro_frags(), on error (after
calling napi_free_frags()) or if the port is stopped.
Zero it in some place where not strictly necessary just to
emphasize what is going on.
This was found by Sashiko during normal patch review.
🎖@cveNotify
🚨 CVE-2026-64057
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the locking used by afs_get_link()
The afs filesystem in the kernel doesn't do locking correctly for symbolic
links. There are a number of problems:
(1) It doesn't do any locking around afs_read_single() to prevent races
between multiple ->get_link() calls, thereby allowing the possibility
of leaks.
(2) It doesn't use RCU barriering when accessing the buffer pointers
during RCU pathwalk.
(3) It can race with another thread updating the contents of the symlink
if a third party updated it on the server.
Fix this by the following means:
(0) Move symlink handling into its own file as this makes it more
complicated.
(1) Take the validate_lock around afs_read_single() to prevent races
between multiple ->get_link() calls.
(2) Keep a separate copy of the symlink contents with an rcu_head. This
is always going to be a lot smaller than a page, so it can be
kmalloc'd and save quite a bit of memory. It also needs a refcount
for non-RCU pathwalk.
(3) Split the symlink read and write-to-cache routines in afs from those
for directories.
(4) Discard the I/O buffer as soon as the write-to-cache completes as this
is a full page (plus a folio_queue).
(5) If there's no cache, discard the I/O buffer immediately after reading
and copying if there is no cache.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the locking used by afs_get_link()
The afs filesystem in the kernel doesn't do locking correctly for symbolic
links. There are a number of problems:
(1) It doesn't do any locking around afs_read_single() to prevent races
between multiple ->get_link() calls, thereby allowing the possibility
of leaks.
(2) It doesn't use RCU barriering when accessing the buffer pointers
during RCU pathwalk.
(3) It can race with another thread updating the contents of the symlink
if a third party updated it on the server.
Fix this by the following means:
(0) Move symlink handling into its own file as this makes it more
complicated.
(1) Take the validate_lock around afs_read_single() to prevent races
between multiple ->get_link() calls.
(2) Keep a separate copy of the symlink contents with an rcu_head. This
is always going to be a lot smaller than a page, so it can be
kmalloc'd and save quite a bit of memory. It also needs a refcount
for non-RCU pathwalk.
(3) Split the symlink read and write-to-cache routines in afs from those
for directories.
(4) Discard the I/O buffer as soon as the write-to-cache completes as this
is a full page (plus a folio_queue).
(5) If there's no cache, discard the I/O buffer immediately after reading
and copying if there is no cache.
🎖@cveNotify
🚨 CVE-2026-64058
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_read_folio() to wait on writeback
Fix netfs_read_folio() to wait for an ongoing writeback to complete so that
it can trust the dirty flag and whatever is attached to folio->private
(folio->private may get cleaned up by the collector before it clears the
writeback flag).
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfs_read_folio() to wait on writeback
Fix netfs_read_folio() to wait for an ongoing writeback to complete so that
it can trust the dirty flag and whatever is attached to folio->private
(folio->private may get cleaned up by the collector before it clears the
writeback flag).
🎖@cveNotify
🚨 CVE-2026-64059
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix folio->private handling in netfs_perform_write()
Under some circumstances, netfs_perform_write() doesn't correctly
manipulate folio->private between NULL, NETFS_FOLIO_COPY_TO_CACHE, pointing
to a group and pointing to a netfs_folio struct, leading to potential
multiple attachments of private data with associated folio ref leaks and
also leaks of netfs_folio structs or netfs_group refs.
Fix this by consolidating the place at which a folio is marked uptodate in
one place and having that look at what's attached to folio->private and
decide how to clean it up and then set the new group. Also, the content
shouldn't be flushed if group is NULL, even if a group is specified in the
netfs_group parameter, as that would be the case for a new folio. A
filesystem should always specify netfs_group or never specify netfs_group.
The Sashiko auto-review tool noted that it was theoretically possible that
the fpos >= ctx->zero_point section might leak if it modified a streaming
write folio. This is unlikely, but with a network filesystem, third party
changes can happen. It also pointed out that __netfs_set_group() would
leak if called multiple times on the same folio from the "whole folio
modify section".
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix folio->private handling in netfs_perform_write()
Under some circumstances, netfs_perform_write() doesn't correctly
manipulate folio->private between NULL, NETFS_FOLIO_COPY_TO_CACHE, pointing
to a group and pointing to a netfs_folio struct, leading to potential
multiple attachments of private data with associated folio ref leaks and
also leaks of netfs_folio structs or netfs_group refs.
Fix this by consolidating the place at which a folio is marked uptodate in
one place and having that look at what's attached to folio->private and
decide how to clean it up and then set the new group. Also, the content
shouldn't be flushed if group is NULL, even if a group is specified in the
netfs_group parameter, as that would be the case for a new folio. A
filesystem should always specify netfs_group or never specify netfs_group.
The Sashiko auto-review tool noted that it was theoretically possible that
the fpos >= ctx->zero_point section might leak if it modified a streaming
write folio. This is unlikely, but with a network filesystem, third party
changes can happen. It also pointed out that __netfs_set_group() would
leak if called multiple times on the same folio from the "whole folio
modify section".
🎖@cveNotify
🚨 CVE-2026-64060
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix leak of request in netfs_write_begin() error handling
Fix netfs_write_begin() to not leak our ref on the request in the event
that we get an error from netfs_wait_for_read().
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix leak of request in netfs_write_begin() error handling
Fix netfs_write_begin() to not leak our ref on the request in the event
that we get an error from netfs_wait_for_read().
🎖@cveNotify
🚨 CVE-2026-64061
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early put of sink folio in netfs_read_gaps()
Fix netfs_read_gaps() to release the sink page it uses after waiting for
the request to complete. The way the sink page is used is that an
ITER_BVEC-class iterator is created that has the gaps from the target folio
at either end, but has the sink page tiled over the middle so that a single
read op can fill in both gaps.
The bug was found by KASAN detecting a UAF on the generic/075 xfstest in
the cifsd kernel thread that handles reception of data from the TCP socket:
BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20
Write of size 885 at addr ffff888107f92000 by task cifsd/1285
CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy)
Call Trace:
dump_stack_lvl+0x5d/0x80
print_report+0x17f/0x4f1
kasan_report+0x100/0x1e0
kasan_check_range+0x10f/0x1e0
__asan_memcpy+0x3c/0x60
_copy_to_iter+0x48a/0xa20
__skb_datagram_iter+0x2c9/0x430
skb_copy_datagram_iter+0x6e/0x160
tcp_recvmsg_locked+0xce0/0x1130
tcp_recvmsg+0xeb/0x300
inet_recvmsg+0xcf/0x3a0
sock_recvmsg+0xea/0x100
cifs_readv_from_socket+0x3a6/0x4d0 [cifs]
cifs_read_iter_from_socket+0xdd/0x130 [cifs]
cifs_readv_receive+0xaad/0xb10 [cifs]
cifs_demultiplex_thread+0x1148/0x1740 [cifs]
kthread+0x1cf/0x210
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early put of sink folio in netfs_read_gaps()
Fix netfs_read_gaps() to release the sink page it uses after waiting for
the request to complete. The way the sink page is used is that an
ITER_BVEC-class iterator is created that has the gaps from the target folio
at either end, but has the sink page tiled over the middle so that a single
read op can fill in both gaps.
The bug was found by KASAN detecting a UAF on the generic/075 xfstest in
the cifsd kernel thread that handles reception of data from the TCP socket:
BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20
Write of size 885 at addr ffff888107f92000 by task cifsd/1285
CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy)
Call Trace:
dump_stack_lvl+0x5d/0x80
print_report+0x17f/0x4f1
kasan_report+0x100/0x1e0
kasan_check_range+0x10f/0x1e0
__asan_memcpy+0x3c/0x60
_copy_to_iter+0x48a/0xa20
__skb_datagram_iter+0x2c9/0x430
skb_copy_datagram_iter+0x6e/0x160
tcp_recvmsg_locked+0xce0/0x1130
tcp_recvmsg+0xeb/0x300
inet_recvmsg+0xcf/0x3a0
sock_recvmsg+0xea/0x100
cifs_readv_from_socket+0x3a6/0x4d0 [cifs]
cifs_read_iter_from_socket+0xdd/0x130 [cifs]
cifs_readv_receive+0xaad/0xb10 [cifs]
cifs_demultiplex_thread+0x1148/0x1740 [cifs]
kthread+0x1cf/0x210
🎖@cveNotify
🚨 CVE-2026-64062
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential deadlock in write-through mode
Fix netfs_advance_writethrough() to always unlock the supplied folio and to
mark it dirty if it isn't yet written to the end. Unfortunately, it can't
be marked for writeback until the folio is done with as that may cause a
deadlock against mmapped reads and writes.
Even though it has been marked dirty, premature writeback can't occur as
the caller is holding both inode->i_rwsem (which will prevent concurrent
truncation, fallocation, DIO and other writes) and ictx->wb_lock (which
will cause flushing to wait and writeback to skip or wait).
Note that this may be easier to deal with once the queuing of folios is
split from the generation of subrequests.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential deadlock in write-through mode
Fix netfs_advance_writethrough() to always unlock the supplied folio and to
mark it dirty if it isn't yet written to the end. Unfortunately, it can't
be marked for writeback until the folio is done with as that may cause a
deadlock against mmapped reads and writes.
Even though it has been marked dirty, premature writeback can't occur as
the caller is holding both inode->i_rwsem (which will prevent concurrent
truncation, fallocation, DIO and other writes) and ictx->wb_lock (which
will cause flushing to wait and writeback to skip or wait).
Note that this may be easier to deal with once the queuing of folios is
split from the generation of subrequests.
🎖@cveNotify
🚨 CVE-2022-34821
A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2), SCALANCE M804PB (6GK5804-0AP00-2AA2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2), SCALANCE M874-2 (6GK5874-2AA00-2AA2), SCALANCE M874-3 (6GK5874-3AA00-2AA2), SCALANCE M876-3 (6GK5876-3AA02-2BA2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2), SCALANCE M876-4 (6GK5876-4AA10-2BA2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2), SCALANCE SC622-2C (6GK5622-2GS00-2AC2), SCALANCE SC622-2C (6GK5622-2GS00-2AC2), SCALANCE SC626-2C (6GK5626-2GS00-2AC2), SCALANCE SC626-2C (6GK5626-2GS00-2AC2), SCALANCE SC632-2C (6GK5632-2GS00-2AC2), SCALANCE SC632-2C (6GK5632-2GS00-2AC2), SCALANCE SC636-2C (6GK5636-2GS00-2AC2), SCALANCE SC636-2C (6GK5636-2GS00-2AC2), SCALANCE SC642-2C (6GK5642-2GS00-2AC2), SCALANCE SC642-2C (6GK5642-2GS00-2AC2), SCALANCE SC646-2C (6GK5646-2GS00-2AC2), SCALANCE SC646-2C (6GK5646-2GS00-2AC2), SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0), SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0), SIMATIC CP 1543-1 (6GK7543-1AX00-0XE0), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0), SIPLUS NET CP 1543-1 (6AG1543-1AX00-2XE0), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0). By injecting code to specific configuration options for OpenVPN, an attacker could execute arbitrary code with elevated privileges.
🎖@cveNotify
A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2), SCALANCE M804PB (6GK5804-0AP00-2AA2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2), SCALANCE M874-2 (6GK5874-2AA00-2AA2), SCALANCE M874-3 (6GK5874-3AA00-2AA2), SCALANCE M876-3 (6GK5876-3AA02-2BA2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2), SCALANCE M876-4 (6GK5876-4AA10-2BA2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2), SCALANCE SC622-2C (6GK5622-2GS00-2AC2), SCALANCE SC622-2C (6GK5622-2GS00-2AC2), SCALANCE SC626-2C (6GK5626-2GS00-2AC2), SCALANCE SC626-2C (6GK5626-2GS00-2AC2), SCALANCE SC632-2C (6GK5632-2GS00-2AC2), SCALANCE SC632-2C (6GK5632-2GS00-2AC2), SCALANCE SC636-2C (6GK5636-2GS00-2AC2), SCALANCE SC636-2C (6GK5636-2GS00-2AC2), SCALANCE SC642-2C (6GK5642-2GS00-2AC2), SCALANCE SC642-2C (6GK5642-2GS00-2AC2), SCALANCE SC646-2C (6GK5646-2GS00-2AC2), SCALANCE SC646-2C (6GK5646-2GS00-2AC2), SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0), SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0), SIMATIC CP 1543-1 (6GK7543-1AX00-0XE0), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0), SIPLUS NET CP 1543-1 (6AG1543-1AX00-2XE0), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0). By injecting code to specific configuration options for OpenVPN, an attacker could execute arbitrary code with elevated privileges.
🎖@cveNotify
🚨 CVE-2023-7259
** DISPUTED ** A vulnerability was found in zzdevelop lenosp up to 20230831. It has been classified as problematic. This affects an unknown part of the component Adduser Page. The manipulation of the argument username with the input <script>alert(1)</script> leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The associated identifier of this vulnerability is VDB-266127. NOTE: The vendor rejected the issue because he claims that XSS which require administrative privileges are not of any use for attackers.
🎖@cveNotify
** DISPUTED ** A vulnerability was found in zzdevelop lenosp up to 20230831. It has been classified as problematic. This affects an unknown part of the component Adduser Page. The manipulation of the argument username with the input <script>alert(1)</script> leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The associated identifier of this vulnerability is VDB-266127. NOTE: The vendor rejected the issue because he claims that XSS which require administrative privileges are not of any use for attackers.
🎖@cveNotify
🚨 CVE-2023-7249
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in OpenText OpenText Directory Services allows Path Traversal.This issue affects OpenText Directory Services: from 16.4.2 before 24.1.
🎖@cveNotify
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in OpenText OpenText Directory Services allows Path Traversal.This issue affects OpenText Directory Services: from 16.4.2 before 24.1.
🎖@cveNotify
🚨 CVE-2023-7260
Path Traversal vulnerability discovered in OpenText™ CX-E Voice,
affecting all version through 22.4. The vulnerability could allow arbitrarily access files on the system.
🎖@cveNotify
Path Traversal vulnerability discovered in OpenText™ CX-E Voice,
affecting all version through 22.4. The vulnerability could allow arbitrarily access files on the system.
🎖@cveNotify
🚨 CVE-2023-7279
A vulnerability has been found in Secure Systems Engineering Connaisseur up to 3.3.0 and classified as problematic. This vulnerability affects unknown code of the file connaisseur/res/targets_schema.json of the component Delegation Name Handler. The manipulation leads to inefficient regular expression complexity. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 3.3.1 is able to address this issue. The name of the patch is 524b73ff7306707f6d3a4d1e86401479bca91b02. It is recommended to upgrade the affected component.
🎖@cveNotify
A vulnerability has been found in Secure Systems Engineering Connaisseur up to 3.3.0 and classified as problematic. This vulnerability affects unknown code of the file connaisseur/res/targets_schema.json of the component Delegation Name Handler. The manipulation leads to inefficient regular expression complexity. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 3.3.1 is able to address this issue. The name of the patch is 524b73ff7306707f6d3a4d1e86401479bca91b02. It is recommended to upgrade the affected component.
🎖@cveNotify
GitHub
sec: Prevent ReDoS during delegation validation · sse-secure-systems/connaisseur@524b73f
This commit fixes a regular expression denial of service vulnerability that was present during the schema validation of the targets.json TUF file in a Notary validation. An adversary with the abili...