block: fix rq-qos breakage from skipping rq_qos_done_bio()
In the Linux kernel, the following vulnerability has been resolved:
block: fix rq-qos breakage from skipping rq_qos_done_bio()
a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't
tracked") made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set.
While this fixed a potential oops, it also broke blk-iocost by skipping the
done_bio callback for merged bios.
Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(),
rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED
distinguishing the former from the latter. rq_qos_done_bio() is not called
for bios which wenth through rq_qos_me
PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove()
In the Linux kernel, the following vulnerability has been resolved:
PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove()
When a genpd with GENPD_FLAG_IRQ_SAFE gets removed, the following
sleep-in-atomic bug will be seen, as genpd_debug_remove() will be called
with a spinlock being held.
[ 0.029183] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1460
[ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0
[ 0.029219] preempt_count: 1, expected: 0
[ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc4+ #489
[ 0.029245] Hardware name: Thunder
exec: Force single empty string when argv is empty
In the Linux kernel, the following vulnerability has been resolved:
exec: Force single empty string when argv is empty
Quoting[1] Ariadne Conill:
"In several other operating systems, it is a hard requirement that the
second argument to execve(2) be the name of a program, thus prohibiting
a scenario where argc < 1. POSIX 2017 also recommends this behaviour,
but it is not an explicit requirement[2]:
The argument arg0 should point to a filename string that is
associated with the process being started by one of the exec
functions.
...
Interestingly, Michael Kerrisk opened an issue about this in 2008[3],
but there was no consensus
brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
In the Linux kernel, the following vulnerability has been resolved:
brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path
This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that
the CLM blob is released in the device remove path.
In the Linux kernel, the following vulnerability has been resolved:
crypto: octeontx2 - remove CONFIG_DM_CRYPT check
No issues were found while using the driver with dm-crypt enabled. So
CONFIG_DM_CRYPT check in the driver can be removed.
This also fixes the NULL pointer dereference in driver release if
CONFIG_DM_CRYPT is enabled.
...
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
...
Call trace:
crypto_unregister_alg+0x68/0xfc
crypto_unregister_skciphers+0x44/0x60
otx2_cpt_crypto_exit+0x100/0x1a0
otx2_cptvf_remove+0xf8/0x200
pci_device_remove+0x3c/0xd4
__device_release_driver+0x188/0x234
devic
drm/i915/gem: add missing boundary check in vm_access
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: add missing boundary check in vm_access
A missing bounds check in vm_access() can lead to an out-of-bounds read
or write in the adjacent memory area, since the len attribute is not
validated before the memcpy later in the function, potentially hitting:
[ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000
[ 183.637934] #PF: supervisor read access in kernel mode
[ 183.637997] #PF: error_code(0x0000) - not-present page
[ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0
[ 183.638144] Oops: 0000 [#2] PREEMPT SM
crypto: hisilicon/sec - fix the aead software fallback for engine
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - fix the aead software fallback for engine
Due to the subreq pointer misuse the private context memory. The aead
soft crypto occasionally casues the OS panic as setting the 64K page.
Here is fix it.
block: don't delete queue kobject before its children
In the Linux kernel, the following vulnerability has been resolved:
block: don't delete queue kobject before its children
kobjects aren't supposed to be deleted before their child kobjects are
deleted. Apparently this is usually benign; however, a WARN will be
triggered if one of the child kobjects has a named attribute group:
sysfs group 'modes' not found for kobject 'crypto'
WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80
...
Call Trace:
sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312
__kobject_del+0x20/0x80 lib/kobject.c:611
kobject_cleanup+0xa4/0x140 lib/kobject.c:696
crypto: ccree - Fix use after free in cc_cipher_exit()
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccree - Fix use after free in cc_cipher_exit()
kfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But
ctx_p->user.key is still used in the next line, which will lead to a
use after free.
We can call kfree_sensitive() after dev_dbg() to avoid the uaf.
watch_queue: Fix NULL dereference in error cleanup
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix NULL dereference in error cleanup
In watch_queue_set_size(), the error cleanup code doesn't take account of
the fact that __free_page() can't handle a NULL pointer when trying to free
up buffer pages that did get allocated.
Fix this by only calling __free_page() on the pages actually allocated.
Without the fix, this can lead to something like the following:
BUG: KASAN: null-ptr-deref in __free_pages+0x1f/0x1b0 mm/page_alloc.c:5473
Read of size 4 at addr 0000000000000034 by task syz-executor168/3599
...
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:8
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Actually free the watch
free_watch() does everything barring actually freeing the watch object. Fix
this by adding the missing kfree.
kmemleak produces a report something like the following. Note that as an
address can be seen in the first word, the watch would appear to have gone
through call_rcu().
BUG: memory leak
unreferenced object 0xffff88810ce4a200 (size 96):
comm "syz-executor352", pid 3605, jiffies 4294947473 (age 13.720s)
hex dump (first 32 bytes):
e0 82 48 0d 81 88 ff ff 00 00 00 00 00 00 00 00 ..H.............
80 a2 e4 0c 81 88 ff f
f2fs: fix missing free nid in f2fs_handle_failed_inode
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix missing free nid in f2fs_handle_failed_inode
This patch fixes xfstests/generic/475 failure.
[ 293.680694] F2FS-fs (dm-1): May loss orphan inode, run fsck to fix.
[ 293.685358] Buffer I/O error on dev dm-1, logical block 8388592, async page read
[ 293.691527] Buffer I/O error on dev dm-1, logical block 8388592, async page read
[ 293.691764] sh (7615): drop_caches: 3
[ 293.691819] sh (7616): drop_caches: 3
[ 293.694017] Buffer I/O error on dev dm-1, logical block 1, async page read
[ 293.695659] sh (7618): drop_caches: 3
[ 293.696979] sh (7617): drop_caches
media: ti-vpe: cal: Fix a NULL pointer dereference in cal_ctx_v4l2_init_formats()
In the Linux kernel, the following vulnerability has been resolved:
media: ti-vpe: cal: Fix a NULL pointer dereference in cal_ctx_v4l2_init_formats()
In cal_ctx_v4l2_init_formats(), devm_kzalloc() is assigned to
ctx->active_fmt and there is a dereference of it after that, which could
lead to NULL pointer dereference on failure of devm_kzalloc().
Fix this bug by adding a NULL check of ctx->active_fmt.
This bug was found by a static analyzer.
Builds with 'make allyesconfig' show no new warnings, and our static
analyzer no longer warns about this code.
media: usb: go7007: s2250-board: fix leak in probe()
In the Linux kernel, the following vulnerability has been resolved:
media: usb: go7007: s2250-board: fix leak in probe()
Call i2c_unregister_device(audio) on this error path.
ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type
Accessing enums using integer would result in array out of bounds access
on platforms like aarch64 where sizeof(long) is 8 compared to enum size
which is 4 bytes.
ASoC: codecs: va-macro: fix accessing array out of bounds for enum type
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: va-macro: fix accessing array out of bounds for enum type
Accessing enums using integer would result in array out of bounds access
on platforms like aarch64 where sizeof(long) is 8 compared to enum size
which is 4 bytes.
ASoC: codecs: rx-macro: fix accessing compander for aux
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: rx-macro: fix accessing compander for aux
AUX interpolator does not have compander, so check before accessing
compander data for this.
Without this checkan array of out bounds access will be made in
comp_enabled[] array.
ASoC: codecs: wc938x: fix accessing array out of bounds for enum type
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: wc938x: fix accessing array out of bounds for enum type
Accessing enums using integer would result in array out of bounds access
on platforms like aarch64 where sizeof(long) is 8 compared to enum size
which is 4 bytes.
Fix this by using enumerated items instead of integers.
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
In the Linux kernel, the following vulnerability has been resolved:
ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction
AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:
firewire-lib: Add support for deferred transaction") while 'deferrable'
flag can be uninitialized for non-control/notify AV/C transactions.
UBSAN reports it:
kernel: ================================================================================
kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9
kernel: load of value 158 is not a valid value for type '_Bool'
kernel: CPU: 3 PID: 182227 Comm