In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone<\/p>\n
Commit 25e5cb780e62 (“nvme-tcp: fix possible crash in write_zeroes
\nprocessing”) established that blk_rq_payload_bytes() must not be read
\nwithout first checking blk_rq_nr_phys_segments(), and recorded the
\nresult in nvme_tcp_setup_cmd_pdu() as req->data_len. The receive side
\nwas left as it was.<\/p>\n
The two differ for REQ_OP_WRITE_ZEROES, which has no physical segments
\nbut a non-zero blk_rq_bytes(), so setup leaves req->iter untouched
\nwhile the receive gate lets a C2HData through and nvme_tcp_recv_data()
\ncopies into whatever the previous command on that tag left there. The
\ndriver-private area is zeroed only when the tag set is allocated.<\/p>\n
Reproduced with a test target that leaves a residual iterator on a tag
\nand then sends a C2HData for a WRITE_ZEROES command on the same tag:<\/p>\n
BUG: KASAN: wild-memory-access in _copy_to_iter+0x642\/0x1330
\nWrite of size 512 at addr ffe728c2175dfa81 by task kworker\/0:1H\/103<\/p>\n
CPU: 0 UID: 0 PID: 103 Comm: kworker\/0:1H Not tainted 7.2.0-rc5-NVMETCP-gf5098b6bae76 #1 PREEMPT(lazy)
\nHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04\/01\/2014
\nWorkqueue: nvme_tcp_wq nvme_tcp_io_work
\nCall Trace:<\/p>\n
dump_stack_lvl+0x53\/0x70
\n kasan_report+0xce\/0x100
\n ? _copy_to_iter+0x642\/0x1330
\n kasan_check_range+0x105\/0x1b0
\n __asan_memcpy+0x3c\/0x60
\n _copy_to_iter+0x642\/0x1330
\n ? __pfx_sock_has_perm+0x10\/0x10
\n ? worker_thread+0x45b\/0xd10
\n ? __pfx__copy_to_iter+0x10\/0x10
\n ? _raw_spin_lock_bh+0x83\/0xe0
\n ? __pfx__raw_spin_lock_bh+0x10\/0x10
\n __skb_datagram_iter+0xf3\/0x820
\n ? __pfx_simple_copy_to_iter+0x10\/0x10
\n ? __asan_memcpy+0x3c\/0x60
\n ? skb_copy_bits+0x58d\/0x830
\n skb_copy_datagram_iter+0x37\/0x120
\n nvme_tcp_recv_skb+0xa07\/0x4320
\n ? __pfx_nvme_tcp_recv_skb+0x10\/0x10
\n __tcp_read_sock+0x1ab\/0x810
\n ? __pfx_nvme_tcp_recv_skb+0x10\/0x10
\n ? __pfx_lock_sock_nested+0x10\/0x10
\n ? __pfx___tcp_read_sock+0x10\/0x10
\n nvme_tcp_try_recv+0x152\/0x1e0
\n ? __pfx_nvme_tcp_try_recv+0x10\/0x10
\n ? __pfx_mutex_unlock+0x10\/0x10
\n nvme_tcp_io_work+0x1e4\/0x6c0
\n ? __schedule+0x181a\/0x49f0
\n ? __pfx_nvme_tcp_io_work+0x10\/0x10
\n process_one_work+0x633\/0x1030<\/p>\n
Keep the blk_rq_payload_bytes() test and add req->data_len to it. The
\nold test is what rejects a C2HData naming a tag that is no longer in
\nflight, because blk_update_request() zeroes rq->__data_len on
\ncompletion; req->data_len and req->curr_bio are driver-private and
\nsurvive completion, so they cannot stand in for it. Setup initialises
\nthe iterator only when both req->curr_bio and req->data_len are set, so
\nthe gate now tests the same two.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
nvme-tcp: do not accept C2HData based on blk_rq_payload_bytes() alone<\/p>\n
Commit 25e5cb780e62 (“nvme-tcp: fix possible crash in write_<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-21404","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/21404","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21404"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21404"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21404"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}