In the Linux kernel, the following vulnerability has been resolved:
x86/ioapic: Handle allocation failures gracefully
Breno observed panics when using failslab under certain conditions during
runtime:
can not alloc irq_pin_list (-1,0,20)
Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed
panic+0x4e9/0x590
mp_irqdomain_alloc+0x9ab/0xa80
irq_domain_alloc_irqs_locked+0x25d/0x8d0
__irq_domain_alloc_irqs+0x80/0x110
mp_map_pin_to_irq+0x645/0x890
acpi_register_gsi_ioapic+0xe6/0x150
hpet_open+0x313/0x480
That's a pointless panic which is a leftover of the historic IO/APIC code
which panic'ed du
fbdev: efifb: Register sysfs groups through driver core
In the Linux kernel, the following vulnerability has been resolved:
fbdev: efifb: Register sysfs groups through driver core
The driver core can register and cleanup sysfs groups already.
Make use of that functionality to simplify the error handling and
cleanup.
Also avoid a UAF race during unregistering where the sysctl attributes
were usable after the info struct was freed.
fbdev: pxafb: Fix possible use after free in pxafb_task()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: pxafb: Fix possible use after free in pxafb_task()
In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &fbi->task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &pxafb_ops struct is capable of scheduling work.
If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi->fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of
drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream
This commit addresses a null pointer dereference issue in the
`commit_planes_for_stream` function at line 4140. The issue could occur
when `top_pipe_to_program` is null.
The fix adds a check to ensure `top_pipe_to_program` is not null before
accessing its stream_res. This prevents a null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)
drm/amd/display: Check null pointers before using dc->clk_mgr
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before using dc->clk_mgr
[WHY & HOW]
dc->clk_mgr is null checked previously in the same function, indicating
it might be null.
Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which
dereferences null "dc->clk_mgr". (The function pointer resolves to
"dcn35_apply_idle_power_optimizations".)
This fixes 1 FORWARD_NULL issue reported by Coverity.
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix uaf in dbFreeBits
[syzbot reported]
==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]
BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216
CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Call Trace:
<TASK>
__dump_s
jfs: check if leafidx greater than num leaves per dmap tree
In the Linux kernel, the following vulnerability has been resolved:
jfs: check if leafidx greater than num leaves per dmap tree
syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.
Shaggy:
Modified sanity check to apply to control pages as well as leaf pages.
jfs: Fix uninit-value access of new_ea in ea_buffer
In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix uninit-value access of new_ea in ea_buffer
syzbot reports that lzo1x_1_do_compress is using uninit-value:
=====================================================
BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178
...
Uninit was stored to memory at:
ea_put fs/jfs/xattr.c:639 [inline]
...
Local variable ea_buf created at:
__jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662
__jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934
=====================================================
The reason is ea_buf->new_ea is not initialized properl
drm/amd/display: Check stream before comparing them
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check stream before comparing them
[WHAT & HOW]
amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
necessary to check for null before dereferencing them.
This fixes 1 FORWARD_NULL issue reported by Coverity.
drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation
This commit addresses a potential index out of bounds issue in the
`cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30
color management module. The issue could occur when the index 'i'
exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, the function returns
false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/a
drm/amd/display: Fix index out of bounds in degamma hardware format translation
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in degamma hardware format translation
Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. The issue
could occur when the index 'i' exceeds the number of transfer function
points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds the function returns
false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_de
drm/amd/display: Initialize get_bytes_per_element's default to 1
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Initialize get_bytes_per_element's default to 1
Variables, used as denominators and maybe not assigned to other values,
should not be 0. bytes_per_element_y & bytes_per_element_c are
initialized by get_bytes_per_element() which should never return 0.
This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.
drm/amd/pm: ensure the fw_info is not null before using it
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: ensure the fw_info is not null before using it
This resolves the dereference null return value warning
reported by Coverity.
ext4: avoid use-after-free in ext4_ext_show_leaf()
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid use-after-free in ext4_ext_show_leaf()
In ext4_find_extent(), path may be freed by error or be reallocated, so
using a previously saved *ppath may have been freed and thus may trigger
use-after-free, as follows:
ext4_split_extent
path = *ppath;
ext4_split_extent_at(ppath)
path = ext4_find_extent(ppath)
ext4_split_extent_at(ppath)
// ext4_find_extent fails to free path
// but zeroout succeeds
ext4_ext_show_leaf(inode, path)
eh = path[depth].p_hdr
// path use-after-free !!!
Similar to ext4_split_extent_at(), we use *ppath directly as an
platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug
Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds".
kasan report:
[ 19.411889] ==================================================================
[ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]
[ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113
[ 19.417368]
[ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10
[ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Refe
ext4: fix slab-use-after-free in ext4_split_extent_at()
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix slab-use-after-free in ext4_split_extent_at()
We hit the following use-after-free:
==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
<TASK>
kasan_report+0x93/0xc0
ext4_split_extent_at+0xba8/0xcc0
ext4_split_extent.isra.0+0x18f/0x500
ext4_split_convert_extents+0x275/0x750
ext4_ext_handle_unwritten_extents+0x73e/0x1580
ext4_ext_map_bloc
ext4: aovid use-after-free in ext4_ext_insert_extent()
In the Linux kernel, the following vulnerability has been resolved:
ext4: aovid use-after-free in ext4_ext_insert_extent()
As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
cause UAF. Below is a sample trace with dummy values:
ext4_ext_insert_extent
path = *ppath = 2000
ext4_ext_create_new_leaf(ppath)
ext4_find_extent(ppath)
path = *ppath = 2000
if (depth > path[0].p_maxdepth)
kfree(path = 2000);
*ppath = path = NULL;
path = kcalloc() = 3000
*ppath = 3000;
return path;
/* here path
Alta · CVSS 7.8EPSS 0,32%Código de explotación públicoCorrección disponible
ext4: fix double brelse() the buffer of the extents path
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double brelse() the buffer of the extents path
In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:
split2 map split1
|--------|-------|--------|
ext4_ext_map_blocks
ext4_ext_handle_unwritten_extents
ext4_split_convert_extents
// path->p_depth == 0
ext4_split_extent
// 1. do split1
ext4_split_extent_at
|ext4_ext_insert_extent
| ext4_ext_create_new_leaf
| ext4_ext_grow_indepth
| le16_add
In the Linux kernel, the following vulnerability has been resolved:
ext4: update orig_path in ext4_find_extent()
In ext4_find_extent(), if the path is not big enough, we free it and set
*orig_path to NULL. But after reallocating and successfully initializing
the path, we don't update *orig_path, in which case the caller gets a
valid path but a NULL ppath, and this may cause a NULL pointer dereference
or a path memory leak. For example:
ext4_split_extent
path = *ppath = 2000
ext4_find_extent
if (depth > path[0].p_maxdepth)
kfree(path = 2000);
*orig_path = path = NULL;
path = kcalloc() = 3000
ext4_split_extent_at(
drm: omapdrm: Add missing check for alloc_ordered_workqueue
In the Linux kernel, the following vulnerability has been resolved:
drm: omapdrm: Add missing check for alloc_ordered_workqueue
As it may return NULL pointer and cause NULL pointer dereference. Add check
for the return value of alloc_ordered_workqueue.