OESA-2024-1570

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix scsimodesense() buffer length handling

Several problems exist with scsimodesense() buffer length handling:

1) The allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255.

2) If scsimodesense() is called with len smaller than 8 with sdev->use10for_ms set, or smaller than 4 otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with these increased values, thus corrupting the memory following the buffer.

Fix these 2 problems by using putunalignedbe16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error when len is too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if the device driver did not set sdev->use10forms. In case of invalid opcode error for MODE SENSE(10), access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length overflows for the MODESENSE(10) case, check that len is smaller than 65535 bytes.

While at it, also fix the folowing:

• Use getunalignedbe16() to retrieve the mode data length and block descriptor length fields of the mode sense reply header instead of using an open coded calculation.

• Fix the kdoc dbd argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the dbd argument description was.(CVE-2021-47182)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

The pointer csdesc return from sndusbfindclock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.(CVE-2021-47211)

In the Linux kernel, the following vulnerability has been resolved:

l2tp: pass correct message length to ip6appenddata

l2tpip6sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.

To manage this, we check whether the skbuff contains data using skbqueueempty when deciding how much data to append using ip6appenddata.

However, the code which performed the calculation was incorrect:

 ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;

...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.

Add parentheses to correct the calculation in line with the original intent.(CVE-2024-26752)