[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2026-63888":6},{"stargazers_count":4,"fetched_at":5},8,"2026-09-19T04:32:17.889Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":17,"related":18,"reserved_at":9,"published_at":19,"modified_at":20,"state":9,"summary":21,"references_raw":23,"kevs":30,"epss":9,"epss_history":31,"metrics":32,"affected":38},"DEBIAN-CVE-2026-63888","In the Linux kernel, the following vulnerability has been resolved:  scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()  Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"):  1) DataDigest CRC buffer overread (4 bytes past text_in).     text_in is kzalloc()'d at ALIGN(payload_length, 4).  rx_size is then    incremented by ISCSI_CRC_LEN to make room for the received DataDigest    in the iovec, but the same (now-bumped) rx_size is passed as the    buffer length to iscsit_crc_buf():         if (conn->conn_ops->DataDigest) {                ...                rx_size += ISCSI_CRC_LEN;        }        ...        if (conn->conn_ops->DataDigest) {                data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);     iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so    when DataDigest is negotiated it reads 4 bytes past the end of the    text_in allocation.  KASAN reproduces this directly on the unpatched    mainline tree as slab-out-of-bounds in crc32c() called from the Text    PDU path.  The OOB bytes feed crc32c() and are then compared against    the initiator-supplied checksum, so the value does not flow back to    the attacker, but the kernel does read past the buffer on every Text    PDU with DataDigest=CRC32C.     Fix by passing the actual padded payload length    (ALIGN(payload_length, 4)) that was used for the kzalloc().  2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest    drop.     On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler    silently drops the PDU and lets the initiator plug the CmdSN gap:                 kfree(text_in);                return 0;     cmd->text_in_ptr still points at the freed buffer.  The next Text    Request on the same ITT re-enters iscsit_setup_text_cmd(), which    unconditionally does         kfree(cmd->text_in_ptr);        cmd->text_in_ptr = NULL;     freeing the same pointer a second time.  Session teardown via    iscsit_release_cmd() has the same shape and hits the same double-free    if the connection is dropped before a second Text Request arrives.     On an unmodified mainline tree the bug-1 CRC overread fires first on    the initial valid Text Request and perturbs the subsequent state, so    #4 was isolated by building a kernel with only the bug-1 hunk of this    patch applied plus temporary printk() observability around the three    relevant kfree() sites.  The observability prints are not part of    this patch.  On that build, a three-PDU Text Request sequence after    login produces two back-to-back splats:         BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??        BUG: KASAN: double-free in iscsit_release_cmd+0x??     showing the same pointer freed in the ERL>0 drop path and again in    iscsit_setup_text_cmd() (next Text Request on the same ITT) and once    more in iscsit_release_cmd() (session teardown).  On distro kernels    with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free    becomes a remote kernel BUG(); on non-hardened kernels it corrupts    the slab freelist.     Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop    path.  With both hunks applied #4 is directly observable on the stock    tree without observability printks; fixing bug-1 alone would mask #4    less, not more, so the hunks are submitted together.  Both fixes are one-liners.  The Text PDU state machine is unchanged and the wire protocol is unaffected.",null,[],[],[],[14],{"_key":15},"CVE-2026-63888",[],[],[],"2026-07-19T16:17:05.997Z","2026-07-21T09:00:45.742350345Z",{"cisa_kev":22,"cisa_ransomware":22,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[24],{"url":25,"sources":26,"tags":28},"https://security-tracker.debian.org/tracker/CVE-2026-63888",[27],"osv_debian",[29],"Advisory",[],[],[33],{"source":27,"cvss_v2_0":9,"cvss_v3_0":9,"cvss_v3_1":34,"cvss_v4_0":9},{"baseScore":35,"baseSeverity":9,"vectorString":36,"impactScore":35,"exploitabilityScore":37},9.8,"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",10,[39],{"ecosystem":40,"name":41,"vendor":42,"product":41,"cpe_part":9,"purl_type":43,"purl_namespace":42,"purl_name":41,"source":9,"versions":44},"Debian","linux","debian","deb",[45,51,54,57],{"version":46,"is_range":47,"range_type":48,"version_start":9,"version_start_type":9,"version_end":49,"version_end_type":50,"fixed_in":9},"lt5_10_259_1",true,"ecosystem","5.10.259-1","excluding",{"version":52,"is_range":47,"range_type":48,"version_start":9,"version_start_type":9,"version_end":53,"version_end_type":50,"fixed_in":9},"lt6_1_176_1","6.1.176-1",{"version":55,"is_range":47,"range_type":48,"version_start":9,"version_start_type":9,"version_end":56,"version_end_type":50,"fixed_in":9},"lt6_12_94_1","6.12.94-1",{"version":58,"is_range":47,"range_type":48,"version_start":9,"version_start_type":9,"version_end":59,"version_end_type":50,"fixed_in":9},"lt7_0_12_1","7.0.12-1"]