Media · CVSS 5.5EPSS 0,21%Sin corrección publicada
nilfs2: do not write dirty data after degenerating to read-only
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: do not write dirty data after degenerating to read-only
According to syzbot's report, mark_buffer_dirty() called from
nilfs_segctor_do_construct() outputs a warning with some patterns after
nilfs2 detects metadata corruption and degrades to read-only mode.
After such read-only degeneration, page cache data may be cleared through
nilfs_clear_dirty_page() which may also clear the uptodate flag for their
buffer heads. However, even after the degeneration, log writes are still
performed by unmount processing etc., which causes mark_buffer_dirty() to
be called for buff
RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Fix potential null-ptr-deref in pass_establish()
If get_ep_from_tid() fails to lookup non-NULL value for ep, ep is
dereferenced later regardless of whether it is empty.
This patch adds a simple sanity check to fix the issue.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure
syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1],
for rcu_sync_enter() is called without rcu_sync_init() due to
hci_uart_tty_open() ignoring percpu_init_rwsem() failure.
While we are at it, fix that hci_uart_register_device() ignores
percpu_init_rwsem() failure and hci_uart_unregister_device() does not
call percpu_free_rwsem().
drm/msm/dsi: fix memory corruption with too many bridges
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting
data beyond the fixed-sized bridge array in case there are ever more
than eight bridges.
Patchwork: https://patchwork.freedesktop.org/patch/502668/
In the Linux kernel, the following vulnerability has been resolved:
fs: fix UAF/GPF bug in nilfs_mdt_destroy
In alloc_inode, inode_init_always() could return -ENOMEM if
security_inode_alloc() fails, which causes inode->i_private
uninitialized. Then nilfs_is_metadata_file_inode() returns
true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),
which frees the uninitialized inode->i_private
and leads to crashes(e.g., UAF/GPF).
Fix this by moving security_inode_alloc just prior to
this_cpu_inc(nr_inodes)
In the Linux kernel, the following vulnerability has been resolved:
powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue
When value < time_unit, the parameter of ilog2() will be zero and
the return value is -1. u64(-1) is too large for shift exponent
and then will trigger shift-out-of-bounds:
shift exponent 18446744073709551615 is too large for 32-bit type 'int'
Call Trace:
rapl_compute_time_window_core
rapl_write_data_raw
set_time_window
store_constraint_time_window_us
Media · CVSS 5.5EPSS 0,21%Sin corrección publicada
i2c: mux: reg: check return value after calling platform_get_resource()
In the Linux kernel, the following vulnerability has been resolved:
i2c: mux: reg: check return value after calling platform_get_resource()
It will cause null-ptr-deref in resource_size(), if platform_get_resource()
returns NULL, move calling resource_size() after devm_ioremap_resource() that
will check 'res' to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.
Media · CVSS 5.5EPSS 0,21%Sin corrección publicada
media: cx88: Fix a null-ptr-deref bug in buffer_prepare()
In the Linux kernel, the following vulnerability has been resolved:
media: cx88: Fix a null-ptr-deref bug in buffer_prepare()
When the driver calls cx88_risc_buffer() to prepare the buffer, the
function call may fail, resulting in a empty buffer and null-ptr-deref
later in buffer_queue().
The following log can reveal it:
[ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
[ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500
[ 41.836311] Call Trace:
[ 41.836945] __enqueue_in_driv
Media · CVSS 4.2EPSS 0,29%Sin corrección publicada
brcmfmac: return error when getting invalid max_flowrings from dongle
In the Linux kernel, the following vulnerability has been resolved:
brcmfmac: return error when getting invalid max_flowrings from dongle
When firmware hit trap at initialization, host will read abnormal
max_flowrings number from dongle, and it will cause kernel panic when
doing iowrite to initialize dongle ring.
To detect this error at early stage, we directly return error when getting
invalid max_flowrings(>256).
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably
mmc: wmt-sdmmc: fix return value check of mmc_add_host()
In the Linux kernel, the following vulnerability has been resolved:
mmc: wmt-sdmmc: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, clk_disable_unprepare() also needs be called.
netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: dccp: copy entire header to stack buffer, not just basic one
Eric Dumazet says:
nf_conntrack_dccp_packet() has an unique:
dh = skb_header_pointer(skb, dataoff, sizeof(_dh), &_dh);
And nothing more is 'pulled' from the packet, depending on the content.
dh->dccph_doff, and/or dh->dccph_x ...)
So dccp_ack_seq() is happily reading stuff past the _dh buffer.
BUG: KASAN: stack-out-of-bounds in nf_conntrack_dccp_packet+0x1134/0x11c0
Read of size 4 at addr ffff000128f66e0c by task syz-executor.2/29371
[..]
Fix this by increasing the stack buffer
Media · CVSS 5.5EPSS 0,15%Sin corrección publicada
genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
In the Linux kernel, the following vulnerability has been resolved:
genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
If ipi_send_{mask|single}() is called with an invalid interrupt number, all
the local variables there will be NULL. ipi_send_verify() which is invoked
from these functions does verify its 'data' parameter, resulting in a
kernel oops in irq_data_get_affinity_mask() as the passed NULL pointer gets
dereferenced.
Add a missing NULL pointer check in ipi_send_verify()...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
Media · CVSS 5.5EPSS 0,15%Sin corrección publicada
caif: fix memory leak in cfctrl_linkup_request()
In the Linux kernel, the following vulnerability has been resolved:
caif: fix memory leak in cfctrl_linkup_request()
When linktype is unknown or kzalloc failed in cfctrl_linkup_request(),
pkt is not released. Add release process to error path.
Media · CVSS 5.5EPSS 0,15%Sin corrección publicada
powerpc: Don't try to copy PPR for task with NULL pt_regs
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Don't try to copy PPR for task with NULL pt_regs
powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
from my (arguably very short) checking is not commonly done for other
archs. This is fine, except when PF_IO_WORKER's have been created and
the task does something that causes a coredump to be generated. Then we
get this crash:
Kernel attempted to read user page (160) - exploit attempt? (uid: 1000)
BUG: Kernel NULL pointer dereference on read at 0x00000160
Faulting instruction address: 0xc0000000000c3a60
Oops: Kernel access of bad area, s
Media · CVSS 5.5EPSS 0,15%Sin corrección publicada
drm/msm/mdp5: Don't leak some plane state
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Don't leak some plane state
Apparently no one noticed that mdp5 plane states leak like a sieve
ever since we introduced plane_state->commit refcount a few years ago
in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
early by tracking commits, v3.")
Fix it by using the right helpers.
Patchwork: https://patchwork.freedesktop.org/patch/551236/
scsi: qla2xxx: Wait for io return on terminate rport
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Wait for io return on terminate rport
System crash due to use after free.
Current code allows terminate_rport_io to exit before making
sure all IOs has returned. For FCP-2 device, IO's can hang
on in HW because driver has not tear down the session in FW at
first sign of cable pull. When dev_loss_tmo timer pops,
terminate_rport_io is called and upper layer is about to
free various resources. Terminate_rport_io trigger qla to do
the final cleanup, but the cleanup might not be fast enough where it
leave qla still holding on to the same resource.
Wait for IO's t
Media · CVSS 5.5EPSS 0,16%Sin corrección publicada
recordmcount: Fix memory leaks in the uwrite function
In the Linux kernel, the following vulnerability has been resolved:
recordmcount: Fix memory leaks in the uwrite function
Common realloc mistake: 'file_append' nulled but not freed upon failure
Media · CVSS 5.5EPSS 0,16%Sin corrección publicada
ext4: fix WARNING in mb_find_extent
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in mb_find_extent
Syzbot found the following issue:
EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!
EXT4-fs (loop0): orphan cleanup on readonly fs
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30
Modules linked in:
CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:mb_find_extent+0x8a1/0xe30 fs
fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
In the Linux kernel, the following vulnerability has been resolved:
fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
Do not assing the Linux device to struct fb_info.dev. The call to
register_framebuffer() initializes the field to the fbdev device.
Drivers should not override its value.
Fixes a bug where the driver incorrectly decreases the hardware
device's reference counter and leaks the fbdev device.
v2:
* add Fixes tag (Dan)