Threats Tagged 'cve-2026-46015'

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * kernel: can: bcm: add locking for bcm_op runtime updates (CVE-2025-38004) * kernel: ipv6: add NULL checks for idev in SRv6 paths (CVE-2026-23442) * kernel: udp: Fix wildcard bind conflict check when using hash2 (CVE-2026-31503) * kernel: ipv6: prevent possible UaF in addrconf_permanent_addr() (CVE-2026-43339) * kernel: tcp: call sk_data_ready() after listener migration (CVE-2026-46015) * kernel: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP (CVE-2026-46266) * kernel: flow_dissector: do not dissect PPPoE PFC frames (CVE-2026-46306) * kernel: io_uring/poll: fix signed comparison in io_poll_get_ownership() (CVE-2026-52933) * kernel: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls (CVE-2026-53075) * kernel: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation (CVE-2026-53277) * kernel: ipv6: sit: reload inner IPv6 header after GSO offloads (CVE-2026-53228) * kernel: net: add pskb_may_pull() to skb_gro_receive_list() (CVE-2026-53235) * kernel: net: guard timestamp cmsgs to real error queue skbs (CVE-2026-53223) * kernel: ipv6: mcast: Fix use-after-free when processing MLD queries (CVE-2026-53275) * kernel: ipv6: anycast: insert aca into global hash under idev->lock (CVE-2026-53259) * kernel: ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() (CVE-2026-64002) * kernel: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() (CVE-2026-63993) * kernel: fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req (CVE-2026-64265) * kernel: nvmet-auth: validate reply message payload bounds against transfer length (CVE-2026-64319) * kernel: KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU (CVE-2026-64287) * kernel: rhashtable: clear stale iter->p on table restart (CVE-2026-64563) * kernel: smb: client: fix double-free in SMB2_close() replay (CVE-2026-64597) Bug Fix(es) and Enhancement(s): * Customer needs "netfilter: nfnetlink_queue: optimize verdict lookup with hash table" patch [RHEL 10.2] (JIRA:RHEL-132852) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.

CVE-2026-46015 is a vulnerability related to the TCP stack in Microsoft products, specifically involving the function call sk_data_ready() after listener migration. The provided information does not include technical details about the nature of the vulnerability, its exploitation methods, or impact. No CVSS score or patch information is available, and there are no known exploits in the wild. The affected products include Microsoft and Azure Linux 3.0 versions. Due to limited data, the severity is assessed as medium based on the potential impact of TCP stack vulnerabilities generally.