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.
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
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211_hwsim: drop short frames
While technically some control frames like ACK are shorter and
end after Address 1, such frames shouldn't be forwarded through
wmediumd or similar userspace, so require the full 3-address
header to avoid accessing invalid memory if shorter frames are
passed in.
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
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)
md/raid10: fix wrong setting of max_corr_read_errors
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix wrong setting of max_corr_read_errors
There is no input check when echo md/max_read_errors and overflow might
occur. Add check of input number.
nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput
During unmount process of nilfs2, nothing holds nilfs_root structure after
nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously,
nilfs_evict_inode() could cause use-after-free read for nilfs_root if
inodes are left in "garbage_list" and released by nilfs_dispose_list at
the end of nilfs_detach_log_writer(), and this bug was fixed by commit
9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in
nilfs_evict_inode()").
However, it turned out that there is another possibility of UAF in
drm/radeon: Fix integer overflow in radeon_cs_parser_init
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: Fix integer overflow in radeon_cs_parser_init
The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later
net: fec: Better handle pm_runtime_get() failing in .remove()
In the Linux kernel, the following vulnerability has been resolved:
net: fec: Better handle pm_runtime_get() failing in .remove()
In the (unlikely) event that pm_runtime_get() (disguised as
pm_runtime_resume_and_get()) fails, the remove callback returned an
error early. The problem with this is that the driver core ignores the
error value and continues removing the device. This results in a
resource leak. Worse the devm allocated resources are freed and so if a
callback of the driver is called later the register mapping is already
gone which probably results in a crash.
rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
In the Linux kernel, the following vulnerability has been resolved:
rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
If getting an ID or setting up a work queue in rbd_dev_create() fails,
use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
is triggered in do_rbd_add(). The root cause is that the ownership of
these structures is transfered to rbd_dev prematurely and they all end
up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
returning to do_rbd_add().
Found by Linux Verification Center (linuxtesting.org) with SVACE, an
incomplete patch submitted by Natalia Petrova <n.petrova@fin
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free
Fix potential use-after-free in l2cap_le_command_rej.
net: hns: fix possible memory leak in hnae_ae_register()
In the Linux kernel, the following vulnerability has been resolved:
net: hns: fix possible memory leak in hnae_ae_register()
Inject fault while probing module, if device_register() fails,
but the refcount of kobject is not decreased to 0, the name
allocated in dev_set_name() is leaked. Fix this by calling
put_device(), so that name can be freed in callback function
kobject_cleanup().
unreferenced object 0xffff00c01aba2100 (size 128):
comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s)
hex dump (first 32 bytes):
68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!......
00 00 00 00 00 00 00 00 00 00 00 00 00
misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()
In the Linux kernel, the following vulnerability has been resolved:
misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()
If device_register() returns error in tifm_7xx1_switch_media(),
name of kobject which is allocated in dev_set_name() called in device_add()
is leaked.
Never directly free @dev after calling device_register(), even
if it returned an error! Always use put_device() to give up the
reference initialized.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: Fix a memory leak in an error handling path
If this memdup_user() call fails, the memory allocated in a previous call
a few lines above should be freed. Otherwise it leaks.
mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()
In the Linux kernel, the following vulnerability has been resolved:
mmc: rtsx_usb_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 calling mmc_free_host() in the
error path, besides, led_classdev_unregister() and pm_runtime_disable() also
need be called.
In the Linux kernel, the following vulnerability has been resolved:
ext4: init quota for 'old.inode' in 'ext4_rename'
Syzbot found the following issue:
ext4_parse_param: s_want_extra_isize=128
ext4_inode_info_init: s_want_extra_isize=32
ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828
__ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128
__ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128
ext4_xattr_block_set: inode=ffff88823869a2c8
------------[ cut here ]------------
WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xa
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix null-ptr-deref in ext4_write_info
I caught a null-ptr-deref bug as follows:
==================================================================
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339
RIP: 0010:ext4_write_info+0x53/0x1b0
[...]
Call Trace:
dquot_writeback_dquots+0x341/0x9a0
ext4_sync_fs+0x19e/0x800
__sync_filesystem+0x83/0x100
sync_filesystem+0x89/0xf0
generic_shutdown_super+0x79/0x3e0
kill_block_super+0xa1/0x110
deactivate_locked_super+0xac/0x130
deactivate_supe
rapidio: fix possible name leaks when rio_add_device() fails
In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix possible name leaks when rio_add_device() fails
Patch series "rapidio: fix three possible memory leaks".
This patchset fixes three name leaks in error handling.
- patch #1 fixes two name leaks while rio_add_device() fails.
- patch #2 fixes a name leak while rio_register_mport() fails.
This patch (of 2):
If rio_add_device() returns error, the name allocated by dev_set_name()
need be freed. It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and the
'rdev' can be freed in rio_release_d