Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: Fix spinlock race in kernel thread creation<br /> <br /> Context switching does take care to retain the correct lock owner across<br /> the switch from &amp;#39;prev&amp;#39; to &amp;#39;next&amp;#39; tasks. This does rely on interrupts<br /> remaining disabled for the entire duration of the switch.<br /> <br /> This condition is guaranteed for normal process creation and context<br /> switching between already running processes, because both &amp;#39;prev&amp;#39; and<br /> &amp;#39;next&amp;#39; already have interrupts disabled in their saved copies of the<br /> status register.<br /> <br /> The situation is different for newly created kernel threads. The status<br /> register is set to PS_S in copy_thread(), which does leave the IPL at 0.<br /> Upon restoring the &amp;#39;next&amp;#39; thread&amp;#39;s status register in switch_to() aka<br /> resume(), interrupts then become enabled prematurely. resume() then<br /> returns via ret_from_kernel_thread() and schedule_tail() where run queue<br /> lock is released (see finish_task_switch() and finish_lock_switch()).<br /> <br /> A timer interrupt calling scheduler_tick() before the lock is released<br /> in finish_task_switch() will find the lock already taken, with the<br /> current task as lock owner. This causes a spinlock recursion warning as<br /> reported by Guenter Roeck.<br /> <br /> As far as I can ascertain, this race has been opened in commit<br /> 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")<br /> but I haven&amp;#39;t done a detailed study of kernel history so it may well<br /> predate that commit.<br /> <br /> Interrupts cannot be disabled in the saved status register copy for<br /> kernel threads (init will complain about interrupts disabled when<br /> finally starting user space). Disable interrupts temporarily when<br /> switching the tasks&amp;#39; register sets in resume().<br /> <br /> Note that a simple oriw 0x700,%sr after restoring sr is not enough here<br /> - this leaves enough of a race for the &amp;#39;spinlock recursion&amp;#39; warning to<br /> still be observed.<br /> <br /> Tested on ARAnyM and qemu (Quadra 800 emulation).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openrisc: traps: Don&amp;#39;t send signals to kernel mode threads<br /> <br /> OpenRISC exception handling sends signals to user processes on floating<br /> point exceptions and trap instructions (for debugging) among others.<br /> There is a bug where the trap handling logic may send signals to kernel<br /> threads, we should not send these signals to kernel threads, if that<br /> happens we treat it as an error.<br /> <br /> This patch adds conditions to die if the kernel receives these<br /> exceptions in kernel mode code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: exit() callback is optional<br /> <br /> The exit() callback is optional and shouldn&amp;#39;t be called without checking<br /> a valid pointer first.<br /> <br /> Also, we must clear freq_table pointer even if the exit() callback isn&amp;#39;t<br /> present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: re-fix fortified-memset warning<br /> <br /> The carl9170_tx_release() function sometimes triggers a fortified-memset<br /> warning in my randconfig builds:<br /> <br /> In file included from include/linux/string.h:254,<br /> from drivers/net/wireless/ath/carl9170/tx.c:40:<br /> In function &amp;#39;fortify_memset_chk&amp;#39;,<br /> inlined from &amp;#39;carl9170_tx_release&amp;#39; at drivers/net/wireless/ath/carl9170/tx.c:283:2,<br /> inlined from &amp;#39;kref_put&amp;#39; at include/linux/kref.h:65:3,<br /> inlined from &amp;#39;carl9170_tx_put_skb&amp;#39; at drivers/net/wireless/ath/carl9170/tx.c:342:9:<br /> include/linux/fortify-string.h:493:25: error: call to &amp;#39;__write_overflow_field&amp;#39; declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]<br /> 493 | __write_overflow_field(p_size_field, size);<br /> <br /> Kees previously tried to avoid this by using memset_after(), but it seems<br /> this does not fully address the problem. I noticed that the memset_after()<br /> here is done on a different part of the union (status) than the original<br /> cast was from (rate_driver_data), which may confuse the compiler.<br /> <br /> Unfortunately, the memset_after() trick does not work on driver_rates[]<br /> because that is part of an anonymous struct, and I could not get<br /> struct_group() to do this either. Using two separate memset() calls<br /> on the two members does address the warning though.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kunit/fortify: Fix mismatched kvalloc()/vfree() usage<br /> <br /> The kv*() family of tests were accidentally freeing with vfree() instead<br /> of kvfree(). Use kvfree() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: fix invalid unregister error path<br /> <br /> The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL<br /> is not defined. In that case if seg6_hmac_init() fails, the<br /> genl_unregister_family() isn&amp;#39;t called.<br /> <br /> This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control<br /> lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible<br /> use-after-free and null-ptr-deref") replaced unregister_pernet_subsys()<br /> with genl_unregister_family() in this error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Set lower bound of start tick time<br /> <br /> Currently ALSA timer doesn&amp;#39;t have the lower limit of the start tick<br /> time, and it allows a very small size, e.g. 1 tick with 1ns resolution<br /> for hrtimer. Such a situation may lead to an unexpected RCU stall,<br /> where the callback repeatedly queuing the expire update, as reported<br /> by fuzzer.<br /> <br /> This patch introduces a sanity check of the timer start tick time, so<br /> that the system returns an error when a too small start size is set.<br /> As of this patch, the lower limit is hard-coded to 100us, which is<br /> small enough but can still work somehow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: Fix reference count leak issues of ax25_dev<br /> <br /> The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference<br /> count leak issue of the object "ax25_dev".<br /> <br /> Memory leak issue in ax25_addr_ax25dev():<br /> <br /> The reference count of the object "ax25_dev" can be increased multiple<br /> times in ax25_addr_ax25dev(). This will cause a memory leak.<br /> <br /> Memory leak issues in ax25_dev_device_down():<br /> <br /> The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and<br /> then increase the reference count when ax25_dev is added to ax25_dev_list.<br /> As a result, the reference count of ax25_dev is 2. But when the device is<br /> shutting down. The ax25_dev_device_down() drops the reference count once<br /> or twice depending on if we goto unlock_put or not, which will cause<br /> memory leak.<br /> <br /> As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer<br /> to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the<br /> issue of ax25_dev_device_down(), increase the reference count of ax25_dev<br /> once in ax25_dev_device_up() and decrease the reference count of ax25_dev<br /> after it is removed from the ax25_dev_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()<br /> <br /> pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()<br /> fails, the irq vector is not freed, which leads to a memory leak.<br /> <br /> Replace the devm_add_action with devm_add_action_or_reset to ensure<br /> the irq vector can be destroyed when it fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: refine the EOF check in blkdev_iomap_begin<br /> <br /> blkdev_iomap_begin rounds down the offset to the logical block size<br /> before stashing it in iomap-&gt;offset and checking that it still is<br /> inside the inode size.<br /> <br /> Check the i_size check to the raw pos value so that we don&amp;#39;t try a<br /> zero size write if iter-&gt;pos is unaligned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: core: Fix NULL module pointer assignment at card init<br /> <br /> The commit 81033c6b584b ("ALSA: core: Warn on empty module")<br /> introduced a WARN_ON() for a NULL module pointer passed at snd_card<br /> object creation, and it also wraps the code around it with &amp;#39;#ifdef<br /> MODULE&amp;#39;. This works in most cases, but the devils are always in<br /> details. "MODULE" is defined when the target code (i.e. the sound<br /> core) is built as a module; but this doesn&amp;#39;t mean that the caller is<br /> also built-in or not. Namely, when only the sound core is built-in<br /> (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),<br /> the passed module pointer is ignored even if it&amp;#39;s non-NULL, and<br /> card-&gt;module remains as NULL. This would result in the missing module<br /> reference up/down at the device open/close, leading to a race with the<br /> code execution after the module removal.<br /> <br /> For addressing the bug, move the assignment of card-&gt;module again out<br /> of ifdef. The WARN_ON() is still wrapped with ifdef because the<br /> module can be really NULL when all sound drivers are built-in.<br /> <br /> Note that we keep &amp;#39;ifdef MODULE&amp;#39; for WARN_ON(), otherwise it would<br /> lead to a false-positive NULL module check. Admittedly it won&amp;#39;t catch<br /> perfectly, i.e. no check is performed when CONFIG_SND=y. But, it&amp;#39;s no<br /> real problem as it&amp;#39;s only for debugging, and the condition is pretty<br /> rare.