In the Linux kernel, the following vulnerability has been resolved:
kernel/resource: fix kfree() of bootmem memory again
Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem
memory"), we could get a resource allocated during boot via
alloc_resource(). And it's required to release the resource using
free_resource(). Howerver, many people use kfree directly which will
result in kernel BUG. In order to fix this without fixing every call
site, just leak a couple of bytes in such corner case.
In the Linux kernel, the following vulnerability has been resolved:
mxser: fix xmit_buf leak in activate when LSR == 0xff
When LSR is 0xff in ->activate() (rather unlike), we return an error.
Provided ->shutdown() is not called when ->activate() fails, nothing
actually frees the buffer in this case.
Fix this by properly freeing the buffer in a designated label. We jump
there also from the "!info->type" if now too.
In the Linux kernel, the following vulnerability has been resolved:
af_netlink: Fix shift out of bounds in group mask calculation
When a netlink message is received, netlink_recvmsg() fills in the address
of the sender. One of the fields is the 32-bit bitfield nl_groups, which
carries the multicast group on which the message was received. The least
significant bit corresponds to group 1, and therefore the highest group
that the field can represent is 32. Above that, the UB sanitizer flags the
out-of-bounds shift attempts.
Which bits end up being set in such case is implementation defined, but
it's either going to be a wrong non-zero value, or zero, which is at least
not misleading. Make the latter choice deterministic by always setting to 0
for higher-numbered multicast groups.
To get information about membership in groups >= 32, userspace is expected
to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO
socket option.
[0] https://lwn.net/Articles/147608/
The way to trigger this issue is e.g. through monitoring the BRVLAN group:
# bridge monitor vlan &
# ip link add name br type bridge
Which produces the following citation:
UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19
shift exponent 32 is too large for 32-bit type 'int'
In the Linux kernel, the following vulnerability has been resolved:
LSM: general protection fault in legacy_parse_param
The usual LSM hook "bail on fail" scheme doesn't work for cases where
a security module may return an error code indicating that it does not
recognize an input. In this particular case Smack sees a mount option
that it recognizes, and returns 0. A call to a BPF hook follows, which
returns -ENOPARAM, which confuses the caller because Smack has processed
its data.
The SELinux hook incorrectly returns 1 on success. There was a time
when this was correct, however the current expectation is that it
return 0 on success. This is repaired.
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe
This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid
the refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on curseg->alloc_type
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=215657
- Overview
UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image
- Reproduce
tested on kernel 5.17-rc4, 5.17-rc6
1. mkdir test_crash
2. cd test_crash
3. unzip tmp2.zip
4. mkdir mnt
5. ./single_test.sh f2fs 2
- Kernel dump
[ 46.434454] loop0: detected capacity change from 0 to 131072
[ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9
[ 46.738319] ================================================================================
[ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2
[ 46.738475] index 231 is out of range for type 'unsigned int [2]'
[ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1
[ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[ 46.738551] Call Trace:
[ 46.738556] <TASK>
[ 46.738563] dump_stack_lvl+0x47/0x5c
[ 46.738581] ubsan_epilogue+0x5/0x50
[ 46.738592] __ubsan_handle_out_of_bounds+0x68/0x80
[ 46.738604] f2fs_allocate_data_block+0xdff/0xe60 [f2fs]
[ 46.738819] do_write_page+0xef/0x210 [f2fs]
[ 46.738934] f2fs_do_write_node_page+0x3f/0x80 [f2fs]
[ 46.739038] __write_node_page+0x2b7/0x920 [f2fs]
[ 46.739162] f2fs_sync_node_pages+0x943/0xb00 [f2fs]
[ 46.739293] f2fs_write_checkpoint+0x7bb/0x1030 [f2fs]
[ 46.739405] kill_f2fs_super+0x125/0x150 [f2fs]
[ 46.739507] deactivate_locked_super+0x60/0xc0
[ 46.739517] deactivate_super+0x70/0xb0
[ 46.739524] cleanup_mnt+0x11a/0x200
[ 46.739532] __cleanup_mnt+0x16/0x20
[ 46.739538] task_work_run+0x67/0xa0
[ 46.739547] exit_to_user_mode_prepare+0x18c/0x1a0
[ 46.739559] syscall_exit_to_user_mode+0x26/0x40
[ 46.739568] do_syscall_64+0x46/0xb0
[ 46.739584] entry_SYSCALL_64_after_hwframe+0x44/0xae
The root cause is we missed to do sanity check on curseg->alloc_type,
result in out-of-bound accessing on sbi->block_count[] array, fix it.
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't BUG if someone dirty pages without asking ext4 first
[un]pin_user_pages_remote is dirtying pages without properly warning
the file system in advance. A related race was noted by Jan Kara in
2018[1]; however, more recently instead of it being a very hard-to-hit
race, it could be reliably triggered by process_vm_writev(2) which was
discovered by Syzbot[2].
This is technically a bug in mm/gup.c, but arguably ext4 is fragile in
that if some other kernel subsystem dirty pages without properly
notifying the file system using page_mkwrite(), ext4 will BUG, while
other file systems will not BUG (although data will still be lost).
So instead of crashing with a BUG, issue a warning (since there may be
potential data loss) and just mark the page as clean to avoid
unprivileged denial of service attacks until the problem can be
properly fixed. More discussion and background can be found in the
thread starting at [2].
[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz
[2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com