Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> chardev: fix error handling in cdev_device_add()<br /> <br /> While doing fault injection test, I got the following report:<br /> <br /> ------------[ cut here ]------------<br /> kobject: &amp;#39;(null)&amp;#39; (0000000039956980): is not initialized, yet kobject_put() is being called.<br /> WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0<br /> CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:kobject_put+0x23d/0x4e0<br /> Call Trace:<br /> <br /> cdev_device_add+0x15e/0x1b0<br /> __iio_device_register+0x13b4/0x1af0 [industrialio]<br /> __devm_iio_device_register+0x22/0x90 [industrialio]<br /> max517_probe+0x3d8/0x6b4 [max517]<br /> i2c_device_probe+0xa81/0xc00<br /> <br /> When device_add() is injected fault and returns error, if dev-&gt;devt is not set,<br /> cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev-&gt;devt<br /> in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()<br /> <br /> In error case in bridge_platform_create after calling<br /> platform_device_add()/platform_device_add_data()/<br /> platform_device_add_resources(), release the failed<br /> &amp;#39;pdev&amp;#39; or it will be leak, call platform_device_put()<br /> to fix this problem.<br /> <br /> Besides, &amp;#39;pdev&amp;#39; is divided into &amp;#39;pdev_wd&amp;#39; and &amp;#39;pdev_bd&amp;#39;,<br /> use platform_device_unregister() to release sgi_w1<br /> resources when xtalk-bridge registration fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pnode: terminate at peers of source<br /> <br /> The propagate_mnt() function handles mount propagation when creating<br /> mounts and propagates the source mount tree @source_mnt to all<br /> applicable nodes of the destination propagation mount tree headed by<br /> @dest_mnt.<br /> <br /> Unfortunately it contains a bug where it fails to terminate at peers of<br /> @source_mnt when looking up copies of the source mount that become<br /> masters for copies of the source mount tree mounted on top of slaves in<br /> the destination propagation tree causing a NULL dereference.<br /> <br /> Once the mechanics of the bug are understood it&amp;#39;s easy to trigger.<br /> Because of unprivileged user namespaces it is available to unprivileged<br /> users.<br /> <br /> While fixing this bug we&amp;#39;ve gotten confused multiple times due to<br /> unclear terminology or missing concepts. So let&amp;#39;s start this with some<br /> clarifications:<br /> <br /> * The terms "master" or "peer" denote a shared mount. A shared mount<br /> belongs to a peer group.<br /> <br /> * A peer group is a set of shared mounts that propagate to each other.<br /> They are identified by a peer group id. The peer group id is available<br /> in @shared_mnt-&gt;mnt_group_id.<br /> Shared mounts within the same peer group have the same peer group id.<br /> The peers in a peer group can be reached via @shared_mnt-&gt;mnt_share.<br /> <br /> * The terms "slave mount" or "dependent mount" denote a mount that<br /> receives propagation from a peer in a peer group. IOW, shared mounts<br /> may have slave mounts and slave mounts have shared mounts as their<br /> master. Slave mounts of a given peer in a peer group are listed on<br /> that peers slave list available at @shared_mnt-&gt;mnt_slave_list.<br /> <br /> * The term "master mount" denotes a mount in a peer group. IOW, it<br /> denotes a shared mount or a peer mount in a peer group. The term<br /> "master mount" - or "master" for short - is mostly used when talking<br /> in the context of slave mounts that receive propagation from a master<br /> mount. A master mount of a slave identifies the closest peer group a<br /> slave mount receives propagation from. The master mount of a slave can<br /> be identified via @slave_mount-&gt;mnt_master. Different slaves may point<br /> to different masters in the same peer group.<br /> <br /> * Multiple peers in a peer group can have non-empty -&gt;mnt_slave_lists.<br /> Non-empty -&gt;mnt_slave_lists of peers don&amp;#39;t intersect. Consequently, to<br /> ensure all slave mounts of a peer group are visited the<br /> -&gt;mnt_slave_lists of all peers in a peer group have to be walked.<br /> <br /> * Slave mounts point to a peer in the closest peer group they receive<br /> propagation from via @slave_mnt-&gt;mnt_master (see above). Together with<br /> these peers they form a propagation group (see below). The closest<br /> peer group can thus be identified through the peer group id<br /> @slave_mnt-&gt;mnt_master-&gt;mnt_group_id of the peer/master that a slave<br /> mount receives propagation from.<br /> <br /> * A shared-slave mount is a slave mount to a peer group pg1 while also<br /> a peer in another peer group pg2. IOW, a peer group may receive<br /> propagation from another peer group.<br /> <br /> If a peer group pg1 is a slave to another peer group pg2 then all<br /> peers in peer group pg1 point to the same peer in peer group pg2 via<br /> -&gt;mnt_master. IOW, all peers in peer group pg1 appear on the same<br /> -&gt;mnt_slave_list. IOW, they cannot be slaves to different peer groups.<br /> <br /> * A pure slave mount is a slave mount that is a slave to a peer group<br /> but is not a peer in another peer group.<br /> <br /> * A propagation group denotes the set of mounts consisting of a single<br /> peer group pg1 and all slave mounts and shared-slave mounts that point<br /> to a peer in that peer group via -&gt;mnt_master. IOW, all slave mounts<br /> such that @slave_mnt-&gt;mnt_master-&gt;mnt_group_id is equal to<br /> @shared_mnt-&gt;mnt_group_id.<br /> <br /> The concept of a propagation group makes it easier to talk about a<br /> single propagation level in a propagation tree.<br /> <br /> For example, in propagate_mnt() the immediate peers of @dest_mnt and<br /> all slaves of @dest_mnt&amp;#39;s peer group form a propagation group pr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: fix memory leak in init_mqueue_fs()<br /> <br /> When setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is<br /> not released. In order to fix this issue, the release path is reordered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs<br /> <br /> When (size != 0 || ptrs-&gt;lvds_ entries != 3), the program tries to<br /> free() the ptrs. However, the ptrs is not created by calling kzmalloc(),<br /> but is obtained by pointer offset operation.<br /> This may lead to memory leaks or undefined behavior.<br /> <br /> Fix this by replacing the arguments of kfree() with ptrs_block.<br /> <br /> (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec)

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 /> 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 /> 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 /> 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.