CVE-2026-72083

CVE CVE-2026-72083EUVD EUVD-2026-59041Published 2026-08-15T05:52:32.000ZLast changed 2026-08-17T05:40:05.000ZCVSS 9.8

What the advisory describes

In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing "if (buf) transport_kunmap_data_sg(cmd)" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 4949314c7283ea4f9ade182ca599583b89f7edd6 <9f8076cc73dfa6b10155978c160587e986b22169; d2227f84ba0e97906153ac83db13213fb2e3938d; 4949314c7283ea4f9ade182ca599583b89f7edd6 <ef2ee18fec92088c7d8877baf7674e89389ccd66; patch: 0; 4949314c7283ea4f9ade182ca599583b89f7edd6 <59a2a5a37dc49a641ad6bc64aee34e5a61025ffd; patch: 6.18.40; 4949314c7283ea4f9ade182ca599583b89f7edd6 <a040004846f1fbe687f6ec76d9ccc27b4ead42e4; 4949314c7283ea4f9ade182ca599583b89f7edd6 <7d56f5c868d92c9d504a34a3ea450bce481c7f63; patch: 7.1.5; 4949314c7283ea4f9ade182ca599583b89f7edd6 <cb7bdae7fba404852ade34b0c1445fbaf3e54fbb; patch: 6.12.97; patch: 6.1.178; patch: 7.2; patch: 6.6.145; 3.3; patch: 5.10.261; patch: 5.15.212; 4949314c7283ea4f9ade182ca599583b89f7edd6 <fda6a1f3c3d7047b5ce5654487649c2daa738bfc; 3.2.9 <3.3; 4949314c7283ea4f9ade182ca599583b89f7edd6 <05b3e37433cf2eaf8867f1c16528aa347bb212ab

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.