Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix error handling in iavf_init_module()<br /> <br /> The iavf_init_module() won&amp;#39;t destroy workqueue when pci_register_driver()<br /> failed. Call destroy_workqueue() when pci_register_driver() failed to<br /> prevent the resource leak.<br /> <br /> Similar to the handling of u132_hcd_init in commit f276e002793c<br /> ("usb: u132-hcd: fix resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: Fix resource leak in ixgbevf_init_module()<br /> <br /> ixgbevf_init_module() won&amp;#39;t destroy the workqueue created by<br /> create_singlethread_workqueue() when pci_register_driver() failed. Add<br /> destroy_workqueue() in fail path to prevent the resource leak.<br /> <br /> Similar to the handling of u132_hcd_init in commit f276e002793c<br /> ("usb: u132-hcd: fix resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails<br /> <br /> Smatch report warning as follows:<br /> <br /> drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:<br /> &amp;#39;&amp;data-&gt;list&amp;#39; not removed from list<br /> <br /> If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will<br /> be freed, but data-&gt;list will not be removed from driver_data.bmc_data,<br /> then list traversal may cause UAF.<br /> <br /> Fix by removeing it from driver_data.bmc_data before free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libbpf: Handle size overflow for ringbuf mmap<br /> <br /> The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries<br /> will overflow u32 when mapping producer page and data pages. Only<br /> casting max_entries to size_t is not enough, because for 32-bits<br /> application on 64-bits kernel the size of read-only mmap region<br /> also could overflow size_t.<br /> <br /> So fixing it by casting the size of read-only mmap region into a __u64<br /> and checking whether or not there will be overflow during mmap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: health: afe4403: Fix oob read in afe4403_read_raw<br /> <br /> KASAN report out-of-bounds read as follows:<br /> <br /> BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0<br /> Read of size 4 at addr ffffffffc02ac638 by task cat/279<br /> <br /> Call Trace:<br /> afe4403_read_raw<br /> iio_read_channel_info<br /> dev_attr_show<br /> <br /> The buggy address belongs to the variable:<br /> afe4403_channel_leds+0x18/0xffffffffffffe9e0<br /> <br /> This issue can be reproduced by singe command:<br /> <br /> $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw<br /> <br /> The array size of afe4403_channel_leds is less than channels, so access<br /> with chan-&gt;address cause OOB read in afe4403_read_raw. Fix it by moving<br /> access before use it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw<br /> <br /> KASAN report out-of-bounds read as follows:<br /> <br /> BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380<br /> Read of size 4 at addr ffffffffc00e4658 by task cat/278<br /> <br /> Call Trace:<br /> afe4404_read_raw<br /> iio_read_channel_info<br /> dev_attr_show<br /> <br /> The buggy address belongs to the variable:<br /> afe4404_channel_leds+0x18/0xffffffffffffe9c0<br /> <br /> This issue can be reproduce by singe command:<br /> <br /> $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw<br /> <br /> The array size of afe4404_channel_leds and afe4404_channel_offdacs<br /> are less than channels, so access with chan-&gt;address cause OOB read<br /> in afe4404_[read|write]_raw. Fix it by moving access before use them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()<br /> <br /> Syzkaller reported BUG as follows:<br /> <br /> BUG: sleeping function called from invalid context at<br /> include/linux/sched/mm.h:274<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xcd/0x134<br /> __might_resched.cold+0x222/0x26b<br /> kmem_cache_alloc+0x2e7/0x3c0<br /> update_qgroup_limit_item+0xe1/0x390<br /> btrfs_qgroup_inherit+0x147b/0x1ee0<br /> create_subvol+0x4eb/0x1710<br /> btrfs_mksubvol+0xfe5/0x13f0<br /> __btrfs_ioctl_snap_create+0x2b0/0x430<br /> btrfs_ioctl_snap_create_v2+0x25a/0x520<br /> btrfs_ioctl+0x2a1c/0x5ce0<br /> __x64_sys_ioctl+0x193/0x200<br /> do_syscall_64+0x35/0x80<br /> <br /> Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in<br /> btrfs_run_qgroups() later outside of the spinlock context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: ops: Fix bounds check for _sx controls<br /> <br /> For _sx controls the semantics of the max field is not the usual one, max<br /> is the number of steps rather than the maximum value. This means that our<br /> check in snd_soc_put_volsw_sx() needs to just check against the maximum<br /> value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Free buffers when a used dynamic event is removed<br /> <br /> After 65536 dynamic events have been added and removed, the "type" field<br /> of the event then uses the first type number that is available (not<br /> currently used by other events). A type number is the identifier of the<br /> binary blobs in the tracing ring buffer (known as events) to map them to<br /> logic that can parse the binary blob.<br /> <br /> The issue is that if a dynamic event (like a kprobe event) is traced and<br /> is in the ring buffer, and then that event is removed (because it is<br /> dynamic, which means it can be created and destroyed), if another dynamic<br /> event is created that has the same number that new event&amp;#39;s logic on<br /> parsing the binary blob will be used.<br /> <br /> To show how this can be an issue, the following can crash the kernel:<br /> <br /> # cd /sys/kernel/tracing<br /> # for i in `seq 65536`; do<br /> echo &amp;#39;p:kprobes/foo do_sys_openat2 $arg1:u32&amp;#39; &gt; kprobe_events<br /> # done<br /> <br /> For every iteration of the above, the writing to the kprobe_events will<br /> remove the old event and create a new one (with the same format) and<br /> increase the type number to the next available on until the type number<br /> reaches over 65535 which is the max number for the 16 bit type. After it<br /> reaches that number, the logic to allocate a new number simply looks for<br /> the next available number. When an dynamic event is removed, that number<br /> is then available to be reused by the next dynamic event created. That is,<br /> once the above reaches the max number, the number assigned to the event in<br /> that loop will remain the same.<br /> <br /> Now that means deleting one dynamic event and created another will reuse<br /> the previous events type number. This is where bad things can happen.<br /> After the above loop finishes, the kprobes/foo event which reads the<br /> do_sys_openat2 function call&amp;#39;s first parameter as an integer.<br /> <br /> # echo 1 &gt; kprobes/foo/enable<br /> # cat /etc/passwd &gt; /dev/null<br /> # cat trace<br /> cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196<br /> cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196<br /> cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196<br /> cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196<br /> # echo 0 &gt; kprobes/foo/enable<br /> <br /> Now if we delete the kprobe and create a new one that reads a string:<br /> <br /> # echo &amp;#39;p:kprobes/foo do_sys_openat2 +0($arg2):string&amp;#39; &gt; kprobe_events<br /> <br /> And now we can the trace:<br /> <br /> # cat trace<br /> sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"<br /> cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"<br /> cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"<br /> cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="���������������������������������������<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()<br /> <br /> Syzbot reported a null-ptr-deref bug:<br /> <br /> NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP<br /> frequency pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during<br /> a b-tree operation that cascadingly updates ancestor nodes of the b-tree,<br /> because nilfs_dat_commit_alloc() for a lower level block can initialize<br /> the blocknr on the same DAT entry between nilfs_dat_prepare_end() and<br /> nilfs_dat_commit_end().<br /> <br /> If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free()<br /> without valid buffer heads in req-&gt;pr_desc_bh and req-&gt;pr_bitmap_bh, and<br /> causes the NULL pointer dereference above in<br /> nilfs_palloc_commit_free_entry() function, which leads to a crash.<br /> <br /> Fix this by adding a NULL check on req-&gt;pr_desc_bh and req-&gt;pr_bitmap_bh<br /> before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().<br /> <br /> This also calls nilfs_error() in that case to notify that there is a fatal<br /> flaw in the filesystem metadata and prevent further operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: can327: can327_feed_frame_to_netdev(): fix potential skb leak when netdev is down<br /> <br /> In can327_feed_frame_to_netdev(), it did not free the skb when netdev<br /> is down, and all callers of can327_feed_frame_to_netdev() did not free<br /> allocated skb too. That would trigger skb leak.<br /> <br /> Fix it by adding kfree_skb() in can327_feed_frame_to_netdev() when netdev<br /> is down. Not tested, just compiled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (asus-ec-sensors) Add checks for devm_kcalloc<br /> <br /> As the devm_kcalloc may return NULL, the return value needs to be checked<br /> to avoid NULL poineter dereference.