| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| IBM Common Licensing Agent 9.0, Agent 9.0.0.1, Agent 9.0.0.2, ART 9.0, ART 9.0.0.1, and ART 9.0.0.2 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. |
| IBM Controller 11.0.0 through 11.0.1 FP7, and 11.1.0 through 11.1.3 FP1 could allow an authenticated user to bypass input validation due to improper validation of client-side input of file size. |
| IBM MQ Console allows authenticated non-administrative users to create and start queue managers due to improper authorization checks. |
| IBM QRadar 7.5.0 through 7.5.0 UP15 Interim Fix 006 could allow an authenticated user to obtain sensitive information from backup files due to incorrect permissions assignment. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length
pair derived from skb->len, without bounding reads to the actual skb
data. Three problems followed:
- For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed.
- The per-TLV header (type, length) was read without checking that two
bytes remained.
- A declared TLV length could run past the end of the buffer, and an
SDREQ with length == 0 made "service_name_len = length - 1" underflow
(size_t), driving an out-of-bounds read in the following strncmp() /
nfc_llcp_sock_from_sn(). The SDRES case likewise read tlv[2]/tlv[3]
without a length check.
A nearby NFC device can reach this without authentication; LLCP link
activation happens automatically after NFC-DEP.
Walk the TLV list by pointer, bounded by skb_tail_pointer() over the
linear skb data, and validate each TLV declared length before use. Add
explicit length checks for SDREQ (>= 1) and SDRES (exactly 2).
Found by 0sec automated security-research tooling (https://0sec.ai). |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate orphan slot during inode read
Patch series "ocfs2: validate active orphan slots during inode read".
OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes.
A corrupted slot can therefore index osb_orphan_wipes or the slot-local
system-inode cache outside their allocations before the corruption is
reported.
Patch 1 validates the ordinary orphan slot used by inode wipe processing.
Patch 2 validates the append-DIO orphan slot used by DIO completion and
orphan recovery. Both checks reject corrupt metadata at the existing inode
validation boundary.
This patch (of 2):
[BUG]
A corrupted dinode with OCFS2_ORPHANED_FL can carry an
i_orphaned_slot outside the mounted filesystem slot range.
ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking
up the orphan directory, causing an out-of-bounds memory access.
BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102
Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85
Call Trace:
...
ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102
ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840
ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline]
ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295
evict+0x38e/0x8f0 fs/inode.c:810
iput_final fs/inode.c:1914 [inline]
iput fs/inode.c:1966 [inline]
iput+0x55b/0x8b0 fs/inode.c:1926
ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374
ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373
...
[CAUSE]
ocfs2_validate_inode_block() validates i_suballoc_slot but leaves
the active ordinary orphan slot unchecked. Downstream consumers
assume that the value is smaller than osb->max_slots.
[FIX]
Reject an active i_orphaned_slot outside the slot range during
dinode validation, before the inode reaches orphan wipe processing. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: reject out-of-range evcn in mi_enum_attr()
In mi_enum_attr(), the start/end VCN validation for non-resident
attributes is:
if (svcn > evcn + 1) goto out;
When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn
passes the check. For evcn values close to U64_MAX (but not equal to it)
the right-hand side is still a meaningless near-wrap upper bound, so a
malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass
mi_enum_attr() unrejected.
VCN (virtual cluster number) is a cluster index, so any valid evcn is
bounded by the volume's total cluster count, which ntfs3 holds in
sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller
of mi_enum_attr() runs). Reject evcn values that fall outside this range.
However, an empty non-resident attribute (no allocated clusters) is
legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via
attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel
must keep passing, so exclude evcn == U64_MAX from the range check. The
existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is
false) and continues to require svcn == 0 for it, while the range check
rejects every other out-of-range evcn and thereby also defuses the
"evcn + 1" wraparound.
svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1"
implies svcn <= nbits.
[almaz.alexandrovich@paragon-software.com: fixed evcn check] |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: riscv-sbi-mpxy: validate RPMI notification lengths
The SBI return value controls how many bytes are copied from shared
memory into the RPMI notification buffer. It is not validated against
the negotiated shared-memory size before that copy. The event walker
also uses a reversed loop condition and can inspect a short event record.
Validate the complete notification length before copying it, iterate only
while a full event header remains, and stop when a declared event payload
extends beyond the copied notification data. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Do not skip lock checks for single-byte ranges
check_lock_range() uses inclusive ranges. Its callers pass the end
offset as start + length - 1, so start == end represents a valid
single-byte range rather than an empty range.
The start == end shortcut therefore skips mandatory byte-range lock
checks for one-byte reads, writes, copychunk operations and one-byte
truncate ranges. A conflicting lock covering that byte is not checked
and the operation is allowed to proceed.
Remove the shortcut. The truncate size == inode->i_size case is already
handled by only calling check_lock_range() when the new size differs
from the current file size. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user()
ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC
login response with
user->passkey_sz = resp->hash_sz;
user->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP);
if (user->passkey)
memcpy(user->passkey, resp->hash, resp->hash_sz);
resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is
only KSMBD_REQ_MAX_HASH_SZ bytes. A malformed or malicious login
response can set hash_sz well beyond that (up to 65535), so the memcpy()
reads past the end of the response object. ipc_validate_msg() does not
bound hash_sz, so reject any response whose hash_sz exceeds the on-stack
hash[] buffer before allocating and copying.
[ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680
[ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611
[ 2030.242296]
[ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy)
[ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work
[ 2030.242763] Call Trace:
[ 2030.242769] <TASK>
[ 2030.242776] dump_stack_lvl+0xa2/0xd0
[ 2030.242794] print_address_description+0x77/0x200
[ 2030.242815] ? ksmbd_alloc_user+0x278/0x680
[ 2030.242831] print_report+0x58/0x70
[ 2030.242848] kasan_report+0x117/0x150
[ 2030.242869] ? ksmbd_alloc_user+0x278/0x680
[ 2030.242888] kasan_check_range+0x3c7/0x3f0
[ 2030.242908] ? ksmbd_alloc_user+0x278/0x680
[ 2030.242925] __asan_memcpy+0x29/0x70
[ 2030.242942] ksmbd_alloc_user+0x278/0x680
[ 2030.242960] ksmbd_login_user+0xc3/0x120
[ 2030.242978] ntlm_authenticate+0x5e6/0x1b00
[ 2030.243017] ? __pfx_ntlm_authenticate+0x10/0x10
[ 2030.243035] ? ksmbd_session_lookup+0x188/0x1d0
[ 2030.243054] ? __pfx_ksmbd_session_lookup+0x10/0x10
[ 2030.243090] ? __sanitizer_cov_trace_switch+0x7b/0x140
[ 2030.243108] smb2_sess_setup+0x1e4a/0x27b0
[ 2030.243126] ? copy_from_kernel_nofault+0x199/0x300
[ 2030.243156] ? __pfx_smb2_sess_setup+0x10/0x10
[ 2030.243173] ? get_smb2_cmd_val+0xe3/0x1c0
[ 2030.243208] handle_ksmbd_work+0x954/0x1280
[ 2030.243230] ? __pfx_handle_ksmbd_work+0x10/0x10
[ 2030.243249] ? process_scheduled_works+0xa07/0x1490
[ 2030.243270] ? process_scheduled_works+0xa07/0x1490
[ 2030.243291] process_scheduled_works+0xa70/0x1490
[ 2030.243320] ? __pfx_process_scheduled_works+0x10/0x10
[ 2030.243340] ? do_raw_spin_lock+0x130/0x300
[ 2030.243358] ? lock_is_held_type+0x7b/0x110
[ 2030.243388] worker_thread+0x932/0xe20
[ 2030.243415] kthread+0x38a/0x470
[ 2030.243431] ? __pfx_worker_thread+0x10/0x10
[ 2030.243451] ? __pfx_kthread+0x10/0x10
[ 2030.243467] ret_from_fork+0x484/0x910
[ 2030.243485] ? __pfx_ret_from_fork+0x10/0x10
[ 2030.243501] ? __switch_to+0xc77/0x12c0
[ 2030.243523] ? __pfx_kthread+0x10/0x10
[ 2030.243540] ret_from_fork_asm+0x1a/0x30
[ 2030.243564] </TASK>
[ 2030.243570]
[ 2030.290164] Allocated by task 19279:
[ 2030.290911] kasan_save_track+0x3e/0x80
[ 2030.292179] __kasan_kmalloc+0x72/0x90
[ 2030.293217] __kvmalloc_node_noprof+0x3ff/0x6b0
[ 2030.294467] handle_generic_event+0x59b/0x750
[ 2030.295345] genl_family_rcv_msg_doit+0x238/0x340
[ 2030.296553] genl_rcv_msg+0x606/0x7b0
[ 2030.297129] netlink_rcv_skb+0x22b/0x4a0
[ 2030.298500] genl_rcv+0x2d/0x40
[ 2030.299273] netlink_unicast+0x7ba/0x930
[ 2030.300019] netlink_sendmsg+0x8c3/0xb00
[ 2030.301073] __sock_sendmsg+0xec/0x140
[ 2030.301579] __sys_sendto+0x357/0x470
[ 2030.302255] __x64_sys_sendto+0xe3/0x100
[ 2030.303425] do_syscall_64+0x135/0x460
[ 2030.304763] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 2030.305594]
[ 2030.305819] The buggy address belongs to the object at ffff888121bb6640
[ 2030.305819] which belongs to the cache kmalloc-192 of size 192
[ 2030.309595] The buggy address
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
smb: smbdirect: free completion queues with ib_free_cq()
smbdirect_connection_destroy_qp() creates the send and receive completion
queues with ib_alloc_cq_any(), which for IB_POLL_WORKQUEUE arms an
internal completion handler that runs ib_cq_poll_work() on a workqueue.
Tearing those CQs down with ib_destroy_cq() frees them without first
cancelling that poll work.
If the provider posts a completion late -- for example Soft-RoCE (rxe)
posting an RNR error from rxe_receiver() after rdma_destroy_qp() -- the
handler re-queues ib_cq_poll_work() on the already-freed CQ, and a
follow-on access faults in rxe_req_notify_cq().
Use ib_free_cq(), which cancel_work_sync()es the poll work before freeing
the CQ, so no completion handler can run against a freed queue.
[ 1236.599526] ==================================================================
[ 1236.602142] BUG: KASAN: slab-use-after-free in ib_cq_poll_work+0xd0/0x1a0
[ 1236.605524] Read of size 8 at addr ffff888111865800 by task kworker/4:1H/82
[ 1236.609017]
[ 1236.609270] CPU: 4 UID: 0 PID: 82 Comm: kworker/4:1H Not tainted 7.2.0-rc3-next-20260717-virtme #110 PREEMPT(lazy)
[ 1236.609287] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 1236.609498] Workqueue: ib-comp-wq ib_cq_poll_work
[ 1236.609525] Call Trace:
[ 1236.609536] <TASK>
[ 1236.609545] __dump_stack+0x21/0x60
[ 1236.609562] dump_stack_lvl+0xc2/0x100
[ 1236.609573] print_address_description+0x77/0x200
[ 1236.609587] ? ib_cq_poll_work+0xd0/0x1a0
[ 1236.609597] print_report+0x58/0x70
[ 1236.609607] kasan_report+0x117/0x150
[ 1236.609623] ? ib_cq_poll_work+0xd0/0x1a0
[ 1236.609636] ? process_scheduled_works+0x954/0x1600
[ 1236.609650] ib_cq_poll_work+0xd0/0x1a0
[ 1236.609662] ? process_scheduled_works+0x954/0x1600
[ 1236.609674] process_scheduled_works+0xc22/0x1600
[ 1236.609698] ? __pfx_process_scheduled_works+0x10/0x10
[ 1236.609713] ? __pfx_assign_work+0x10/0x10
[ 1236.609726] ? lock_is_held_type+0x7b/0x110
[ 1236.609741] worker_thread+0x975/0xee0
[ 1236.609757] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 1236.609775] ? __kthread_parkme+0x21e/0x260
[ 1236.609789] kthread+0x3a6/0x490
[ 1236.609800] ? __pfx_worker_thread+0x10/0x10
[ 1236.609809] ? __pfx_kthread+0x10/0x10
[ 1236.609820] ret_from_fork+0x55a/0xa20
[ 1236.609835] ? __pfx_ret_from_fork+0x10/0x10
[ 1236.609850] ? __pfx_kthread+0x10/0x10
[ 1236.609861] ret_from_fork_asm+0x1a/0x30
[ 1236.609880] </TASK>
[ 1236.609886]
[ 1236.661292] Allocated by task 5076:
[ 1236.662640] kasan_save_track+0x3e/0x80
[ 1236.663842] __kasan_kmalloc+0x72/0x90
[ 1236.664763] __kmalloc_noprof+0x2b0/0x5d0
[ 1236.665356] __ib_alloc_cq+0x284/0x1000
[ 1236.666573] __ib_alloc_cq_any+0x23e/0x340
[ 1236.668654] smbdirect_connection_create_qp+0x6f7/0x1070
[ 1236.669757] smbdirect_accept_connect_request+0x500/0x1ca0
[ 1236.672625] smbdirect_listen_rdma_event_handler+0x1655/0x1c50
[ 1236.673930] cma_listen_handler+0x1bf/0x260
[ 1236.674923] cma_cm_event_handler+0x128/0x380
[ 1236.676926] cma_ib_req_handler+0x2d3d/0x4de0
[ 1236.678368] cm_process_work+0xb0/0x530
[ 1236.680454] cm_queue_work_unlock+0xb1/0x230
[ 1236.681673] cm_work_handler+0x969f/0xdca0
[ 1236.682704] process_scheduled_works+0xc22/0x1600
[ 1236.683447] worker_thread+0x975/0xee0
[ 1236.685901] kthread+0x3a6/0x490
[ 1236.688164] ret_from_fork+0x55a/0xa20
[ 1236.689522] ret_from_fork_asm+0x1a/0x30
[ 1236.690073]
[ 1236.690378] Freed by task 5137:
[ 1236.692242] kasan_save_track+0x3e/0x80
[ 1236.694272] kasan_save_free_info+0x40/0x50
[ 1236.695514] __kasan_slab_free+0x3a/0x60
[ 1236.696773] kfree+0x14e/0x4e0
[ 1236.697216] ib_destroy_cq_user+0x18d/0x250
[ 1236.699817] smbdirect_connection_destroy_qp+0xf2/0x280
[ 1236.702115] smbdirect_socket_destroy_sync+0x1607/0x2720
[ 1236.704062] smbdirect_socket_release+0x140/0x280
[ 1236.705286] smb_direct_free_transpor
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
smb: smbdirect: destroy QP before mem pools on accept failure
On the rdma_accept_failed error path of
smbdirect_accept_connect_request(), the receive io posted just above is
owned by the QP (recv_io is set to NULL after a successful post). The
error path fell through to smbdirect_connection_destroy_mem_pools()
before smbdirect_connection_destroy_qp(), so the mem pools and the
recv_io slab cache were destroyed while that recv_io was still
outstanding on the QP.
The drain in smbdirect_connection_destroy_qp() (ib_drain_qp()) is what
runs the recv completion that returns the recv_io to the free list, so
destroying the pools first leaves the object outstanding at
kmem_cache_destroy() time ("Slab cache still has objects") and later
frees it into an already-destroyed mempool (mempool_free_bulk
NULL-pointer dereference).
Give rdma_accept_failed its own teardown that drains the QP first, then
destroys the mem pools, and returns. The remaining labels
(post_recv_io_failed onward) run before the recv_io was ever posted, so
they keep the mem-pools-then-qp order.
The outstanding recv_io at kmem_cache_destroy() time:
[ 3487.344647] =============================================================================
[ 3487.349942] BUG smbdirect_recv_io_cache_ffff88811ba99000 (Not tainted): Objects remaining on __kmem_cache_shutdown()
[ 3487.356078] -----------------------------------------------------------------------------
[ 3487.356078]
[ 3487.356738] Object 0xffff8881511c3440 @offset=13376
[ 3487.358464] Allocated in mempool_alloc_noprof+0x18c/0x290 age=1194 cpu=6 pid=22254
[ 3487.361197] mempool_alloc_noprof+0x18c/0x290
[ 3487.361542] smbdirect_connection_create_mem_pools+0x405/0x780
[ 3487.361972] smbdirect_accept_connect_request+0x5a8/0x1b80
[ 3487.362359] smbdirect_listen_rdma_event_handler+0x1579/0x1b90
[ 3487.362779] cma_cm_event_handler+0x9c/0x230
[ 3487.363096] cma_ib_req_handler+0x2682/0x45d0
[ 3487.363414] cm_process_work+0x56/0x3d0
[ 3487.363676] cm_work_handler+0x8a0e/0xd000
[ 3487.367496] process_scheduled_works+0xa07/0x13a0
[ 3487.367859] worker_thread+0x7c9/0xc80
[ 3487.368148] kthread+0x341/0x430
[ 3487.368407] ret_from_fork+0x3a8/0x7a0
[ 3487.368704] ret_from_fork_asm+0x1a/0x30
[ 3487.370307] Slab 0xffffea0005447000 objects=19 used=1 fp=0xffff8881511c0040 flags=0x100000000000240(workingset|head|node=0|zone=2)
[ 3487.372840] ------------[ cut here ]------------
[ 3487.373195] WARNING: mm/slub.c:1244 at __slab_err+0x1a/0x30, CPU#6: kworker/6:84/22254
[ 3487.373759] Modules linked in:
[ 3487.373993] CPU: 6 UID: 0 PID: 22254 Comm: kworker/6:84 Tainted: G B 7.1.0-next-20260623+ #88 PREEMPT(lazy)
[ 3487.374778] Tainted: [B]=BAD_PAGE
[ 3487.377830] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 3487.378515] Workqueue: ib_cm cm_work_handler
[ 3487.378820] RIP: 0010:__slab_err+0x1a/0x30
[ 3487.379129] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 e8 36 00 00 00 bf 05 00 00 00 be 01 00 00 00 e8 f7 75 45 00 90 <0f> 0b 90 c3 cc cc cc cc cc 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
[ 3487.383255] RSP: 0018:ffff888220fc7050 EFLAGS: 00010093
[ 3487.383643] RAX: ffffffff8168e60a RBX: ffff88810955e640 RCX: ffff88821c381d80
[ 3487.384158] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff870fa080
[ 3487.384662] RBP: ffff888220fc7068 R08: ffffffff870fa087 R09: 1ffffffff0e1f410
[ 3487.385192] R10: dffffc0000000000 R11: fffffbfff0e1f411 R12: ffffea0005447210
[ 3487.385674] R13: ffffea0005447000 R14: ffff888220fc7068 R15: ffff88812a8ab300
[ 3487.388932] FS: 0000000000000000(0000) GS:ffff888427e76000(0000) knlGS:0000000000000000
[ 3487.389529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3487.389934] CR2: 00007ffcf2d84fd8 CR3: 0000000111d64006 CR4: 0000000000f72ef0
[ 3487.390440] PKRU: 55555554
[ 3487.390641] Call Trace:
[ 3487.390826] <TASK>
[ 3
---truncated--- |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: defer publishing granted locks to prevent UAF/double-free race
In smb2_lock(), mid-batch granted locks are published to connection-wide
(conn->lock_list) and file-wide (fp->lock_list) lists immediately upon
vfs_lock_file() success, while also remaining tracked on the stack-local
rollback_list.
If a subsequent element in the same SMB2_LOCK request array fails
validation or execution, the thread jumps to out: and walks
rollback_list to undo previously granted locks. However, because the
granted lock was already published to conn->lock_list, a concurrent
UNLOCK request on the same connection can find the lock object and
kfree() it before the rollback loop executes.
When the granting thread subsequently walks rollback_list, it
dereferences and frees the already-freed ksmbd_lock structure, resulting
in a Use-After-Free and Double-Free (on both ksmbd_lock and struct
file_lock).
Fix this by deferring the publication of granted locks to
conn->lock_list and fp->lock_list until after the entire array of lock
elements has been processed without error. Mid-batch grants remain
tracked exclusively on the request-local rollback_list until the whole
batch succeeds, eliminating the race window. |
| In the Linux kernel, the following vulnerability has been resolved:
NFSv4: remove callback IDR entry on client allocation failure
nfs4_alloc_client() allocates an NFSv4.0 callback identifier before it
finishes setting up the client. If any later initialization step fails,
the error path frees the nfs_client directly with nfs_free_client(). That
bypasses nfs_put_client(), which is where the callback IDR entry is
removed during normal teardown.
A failed allocation can therefore leave cb_ident_idr pointing at a freed
nfs_client. A later NFSv4.0 callback lookup by cb_ident would find the
stale pointer and take a reference to it.
Make the callback IDR removal helper callable by the allocation failure
path, and remove the callback identifier before freeing the client.
This was found by a local static-analysis checker for publish-before-free
lifetime bugs and confirmed by manual inspection. |
| In the Linux kernel, the following vulnerability has been resolved:
hinic3: Fix skb linearization mismatch and drop skb when skb_checksum_help() failed
Previously, hinic3_send_one_skb() cached the skb fragment count before
calling hinic3_tx_offload(). If hinic3_tx_csum() falls back to
skb_checksum_help() for unsupported tunnel packets, the skb may be
linearized. Continuing to build the TX descriptor with the stale
fragment count leads to a descriptor mismatch, which can trigger
out-of-bounds DMA reads or IOMMU faults.
Furthermore, the old code ignored the return value of skb_checksum_help(),
transmitting corrupted packets with incomplete checksums upon failure.
Fix this by:
1. Moving the hinic3_tx_offload() call before calculating 'num_sge' to
ensure the correct fragment count is used if the SKB is linearized.
2. Propagating skb_checksum_help() errors and returning
HINIC3_TX_OFFLOAD_INVALID to properly drop the skb. |
| In the Linux kernel, the following vulnerability has been resolved:
net: kcm: Hold RCU read lock while running BPF parser
kcm_parse_func_strparser() calls bpf_prog_run_pin_on_cpu() which
prevents CPU migration, but does not establish an RCU read-side
critical section. Consequently, BPF map operations can trigger
WARN_ON_ONCE(!bpf_rcu_lock_held()) when called from the KCM strparser
program.
Hold the RCU read lock while running the program. |
| In the Linux kernel, the following vulnerability has been resolved:
virtio_net: Fix resize of the RX ring
When a AF_XDP socket is attached, the virtnet_rx_resize
should resize the rq->xsk_buffs XSK buffer array. Otherwise,
when the size grows, the virtnet_rx_resume() causes a write
past the end of the array. This is easily reproducable with
ethtool -G ens3 rx 32
./xdpsock -i eth0 -q 0 -r -z &
ethtool -G eth0 rx 256 |
| In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix integer overflow in ftp helper port/address parsing
ip_vs_ftp_get_addrport() accumulates decimal digits into a __u16
(hport) and into unsigned char (p[]) without checking for overflow.
A crafted FTP PASV/EPSV response with an over-long port or address
octet wraps the value, so the helper configures the data connection
with a truncated port/address.
The netfilter conntrack FTP helper had the same defect, fixed in
commit 2b413fc689ba ("netfilter: nf_conntrack_ftp: avoid u16
overflows"). Apply the equivalent fix here: widen the port accumulator
to u32 and reject values above 65535, and reject address octets above
255. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: Fix index_root heap OOB write in ntfs_ir_to_ib()
ntfs_ir_to_ib copies all entries from index_root into a freshly allocated
index_block_size-byte buffer without verifying that the entries fit in the
available space. The entries in index_root may be larger than the usable
entry space in the index block.
This can cause OOB writes past the end of the allocation.
The validator ntfs_index_root_inconsistent() checks that entries are
self-consistent within the IR value, but never cross-checks them against
index_block_size. There is no bounds check in ntfs_ir_to_ib() before the
memcpy.
Fixing this at the sink in ntfs_ir_to_ib() since
ntfs_index_root_inconsistent() validates the logical consistency of
index_root as a structure and a root with large entries is a structurally
valid root. The bug is a size conflict of ntfs_ir_to_ib().
Also, the validator is called once per inode load in
ntfs_read_locked_inode() while ntfs_ir_to_ib() is only called during a
reparent, a check there adds no overhead to the common path.
Moreover, even a future call path that bypasses the validator would still
be protected.
With NULL as first parameter of ntfs_error(), the volume error flag is
never set by this call, so the device name will be absent from the error
message. In any case, that the caller, ntfs_ir_reparent(), prints an error
message that includes the device name on NULL returns.
I think this is the best solution available without adding
'struct super_block *sb' as a parameter to ntfs_ir_to_ib().
This heap out-of-bounds write is triggered by a crafted filesystem image,
which is not in the kernel threat model, anyway, fixing memory errors would
be nice to keep things secure. |
