In the Linux kernel, the following vulnerability has been resolved:
i2c: tegra: check msg length in SMBUS block read
For SMBUS block read, do not continue to read if the message length
passed from the device is '0' or greater than the maximum allowed bytes.
In the Linux kernel, the following vulnerability has been resolved:
Input: ims-pcu - check record size in ims_pcu_flash_firmware()
The "len" variable comes from the firmware and we generally do
trust firmware, but it's always better to double check. If the "len"
is too large it could result in memory corruption when we do
"memcpy(fragment->data, rec->data, len);"
In the Linux kernel, the following vulnerability has been resolved:
nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request
If the request being processed is not a v4 compound request, then
examining the cstate can have undefined results.
This patch adds a check that the rpc procedure being executed
(rq_procinfo) is the NFSPROC4_COMPOUND procedure.
In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: do not ping device which has failed to load firmware
Syzkaller reports [1, 2] crashes caused by an attempts to ping
the device which has failed to load firmware. Since such a device
doesn't pass 'ieee80211_register_hw()', an internal workqueue
managed by 'ieee80211_queue_work()' is not yet created and an
attempt to queue work on it causes null-ptr-deref.
[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff
[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217
In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check return result of sb_min_blocksize
Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.
Syzkaller forks multiple processes which after mounting the Squashfs
filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000).
Now if this ioctl occurs at the same time another process is in the
process of mounting a Squashfs filesystem on /dev/loop0, the failure
occurs. When this happens the following code in squashfs_fill_super()
fails.
----
msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);
msblk->devblksize_log2 = ffz(~msblk->devblksize);
----
sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.
As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2
is set to 64.
This subsequently causes the
UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36
shift exponent 64 is too large for 64-bit type 'u64' (aka
'unsigned long long')
This commit adds a check for a 0 return by sb_min_blocksize().
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: uart: Set tty->disc_data only in success path
Setting tty->disc_data before opening the NCI device means we need to
clean it up on error paths. This also opens some short window if device
starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded
(broken hardware?). Close the window by exposing tty->disc_data only on
the success path, when opening of the NCI device and try_module_get()
succeeds.
The code differs in error path in one aspect: tty->disc_data won't be
ever assigned thus NULL-ified. This however should not be relevant
difference, because of "tty->disc_data=NULL" in nci_uart_tty_open().
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath6kl: remove WARN on bad firmware input
If the firmware gives bad input, that's nothing to do with
the driver's stack at this point etc., so the WARN_ON()
doesn't add any value. Additionally, this is one of the
top syzbot reports now. Just print a message, and as an
added bonus, print the sizes too.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix another leak in the submit error path
put_unused_fd() doesn't free the installed file, if we've already done
fd_install(). So we need to also free the sync_file.
Patchwork: https://patchwork.freedesktop.org/patch/653583/
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix a fence leak in submit error path
In error paths, we could unref the submit without calling
drm_sched_entity_push_job(), so msm_job_free() will never get
called. Since drm_sched_job_cleanup() will NULL out the
s_fence, we can use that to detect this case.
Patchwork: https://patchwork.freedesktop.org/patch/653584/
In the Linux kernel, the following vulnerability has been resolved:
vsock/vmci: Clear the vmci transport packet properly when initializing it
In vmci_transport_packet_init memset the vmci_transport_packet before
populating the fields to avoid any uninitialised data being left in the
structure.