Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()<br /> <br /> Wei Chen reports a kernel bug as blew:<br /> <br /> general protection fault, probably for non-canonical address<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> ...<br /> Call Trace:<br /> <br /> __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109<br /> i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170<br /> i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297<br /> i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fd834a8bded<br /> <br /> In az6027_i2c_xfer(), if msg[i].addr is 0x99,<br /> a null-ptr-deref will caused when accessing msg[i].buf.<br /> For msg[i].len is 0 and msg[i].buf is null.<br /> <br /> Fix this by checking msg[i].len in az6027_i2c_xfer().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on destination blkaddr during recovery<br /> <br /> As Wenqing Liu reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=216456<br /> <br /> loop5: detected capacity change from 0 to 131072<br /> F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1<br /> F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0<br /> F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1<br /> F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0<br /> F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1<br /> F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0<br /> F2FS-fs (loop5): Bitmap was wrongly set, blk:5634<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198<br /> RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]<br /> Call Trace:<br /> <br /> f2fs_do_replace_block+0xa98/0x1890 [f2fs]<br /> f2fs_replace_block+0xeb/0x180 [f2fs]<br /> recover_data+0x1a69/0x6ae0 [f2fs]<br /> f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]<br /> f2fs_fill_super+0x4665/0x61e0 [f2fs]<br /> mount_bdev+0x2cf/0x3b0<br /> legacy_get_tree+0xed/0x1d0<br /> vfs_get_tree+0x81/0x2b0<br /> path_mount+0x47e/0x19d0<br /> do_mount+0xce/0xf0<br /> __x64_sys_mount+0x12c/0x1a0<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic<br /> instead of warning.<br /> <br /> The root cause is: in fuzzed image, SIT table is inconsistent with inode<br /> mapping table, result in triggering such warning during SIT table update.<br /> <br /> This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this<br /> flag, data block recovery flow can check destination blkaddr&amp;#39;s validation<br /> in SIT table, and skip f2fs_replace_block() to avoid inconsistent status.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvbdev: adopts refcnt to avoid UAF<br /> <br /> dvb_unregister_device() is known that prone to use-after-free.<br /> That is, the cleanup from dvb_unregister_device() releases the dvb_device<br /> even if there are pointers stored in file-&gt;private_data still refer to it.<br /> <br /> This patch adds a reference counter into struct dvb_device and delays its<br /> deallocation until no pointer refers to the object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: Add the missed acpi_put_table() to fix memory leak<br /> <br /> When the radeon driver reads the bios information from ACPI<br /> table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table()<br /> to release the ACPI memory after the init, so add acpi_put_table()<br /> properly to fix the memory leak.<br /> <br /> v2: fix text formatting (Alex)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: fix null pointer dereferencing in power_supply_get_battery_info<br /> <br /> when kmalloc() fail to allocate memory in kasprintf(), propname<br /> will be NULL, strcmp() called by of_get_property() will cause<br /> null pointer dereference.<br /> <br /> So return ENOMEM if kasprintf() return NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t allow journal inode to have encrypt flag<br /> <br /> Mounting a filesystem whose journal inode has the encrypt flag causes a<br /> NULL dereference in fscrypt_limit_io_blocks() when the &amp;#39;inlinecrypt&amp;#39;<br /> mount option is used.<br /> <br /> The problem is that when jbd2_journal_init_inode() calls bmap(), it<br /> eventually finds its way into ext4_iomap_begin(), which calls<br /> fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if<br /> the inode is encrypted, then its encryption key must already be set up.<br /> That&amp;#39;s not the case here, since the journal inode is never "opened" like<br /> a normal file would be. Hence the crash.<br /> <br /> A reproducer is:<br /> <br /> mkfs.ext4 -F /dev/vdb<br /> debugfs -w /dev/vdb -R "set_inode_field flags 0x80808"<br /> mount /dev/vdb /mnt -o inlinecrypt<br /> <br /> To fix this, make ext4 consider journal inodes with the encrypt flag to<br /> be invalid. (Note, maybe other flags should be rejected on the journal<br /> inode too. For now, this is just the minimal fix for the above issue.)<br /> <br /> I&amp;#39;ve marked this as fixing the commit that introduced the call to<br /> fscrypt_limit_io_blocks(), since that&amp;#39;s what made an actual crash start<br /> being possible. But this fix could be applied to any version of ext4<br /> that supports the encrypt feature.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PNP: fix name memory leak in pnp_alloc_dev()<br /> <br /> After commit 1fa5ae857bb1 ("driver core: get rid of struct device&amp;#39;s<br /> bus_id string array"), the name of device is allocated dynamically,<br /> move dev_set_name() after pnp_add_id() to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()<br /> <br /> There is a global-out-of-bounds reported by KASAN:<br /> <br /> BUG: KASAN: global-out-of-bounds in<br /> _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]<br /> Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411<br /> <br /> CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D<br /> 6.1.0-rc8+ #144 e15588508517267d37<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),<br /> Call Trace:<br /> <br /> ...<br /> kasan_report+0xbb/0x1c0<br /> _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]<br /> rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]<br /> rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]<br /> ...<br /> <br /> <br /> The root cause of the problem is that the comparison order of<br /> "prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The<br /> _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two<br /> strings from tail to head, which causes the problem. In the<br /> _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet<br /> this requirement by carefully designing the comparison order.<br /> For example, "pregulation" and "pbandwidth" are compared in order of<br /> length from small to large, first is 3 and last is 4. However, the<br /> comparison order of "prate_section" dose not obey such order requirement,<br /> therefore when "prate_section" is "HT", when comparing from tail to head,<br /> it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As<br /> mentioned above, the _rtl8812ae_eq_n_byte() has the same function as<br /> strcmp(), so just strcmp() is enough.<br /> <br /> Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.<br /> Although it can be fixed by adjusting the comparison order of<br /> "prate_section", this may cause the value of "rate_section" to not be<br /> from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver<br /> from staging to regular tree, but also added setting txpower limit<br /> function during the driver config phase, so the problem was introduced<br /> by this commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: annotate data-races around kcm-&gt;rx_wait<br /> <br /> kcm-&gt;rx_psock can be read locklessly in kcm_rfree().<br /> Annotate the read and writes accordingly.<br /> <br /> syzbot reported:<br /> <br /> BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree<br /> <br /> write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:<br /> reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]<br /> kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363<br /> __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301<br /> strp_recv+0x6d/0x80 net/strparser/strparser.c:335<br /> tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703<br /> strp_read_sock net/strparser/strparser.c:358 [inline]<br /> do_strp_work net/strparser/strparser.c:406 [inline]<br /> strp_work+0xe8/0x180 net/strparser/strparser.c:415<br /> process_one_work+0x3d3/0x720 kernel/workqueue.c:2289<br /> worker_thread+0x618/0xa70 kernel/workqueue.c:2436<br /> kthread+0x1a9/0x1e0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:<br /> kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181<br /> skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841<br /> skb_release_all net/core/skbuff.c:852 [inline]<br /> __kfree_skb net/core/skbuff.c:868 [inline]<br /> kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891<br /> kfree_skb include/linux/skbuff.h:1216 [inline]<br /> kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161<br /> ____sys_recvmsg+0x16c/0x2e0<br /> ___sys_recvmsg net/socket.c:2743 [inline]<br /> do_recvmmsg+0x2f1/0x710 net/socket.c:2837<br /> __sys_recvmmsg net/socket.c:2916 [inline]<br /> __do_sys_recvmmsg net/socket.c:2939 [inline]<br /> __se_sys_recvmmsg net/socket.c:2932 [inline]<br /> __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x01 -&gt; 0x00<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kprobes: Fix check for probe enabled in kill_kprobe()<br /> <br /> In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be<br /> called always fails. This is because before that we set the<br /> KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always<br /> false.<br /> <br /> The disarm_kprobe_ftrace() call introduced by commit:<br /> <br /> 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")<br /> <br /> to fix the NULL pointer reference problem. When the probe is enabled, if<br /> we do not disarm it, this problem still exists.<br /> <br /> Fix it by putting the probe enabled check before setting the<br /> KPROBE_FLAG_GONE flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: rtsx_pci: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and calling mmc_free_host() in the<br /> error path, beside, runtime PM also needs be disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: moxart: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and goto error path which will call<br /> mmc_free_host().