Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer<br /> <br /> The &amp;#39;data&amp;#39; array is allocated via kmalloc() and it is used to push data<br /> to user space from a triggered buffer, but it does not set values for<br /> inactive channels, as it only uses iio_for_each_active_channel()<br /> to assign new values.<br /> <br /> Use kzalloc for the memory allocation to avoid pushing uninitialized<br /> information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: pressure: zpa2326: fix information leak in triggered buffer<br /> <br /> The &amp;#39;sample&amp;#39; local struct is used to push data to user space from a<br /> triggered buffer, but it has a hole between the temperature and the<br /> timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).<br /> This hole is never initialized.<br /> <br /> Initialize the struct to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Remove WARN_ON in functionfs_bind<br /> <br /> This commit addresses an issue related to below kernel panic where<br /> panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON<br /> in functionsfs_bind, which easily leads to the following scenarios.<br /> <br /> 1.adb_write in adbd 2. UDC write via configfs<br /> ================= =====================<br /> <br /> -&gt;usb_ffs_open_thread() -&gt;UDC write<br /> -&gt;open_functionfs() -&gt;configfs_write_iter()<br /> -&gt;adb_open() -&gt;gadget_dev_desc_UDC_store()<br /> -&gt;adb_write() -&gt;usb_gadget_register_driver_owner<br /> -&gt;driver_register()<br /> -&gt;StartMonitor() -&gt;bus_add_driver()<br /> -&gt;adb_read() -&gt;gadget_bind_driver()<br /> -&gt;configfs_composite_bind()<br /> -&gt;usb_add_function()<br /> -&gt;open_functionfs() -&gt;ffs_func_bind()<br /> -&gt;adb_open() -&gt;functionfs_bind()<br /> state !=FFS_ACTIVE&gt;<br /> <br /> The adb_open, adb_read, and adb_write operations are invoked from the<br /> daemon, but trying to bind the function is a process that is invoked by<br /> UDC write through configfs, which opens up the possibility of a race<br /> condition between the two paths. In this race scenario, the kernel panic<br /> occurs due to the WARN_ON from functionfs_bind when panic_on_warn is<br /> enabled. This commit fixes the kernel panic by removing the unnecessary<br /> WARN_ON.<br /> <br /> Kernel panic - not syncing: kernel: panic_on_warn set ...<br /> [ 14.542395] Call trace:<br /> [ 14.542464] ffs_func_bind+0x1c8/0x14a8<br /> [ 14.542468] usb_add_function+0xcc/0x1f0<br /> [ 14.542473] configfs_composite_bind+0x468/0x588<br /> [ 14.542478] gadget_bind_driver+0x108/0x27c<br /> [ 14.542483] really_probe+0x190/0x374<br /> [ 14.542488] __driver_probe_device+0xa0/0x12c<br /> [ 14.542492] driver_probe_device+0x3c/0x220<br /> [ 14.542498] __driver_attach+0x11c/0x1fc<br /> [ 14.542502] bus_for_each_dev+0x104/0x160<br /> [ 14.542506] driver_attach+0x24/0x34<br /> [ 14.542510] bus_add_driver+0x154/0x270<br /> [ 14.542514] driver_register+0x68/0x104<br /> [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4<br /> [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144<br /> [ 14.542526] configfs_write_iter+0xf0/0x138

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling<br /> <br /> Resolve kernel panic caused by improper handling of IRQs while<br /> accessing GPIO values. This is done by replacing generic_handle_irq with<br /> handle_nested_irq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> topology: Keep the cpumask unchanged when printing cpumap<br /> <br /> During fuzz testing, the following warning was discovered:<br /> <br /> different return values (15 and 11) from vsnprintf("%*pbl<br /> ", ...)<br /> <br /> test:keyward is WARNING in kvasprintf<br /> WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130<br /> Call Trace:<br /> kvasprintf+0x121/0x130<br /> kasprintf+0xa6/0xe0<br /> bitmap_print_to_buf+0x89/0x100<br /> core_siblings_list_read+0x7e/0xb0<br /> kernfs_file_read_iter+0x15b/0x270<br /> new_sync_read+0x153/0x260<br /> vfs_read+0x215/0x290<br /> ksys_read+0xb9/0x160<br /> do_syscall_64+0x56/0x100<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> The call trace shows that kvasprintf() reported this warning during the<br /> printing of core_siblings_list. kvasprintf() has several steps:<br /> <br /> (1) First, calculate the length of the resulting formatted string.<br /> <br /> (2) Allocate a buffer based on the returned length.<br /> <br /> (3) Then, perform the actual string formatting.<br /> <br /> (4) Check whether the lengths of the formatted strings returned in<br /> steps (1) and (2) are consistent.<br /> <br /> If the core_cpumask is modified between steps (1) and (3), the lengths<br /> obtained in these two steps may not match. Indeed our test includes cpu<br /> hotplugging, which should modify core_cpumask while printing.<br /> <br /> To fix this issue, cache the cpumask into a temporary variable before<br /> calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged<br /> during the printing process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-ads1119: fix information leak in triggered buffer<br /> <br /> The &amp;#39;scan&amp;#39; local struct is used to push data to user space from a<br /> triggered buffer, but it has a hole between the sample (unsigned int)<br /> and the timestamp. This hole is never initialized.<br /> <br /> Initialize the struct to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-ads8688: fix information leak in triggered buffer<br /> <br /> The &amp;#39;buffer&amp;#39; local array is used to push data to user space from a<br /> triggered buffer, but it does not set values for inactive channels, as<br /> it only uses iio_for_each_active_channel() to assign new values.<br /> <br /> Initialize the array to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: rockchip_saradc: fix information leak in triggered buffer<br /> <br /> The &amp;#39;data&amp;#39; local struct is used to push data to user space from a<br /> triggered buffer, but it does not set values for inactive channels, as<br /> it only uses iio_for_each_active_channel() to assign new values.<br /> <br /> Initialize the struct to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: kmx61: fix information leak in triggered buffer<br /> <br /> The &amp;#39;buffer&amp;#39; local array is used to push data to user space from a<br /> triggered buffer, but it does not set values for inactive channels, as<br /> it only uses iio_for_each_active_channel() to assign new values.<br /> <br /> Initialize the array to zero before using it to avoid pushing<br /> uninitialized information to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: at91: call input_free_device() on allocated iio_dev<br /> <br /> Current implementation of at91_ts_register() calls input_free_deivce()<br /> on st-&gt;ts_input, however, the err label can be reached before the<br /> allocated iio_dev is stored to st-&gt;ts_input. Thus call<br /> input_free_device() on input instead of st-&gt;ts_input.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: support encoding fid from inode with no alias<br /> <br /> Dmitry Safonov reported that a WARN_ON() assertion can be trigered by<br /> userspace when calling inotify_show_fdinfo() for an overlayfs watched<br /> inode, whose dentry aliases were discarded with drop_caches.<br /> <br /> The WARN_ON() assertion in inotify_show_fdinfo() was removed, because<br /> it is possible for encoding file handle to fail for other reason, but<br /> the impact of failing to encode an overlayfs file handle goes beyond<br /> this assertion.<br /> <br /> As shown in the LTP test case mentioned in the link below, failure to<br /> encode an overlayfs file handle from a non-aliased inode also leads to<br /> failure to report an fid with FAN_DELETE_SELF fanotify events.<br /> <br /> As Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails<br /> if it cannot find an alias for the inode, but this failure can be fixed.<br /> ovl_encode_fh() seldom uses the alias and in the case of non-decodable<br /> file handles, as is often the case with fanotify fid info,<br /> ovl_encode_fh() never needs to use the alias to encode a file handle.<br /> <br /> Defer finding an alias until it is actually needed so ovl_encode_fh()<br /> will not fail in the common case of FAN_DELETE_SELF fanotify events.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix kernel crash when 1588 is sent on HIP08 devices<br /> <br /> Currently, HIP08 devices does not register the ptp devices, so the<br /> hdev-&gt;ptp is NULL. But the tx process would still try to set hardware time<br /> stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.<br /> <br /> [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> ...<br /> [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]<br /> [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]<br /> [ 128.292938] sp : ffff800059b93140<br /> [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280<br /> [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080<br /> [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001<br /> [ 128.315969] x23: 0000000000000000 x22: 0000000000000194<br /> [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000<br /> [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000<br /> [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24<br /> [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000<br /> [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368<br /> [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02<br /> [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0<br /> [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000<br /> [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff<br /> [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294<br /> [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080<br /> [ 128.390626] Call trace:<br /> [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge]<br /> [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3]<br /> [ 128.405468] xmit_one.constprop.0+0xc4/0x200<br /> [ 128.410600] dev_hard_start_xmit+0x54/0xf0<br /> [ 128.415556] sch_direct_xmit+0xe8/0x634<br /> [ 128.420246] __dev_queue_xmit+0x224/0xc70<br /> [ 128.425101] dev_queue_xmit+0x1c/0x40<br /> [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch]<br /> [ 128.435409] do_output+0x60/0x17c [openvswitch]<br /> [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch]<br /> [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch]<br /> [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch]<br /> [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch]<br /> [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch]<br /> [ 128.471460] xmit_one.constprop.0+0xc4/0x200<br /> [ 128.476561] dev_hard_start_xmit+0x54/0xf0<br /> [ 128.481489] __dev_queue_xmit+0x968/0xc70<br /> [ 128.486330] dev_queue_xmit+0x1c/0x40<br /> [ 128.490856] ip_finish_output2+0x250/0x570<br /> [ 128.495810] __ip_finish_output+0x170/0x1e0<br /> [ 128.500832] ip_finish_output+0x3c/0xf0<br /> [ 128.505504] ip_output+0xbc/0x160<br /> [ 128.509654] ip_send_skb+0x58/0xd4<br /> [ 128.513892] udp_send_skb+0x12c/0x354<br /> [ 128.518387] udp_sendmsg+0x7a8/0x9c0<br /> [ 128.522793] inet_sendmsg+0x4c/0x8c<br /> [ 128.527116] __sock_sendmsg+0x48/0x80<br /> [ 128.531609] __sys_sendto+0x124/0x164<br /> [ 128.536099] __arm64_sys_sendto+0x30/0x5c<br /> [ 128.540935] invoke_syscall+0x50/0x130<br /> [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124<br /> [ 128.551205] do_el0_svc+0x34/0xdc<br /> [ 128.555347] el0_svc+0x20/0x30<br /> [ 128.559227] el0_sync_handler+0xb8/0xc0<br /> [ 128.563883] el0_sync+0x160/0x180