The Linux kernel — the core of the OS that runs every container and drives the hardware.
Version: 6.18.49
Type: Kernel
License:
| Expand | CVE | Title | ||
|---|---|---|---|---|
| CVE-2026-100075 Open CVE-2026-100075 in a new tab | In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error. | Not affected | Critical | |
| CVE-2026-31501 Open CVE-2026-31501 in a new tab | In the Linux kernel, the following vulnerability has been resolved: net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor. In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is freed via k3_cppi_desc_pool_free() before the psdata pointer is used by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1]. This constitutes a use-after-free on every received packet that goes through the timestamp path. Defer the descriptor free until after all accesses through the psdata pointer are complete. For emac_rx_packet(), move the free into the requeue label so both early-exit and success paths free the descriptor after all accesses are done. For emac_rx_packet_zc(), move the free to the end of the loop body after emac_dispatch_skb_zc() (which calls emac_rx_timestamp()) has returned. | Not affected | Critical | |
| CVE-2026-31589 Open CVE-2026-31589 in a new tab | In the Linux kernel, the following vulnerability has been resolved: mm: call ->free_folio() directly in folio_unmap_invalidate() We can only call filemap_free_folio() if we have a reference to (or hold a lock on) the mapping. Otherwise, we've already removed the folio from the mapping so it no longer pins the mapping and the mapping can be removed, causing a use-after-free when accessing mapping->a_ops. Follow the same pattern as __remove_mapping() and load the free_folio function pointer before dropping the lock on the mapping. That lets us make filemap_free_folio() static as this was the only caller outside filemap.c. | Not affected | Critical | |
| CVE-2026-43414 Open CVE-2026-43414 in a new tab | In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea. | Not affected | Critical | |
| CVE-2026-53260 Open CVE-2026-53260 in a new tab | In the Linux kernel, the following vulnerability has been resolved: tcp: Add preempt_{disable,enable}_nested() in reqsk_queue_hash_req(). syzbot reported a weird reqsk->rsk_refcnt underflow in __inet_csk_reqsk_queue_drop(). The captured reqsk_put() in __inet_csk_reqsk_queue_drop() is called only when it successfully removes reqsk from ehash. Moreover, reqsk_timer_handler() calls another reqsk_put() after that. This indicates that the reqsk was missing both refcnts for ehash and the timer itself. Since all the syzbot reports had PREEMPT_RT enabled, the only possible scenario is that reqsk_queue_hash_req() is preempted after mod_timer() and before refcount_set(), and then the timer triggered after 1s aborts the reqsk due to its listener's close(). Let's wrap mod_timer() and refcount_set() with preempt_disable_nested() and preempt_enable_nested(). Note that inet_ehash_insert() holds the normal spin_lock() (mutex in PREEMPT_RT), so it must be called outside of preempt_disable_nested(), but this is fine. The lookup path just ignores 0 sk_refcnt entries in ehash and tries to create another reqsk, but this will fail at inet_ehash_insert(). [0]: refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28, CPU#0: ktimers/0/16 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28 Code: e4 7d d1 0a 67 48 0f b9 3a eb 4a e8 38 3d 23 fd 48 8d 3d e1 7d d1 0a 67 48 0f b9 3a eb 37 e8 25 3d 23 fd 48 8d 3d de 7d d1 0a <67> 48 0f b9 3a eb 24 e8 12 3d 23 fd 48 8d 3d db 7d d1 0a 67 48 0f RSP: 0000:ffffc90000157948 EFLAGS: 00010246 RAX: ffffffff84a1301b RBX: 0000000000000003 RCX: ffff88801ca98000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffffff8f72ae00 RBP: ffffffff99ae3b01 R08: ffff88801ca98000 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880425ef568 R13: ffff8880425ef4f8 R14: ffff8880425ef578 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888126386000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7b46710e9c CR3: 000000000dbb6000 CR4: 00000000003526f0 Call Trace: <TASK> __refcount_sub_and_test include/linux/refcount.h:400 [inline] __refcount_dec_and_test include/linux/refcount.h:432 [inline] refcount_dec_and_test include/linux/refcount.h:450 [inline] reqsk_put include/net/request_sock.h:136 [inline] __inet_csk_reqsk_queue_drop+0x3ce/0x440 net/ipv4/inet_connection_sock.c:1007 reqsk_timer_handler+0x651/0xdf0 net/ipv4/inet_connection_sock.c:1137 call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748 expire_timers kernel/time/timer.c:1799 [inline] __run_timers kernel/time/timer.c:2374 [inline] __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386 run_timer_base kernel/time/timer.c:2395 [inline] run_timer_softirq+0x67/0x170 kernel/time/timer.c:2403 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0x69/0x100 kernel/softirq.c:1151 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> | Not affected | Critical | |
| CVE-2026-64067 Open CVE-2026-64067 in a new tab | In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing barriers when accessing stream->subrequests locklessly The list of subrequests attached to stream->subrequests is accessed without locks by netfs_collect_read_results() and netfs_collect_write_results(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if no lock is taken. Fix this by: (1) Add a new list_add_tail_release() function that uses a release barrier to set the pointer to the new member of the list. (2) Add a new list_first_entry_or_null_acquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL). (3) Use list_add_tail_release() when adding a subreq to ->subrequests. (4) Use list_first_entry_or_null_acquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock). | Not affected | Critical | |
| CVE-2026-64068 Open CVE-2026-64068 in a new tab | In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing locking around retry adding new subreqs Fix netfs_retry_read_subrequests() and netfs_retry_write_stream() to take the appropriate lock when adding extra subrequests into stream->subrequests. | Not affected | Critical | |
| CVE-2026-64160 Open CVE-2026-64160 in a new tab | In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential for tearing in ->remote_i_size and ->zero_point Fix potential tearing in using ->remote_i_size and ->zero_point by copying i_size_read() and i_size_write() and using the same seqcount as for i_size. We need to make sure that netfslib and the filesystems that use it always hold i_lock whilst updating any of the sizes to prevent i_size_seqcount from getting corrupted. | Not affected | Critical | |
| CVE-2026-72064 Open CVE-2026-72064 in a new tab | net: mana: Sync page pool RX frags for CPU | Not affected | Critical | |
| CVE-2026-72329 Open CVE-2026-72329 in a new tab | net/liquidio: drop cached VF pci_dev LUT | Not affected | Critical | |
| CVE-2026-72355 Open CVE-2026-72355 in a new tab | netfs: Fix barriering when walking subrequest list | Not affected | Critical | |
| CVE-2026-72477 Open CVE-2026-72477 in a new tab | fs/ntfs3: call _ntfs_bad_inode() when failing to rename | Not affected | Critical | |
| CVE-2026-72493 Open CVE-2026-72493 in a new tab | net: serialize netif_running() check in enqueue_to_backlog() | Not affected | Critical | |
| CVE-2026-72494 Open CVE-2026-72494 in a new tab | RDMA/irdma: Replace waitqueue and flag with completion | Not affected | Critical | |
| CVE-2026-72496 Open CVE-2026-72496 in a new tab | RDMA/bnxt_re: Proper rollback if the ioremap fails | Not affected | Critical | |
| CVE-2026-74269 Open CVE-2026-74269 in a new tab | bnxt: fix head underflow on XDP head-grow | Not affected | Critical | |
| CVE-2026-74350 Open CVE-2026-74350 in a new tab | ocfs2: validate fast symlink target during inode read | Not affected | Critical | |
| CVE-2026-74521 Open CVE-2026-74521 in a new tab | ksmbd: use memcmp() to compare ClientGUIDs | Not affected | Critical | |
| CVE-2026-74568 Open CVE-2026-74568 in a new tab | KVM: arm64: vgic: Fix race between LPI release and re-registration | Not affected | Critical | |
| CVE-2026-74723 Open CVE-2026-74723 in a new tab | btrfs: lzo: reject inline extents without valid headers | Not affected | Critical | |
| CVE-2026-74752 Open CVE-2026-74752 in a new tab | sctp: validate cookie AUTH state before use | Not affected | Critical | |
| CVE-2026-80634 Open CVE-2026-80634 in a new tab | netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag | Not affected | Critical | |
| CVE-2026-80693 Open CVE-2026-80693 in a new tab | idpf: bound interrupt-vector register fill to the allocated array | Not affected | Critical | |
| CVE-2026-80945 Open CVE-2026-80945 in a new tab | crypto: iaa - unmap dst before software fallback on decompress | Not affected | Critical | |
| CVE-2026-80976 Open CVE-2026-80976 in a new tab | seg6: reset IP6CB after IPv6 decapsulation | Not affected | Critical | |
| CVE-2026-80980 Open CVE-2026-80980 in a new tab | net/smc: stop killed, freed and out_of_sync sharing a byte | Not affected | Critical | |
| CVE-2026-80981 Open CVE-2026-80981 in a new tab | net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link() | Not affected | Critical | |
| CVE-2026-80986 Open CVE-2026-80986 in a new tab | net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages | Not affected | Critical | |
| CVE-2026-81002 Open CVE-2026-81002 in a new tab | xdp: fix zero-copy frame layout | Not affected | Critical | |
| CVE-2026-89448 Open CVE-2026-89448 in a new tab | iommu/vt-d: Force requesting ACS when tboot is enabled | Not affected | Critical | |
| CVE-2026-89478 Open CVE-2026-89478 in a new tab | sctp: drop a chunk if its transport was removed | Not affected | Critical | |
| CVE-2026-89479 Open CVE-2026-89479 in a new tab | sctp: stop processing a packet once its association is deleted | Not affected | Critical | |
| CVE-2026-89482 Open CVE-2026-89482 in a new tab | nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone | Not affected | Critical | |
| CVE-2026-89485 Open CVE-2026-89485 in a new tab | lockd: pin next file across nlm_inspect_file lock-drop | Not affected | Critical | |
| CVE-2026-89492 Open CVE-2026-89492 in a new tab | ocfs2: validate directory-index entry counts when reading metadata | Not affected | Critical | |
| CVE-2026-89494 Open CVE-2026-89494 in a new tab | ocfs2: validate lengths in dlm_mig_lockres_handler | Not affected | Critical | |
| CVE-2026-89495 Open CVE-2026-89495 in a new tab | ocfs2: bound namelen in dlm_migrate_request_handler | Not affected | Critical | |
| CVE-2026-89526 Open CVE-2026-89526 in a new tab | svcrdma: Validate Read chunk positions before reconstruction | Not affected | Critical | |
| CVE-2026-89530 Open CVE-2026-89530 in a new tab | svcrdma: Reject inline replies that overflow the pull-up buffer | Not affected | Critical | |
| CVE-2026-89532 Open CVE-2026-89532 in a new tab | svcrdma: Fix pcl_for_each_segment for empty chunks | Not affected | Critical | |
| CVE-2026-89533 Open CVE-2026-89533 in a new tab | svcrdma: Fix offset arithmetic in read_chunk_range | Not affected | Critical | |
| CVE-2026-89536 Open CVE-2026-89536 in a new tab | SUNRPC: wait for in-flight client TLS handshake callback | Not affected | Critical | |
| CVE-2026-89537 Open CVE-2026-89537 in a new tab | SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2 | Not affected | Critical | |
| CVE-2026-89538 Open CVE-2026-89538 in a new tab | SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field | Not affected | Critical | |
| CVE-2026-89541 Open CVE-2026-89541 in a new tab | SUNRPC: harden gss_unwrap_resp_priv length checks | Not affected | Critical | |
| CVE-2026-89542 Open CVE-2026-89542 in a new tab | SUNRPC: harden gss_krb5_unwrap_v2 against short tokens | Not affected | Critical | |
| CVE-2026-89550 Open CVE-2026-89550 in a new tab | SUNRPC: svcauth_gss: enforce krb5 token minimum length | Not affected | Critical | |
| CVE-2026-89551 Open CVE-2026-89551 in a new tab | SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow | Not affected | Critical | |
| CVE-2026-89555 Open CVE-2026-89555 in a new tab | mpls: reload header after pskb_may_pull() | Not affected | Critical | |
| CVE-2026-89558 Open CVE-2026-89558 in a new tab | md/raid10: fix still_degraded being inverted in raid10_sync_request() | Not affected | Critical |
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale n_rw_ctx and n_rdma values (and a dangling rw_ctxs pointer). Later sq_wr_avail accounting in srpt_queue_response() or srpt_write_pending() can then subtract the wrong number of send queue credits. Reset the counters and clear rw_ctxs after freeing the heap allocation before returning an error.
In the Linux kernel, the following vulnerability has been resolved: net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor. In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is freed via k3_cppi_desc_pool_free() before the psdata pointer is used by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1]. This constitutes a use-after-free on every received packet that goes through the timestamp path. Defer the descriptor free until after all accesses through the psdata pointer are complete. For emac_rx_packet(), move the free into the requeue label so both early-exit and success paths free the descriptor after all accesses are done. For emac_rx_packet_zc(), move the free to the end of the loop body after emac_dispatch_skb_zc() (which calls emac_rx_timestamp()) has returned.
In the Linux kernel, the following vulnerability has been resolved: mm: call ->free_folio() directly in folio_unmap_invalidate() We can only call filemap_free_folio() if we have a reference to (or hold a lock on) the mapping. Otherwise, we've already removed the folio from the mapping so it no longer pins the mapping and the mapping can be removed, causing a use-after-free when accessing mapping->a_ops. Follow the same pattern as __remove_mapping() and load the free_folio function pointer before dropping the lock on the mapping. That lets us make filemap_free_folio() static as this was the only caller outside filemap.c.
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.
In the Linux kernel, the following vulnerability has been resolved: tcp: Add preempt_{disable,enable}_nested() in reqsk_queue_hash_req(). syzbot reported a weird reqsk->rsk_refcnt underflow in __inet_csk_reqsk_queue_drop(). The captured reqsk_put() in __inet_csk_reqsk_queue_drop() is called only when it successfully removes reqsk from ehash. Moreover, reqsk_timer_handler() calls another reqsk_put() after that. This indicates that the reqsk was missing both refcnts for ehash and the timer itself. Since all the syzbot reports had PREEMPT_RT enabled, the only possible scenario is that reqsk_queue_hash_req() is preempted after mod_timer() and before refcount_set(), and then the timer triggered after 1s aborts the reqsk due to its listener's close(). Let's wrap mod_timer() and refcount_set() with preempt_disable_nested() and preempt_enable_nested(). Note that inet_ehash_insert() holds the normal spin_lock() (mutex in PREEMPT_RT), so it must be called outside of preempt_disable_nested(), but this is fine. The lookup path just ignores 0 sk_refcnt entries in ehash and tries to create another reqsk, but this will fail at inet_ehash_insert(). [0]: refcount_t: underflow; use-after-free. WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28, CPU#0: ktimers/0/16 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28 Code: e4 7d d1 0a 67 48 0f b9 3a eb 4a e8 38 3d 23 fd 48 8d 3d e1 7d d1 0a 67 48 0f b9 3a eb 37 e8 25 3d 23 fd 48 8d 3d de 7d d1 0a <67> 48 0f b9 3a eb 24 e8 12 3d 23 fd 48 8d 3d db 7d d1 0a 67 48 0f RSP: 0000:ffffc90000157948 EFLAGS: 00010246 RAX: ffffffff84a1301b RBX: 0000000000000003 RCX: ffff88801ca98000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffffff8f72ae00 RBP: ffffffff99ae3b01 R08: ffff88801ca98000 R09: 0000000000000005 R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880425ef568 R13: ffff8880425ef4f8 R14: ffff8880425ef578 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff888126386000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7b46710e9c CR3: 000000000dbb6000 CR4: 00000000003526f0 Call Trace: <TASK> __refcount_sub_and_test include/linux/refcount.h:400 [inline] __refcount_dec_and_test include/linux/refcount.h:432 [inline] refcount_dec_and_test include/linux/refcount.h:450 [inline] reqsk_put include/net/request_sock.h:136 [inline] __inet_csk_reqsk_queue_drop+0x3ce/0x440 net/ipv4/inet_connection_sock.c:1007 reqsk_timer_handler+0x651/0xdf0 net/ipv4/inet_connection_sock.c:1137 call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748 expire_timers kernel/time/timer.c:1799 [inline] __run_timers kernel/time/timer.c:2374 [inline] __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386 run_timer_base kernel/time/timer.c:2395 [inline] run_timer_softirq+0x67/0x170 kernel/time/timer.c:2403 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0x69/0x100 kernel/softirq.c:1151 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing barriers when accessing stream->subrequests locklessly The list of subrequests attached to stream->subrequests is accessed without locks by netfs_collect_read_results() and netfs_collect_write_results(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFS_SREQ_IN_PROGRESS flag is perceived to be set first if no lock is taken. Fix this by: (1) Add a new list_add_tail_release() function that uses a release barrier to set the pointer to the new member of the list. (2) Add a new list_first_entry_or_null_acquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL). (3) Use list_add_tail_release() when adding a subreq to ->subrequests. (4) Use list_first_entry_or_null_acquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock).
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing locking around retry adding new subreqs Fix netfs_retry_read_subrequests() and netfs_retry_write_stream() to take the appropriate lock when adding extra subrequests into stream->subrequests.
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential for tearing in ->remote_i_size and ->zero_point Fix potential tearing in using ->remote_i_size and ->zero_point by copying i_size_read() and i_size_write() and using the same seqcount as for i_size. We need to make sure that netfslib and the filesystems that use it always hold i_lock whilst updating any of the sizes to prevent i_size_seqcount from getting corrupted.
net: mana: Sync page pool RX frags for CPU
net/liquidio: drop cached VF pci_dev LUT
netfs: Fix barriering when walking subrequest list
fs/ntfs3: call _ntfs_bad_inode() when failing to rename
net: serialize netif_running() check in enqueue_to_backlog()
RDMA/irdma: Replace waitqueue and flag with completion
RDMA/bnxt_re: Proper rollback if the ioremap fails
bnxt: fix head underflow on XDP head-grow
ocfs2: validate fast symlink target during inode read
ksmbd: use memcmp() to compare ClientGUIDs
KVM: arm64: vgic: Fix race between LPI release and re-registration
btrfs: lzo: reject inline extents without valid headers
sctp: validate cookie AUTH state before use
netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag
idpf: bound interrupt-vector register fill to the allocated array
crypto: iaa - unmap dst before software fallback on decompress
seg6: reset IP6CB after IPv6 decapsulation
net/smc: stop killed, freed and out_of_sync sharing a byte
net/smc: fix use-after-free of the LLC qentry in smc_llc_srv_add_link()
net/smc: bound the peer rkey counts in SMC-Rv2 LLC messages
xdp: fix zero-copy frame layout
iommu/vt-d: Force requesting ACS when tboot is enabled
sctp: drop a chunk if its transport was removed
sctp: stop processing a packet once its association is deleted
nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone
lockd: pin next file across nlm_inspect_file lock-drop
ocfs2: validate directory-index entry counts when reading metadata
ocfs2: validate lengths in dlm_mig_lockres_handler
ocfs2: bound namelen in dlm_migrate_request_handler
svcrdma: Validate Read chunk positions before reconstruction
svcrdma: Reject inline replies that overflow the pull-up buffer
svcrdma: Fix pcl_for_each_segment for empty chunks
svcrdma: Fix offset arithmetic in read_chunk_range
SUNRPC: wait for in-flight client TLS handshake callback
SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2
SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field
SUNRPC: harden gss_unwrap_resp_priv length checks
SUNRPC: harden gss_krb5_unwrap_v2 against short tokens
SUNRPC: svcauth_gss: enforce krb5 token minimum length
SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow
mpls: reload header after pskb_may_pull()
md/raid10: fix still_degraded being inverted in raid10_sync_request()
Showing 1–50 of 2996