linux-kernel - Re: memcpy: detected field-spanning write (size 128) of single field "&r1_cmd->io_request->SGL" at drivers/scsi/megaraid/megaraid_sas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 9 Jun 2023 22:54:14 +0200
From:   Frank Reppin <frank@...ermydesk.org>
To:     Holger Kiehl <Holger.Kiehl@....de>,
        Kashyap Desai <kashyap.desai@...adcom.com>,
        Sumit Saxena <sumit.saxena@...adcom.com>,
        Shivasharan S <shivasharan.srikanteshwara@...adcom.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        megaraidlinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: memcpy: detected field-spanning write (size 128) of single field
 "&r1_cmd->io_request->SGL" at
 drivers/scsi/megaraid/megaraid_sas_fusion.c:3326 (size 16)

Dear all,

at first - my apologies to bring this up again here.

But may I please ask/request to have this fix committed
to longterm 6.1 too?

Reason: Upcoming Debian Bookworm (currently RC4) comes with 6.1 but
does not include this fix yet - as it is only present in 6.3. - and
probably nobody noticed this one yet.

We do encounter this issue on brand new test machines (which should go
live once Bookworm is released) and this is a real showstopper
when it comes to show logs to QA audit people... ;)

Another reason: I see vanished /dev/disk/by-uuid/ entries when
this issue hits us

For example...

cryptsetup -v -y luksFormat 
/dev/disk/by-uuid/926943a2-8e40-445f-aad4-2ee96807cd32
-> this command should succeed - but returns with error because
somehow this (some seconds earlier perfectly valid and existing)
by-uuid entry vanished during the issue.
Other entries pointing to the same virtual drive are not affected.
(by-id,by-path,by-diskseq)

Last but not least... is this really a warning only?!
While I don't think that something on our brand new servers is broken
(it affects all btw - same observation as Holger mentioned here earlier)
it is really disturbing to see vanishing /dev/disk/by-uuid/ entries
since they might be used somewhere else and their sudden disappearance
might cause severe havoc for other daemons looking for them (server 
monitoring comes to mind ... nagios... zabbix)

Thankyou all!
cheers
Frank Reppin

-- 
43rd Law of Computing:
         Anything that can go wr
fortune: Segmentation violation -- Core dumped