Vulnerabilities

Insufficiently Protected Credentials vulnerability in Zyxel Networks WAH7601 allows Retrieve Embedded Sensitive Data.<br /> <br /> This issue affects WAH7601: through 20072026.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> time/jiffies: Register jiffies clocksource before usage<br /> <br /> Teddy reported that a XEN HVM has a long boot delay, which was bisected to<br /> the recent enhancements to the negative motion detection. It turned out<br /> that the jiffies clocksource is used in early boot before it is registered,<br /> which leaves the max_delta_raw field at zero. That causes the read out to<br /> be clamped to the max delta of 0, which means time is not making progress.<br /> <br /> Cure it by ensuring that it is initialized before its first usage in<br /> timekeeping_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/khugepaged: write all dirty file folios when collapsing<br /> <br /> [There is no upstream commit, as this code was removed by upstream<br /> commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")]<br /> <br /> As-is, khugepaged and writable-file opening exclude each other. A file<br /> cannot be open writeable and have THPs (because the filesystem is not aware<br /> of them). khugepaged will never collapse file pages for files that are<br /> opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that<br /> particular file is dropped. This is fine because nothing could&amp;#39;ve been<br /> dirtied.<br /> <br /> However, there is an edge-case: collapse_file() might not be able to<br /> coexist with concurrent writers, but it can coexist with dirty folios<br /> (from previous writers). Therefore, the following can happen:<br /> <br /> open(file, O_RDWR)<br /> write(file)<br /> close(file)<br /> madvise(file_mapping, MADV_COLLAPSE, some non-dirty range)<br /> open(file, O_RDWR)<br /> nr_thps &gt; 0<br /> truncate_inode_pages()<br /> /* THPs are cleared out, but so are the dirty folios */<br /> <br /> When this edge-case happens, there is data loss, as the dirty folios are<br /> fully discarded.<br /> <br /> Fix it by fully writing back the page cache (and waiting) when collapsing<br /> file THPs. Doing so provides the guarantee that no dirty folio will be<br /> observed while there are active THPs. To fully ensure this is safe, the<br /> invalidate_lock needs to be held while doing the writeout, so that<br /> do_dentry_open()&amp;#39;s page cache truncation excludes this write-and-wait.<br /> <br /> As a side effect, move the nr_thps counter bumping outside the i_pages<br /> lock. This is correct since the counter itself is an atomic_t and the<br /> producer consumer correctness is provided by a full memory barrier:<br /> smp_mb() in collapse_file()/memory barrier implied by full ordering in<br /> get_write_access() -&gt; atomic_inc_unless_negative().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled<br /> <br /> HCI_UART_SENDING bit in tx_state means write_work is pending and blocks<br /> queueing it again. Currently this bit is not cleared when canceling the<br /> work in hci_uart_close(), which blocks future writes when device is<br /> reopened later if write_work was pending.<br /> <br /> Fix by clearing HCI_UART_SENDING when canceling the work.<br /> <br /> Also make clearing of tx_skb safe by using disable_work_sync +<br /> enable_work instead of just cancel_work_sync. hci_uart_flush() purges<br /> the proto tx queue so we can cancel the pending write_work there,<br /> instead of doing it just in hci_uart_close(). Re-enable and possibly<br /> requeue the work after queue flush.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush()<br /> <br /> wacom_wac_queue_flush() is called via the .raw_event callback<br /> (wacom_raw_event → wacom_wac_pen_serial_enforce → wacom_wac_queue_flush).<br /> For USB HID devices, this callback is invoked from hid_irq_in(), which<br /> is a URB completion handler running in atomic context. Using GFP_KERNEL<br /> in this path can sleep, leading to a "scheduling while atomic" bug.<br /> <br /> Use GFP_ATOMIC instead. The existing code already handles allocation<br /> failure by skipping the fifo entry and continuing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: function: rndis: add length check to response query<br /> <br /> Add variable representations for BufLength and BufOffset in<br /> rndis_query_response(), and perform a length check on them.<br /> <br /> This is identical to how rndis_set_response() handles these parameters.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: core: fix uninitialized data in debugfs<br /> <br /> If *ppos is non-zero then simple_write_to_buffer() will not initialize<br /> the start of buf[]. Non zero values for *ppos aren&amp;#39;t going to work<br /> anyway. Test for them at the start of the function and return -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> debugobjects: Plug race against a concurrent OOM disable<br /> <br /> syzbot reported a puzzling splat:<br /> <br /> WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20<br /> <br /> stub_timer() is installed as timer callback function in<br /> hrtimer_fixup_assert_init(), which is invoked when<br /> debug_object_assert_init() can&amp;#39;t find a shadow object. In that case debug<br /> objects emits a warning about it before invoking the fixup.<br /> <br /> Though the provided console log lacks this warning and instead has the<br /> following a few seconds before the splat:<br /> <br /> ODEBUG: Out of memory. ODEBUG disabled<br /> <br /> So the object was looked up in debug_object_assert_init() and the lookup<br /> failed due a concurrent out of memory situation which disabled debug<br /> objects and freed the shadow objects:<br /> <br /> debug_object_assert_init()<br /> if (!debug_objects_enabled)<br /> return; obj = alloc();<br /> if (!obj) {<br /> // Out of memory<br /> debug_objects_enabled = false;<br /> free_objects();<br /> obj = lookup_or_alloc();<br /> <br /> // The lookup failed because the other side<br /> // removed the objects, so this returns<br /> // an error code as the object in question<br /> // is not statically initialized<br /> <br /> if (!IS_ERR_OR_NULL(obj))<br /> return;<br /> if (!obj) {<br /> debug_oom();<br /> return;<br /> }<br /> <br /> print(...)<br /> if (!debug_objects_enabled)<br /> return;<br /> <br /> fixup(...)<br /> <br /> The debug object splat is skipped because debug_objects_enabled is false,<br /> but the fixup callback is invoked unconditionally, which makes the timer<br /> disfunctional.<br /> <br /> This is only a problem in debug_object_assert_init() and<br /> debug_object_activate() as both have to handle statically initialized<br /> objects and therefore must handle the error pointer return case<br /> gracefully. All other places only handle the found/not found case and the<br /> NULL pointer return is a signal for OOM. Otherwise they get a valid shadow<br /> object.<br /> <br /> Plug the hole by checking whether debug objects are still enabled before<br /> invoking the print and fixup function in those two places.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: stop hardware after post-start probe failures<br /> <br /> wacom_parse_and_register() starts HID hardware before registering inputs<br /> and initializing pad LEDs/remotes. Those later steps can fail, but their<br /> error paths currently release Wacom resources without stopping the HID<br /> hardware.<br /> <br /> Route post-hid_hw_start() failures through hid_hw_stop() before<br /> releasing driver resources.<br /> <br /> This issue was identified during our ongoing static-analysis research while<br /> reviewing kernel code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vme_user: fix location monitor leak in tsi148 bridge<br /> <br /> tsi148_probe() allocates a location monitor resource and links it into<br /> tsi148_bridge-&gt;lm_resources. The probe error path frees this list, but<br /> tsi148_remove() only frees the dma, slave and master resource lists, so<br /> the location monitor resource is leaked on device unbind or module<br /> unload.<br /> <br /> Free the lm_resources list in tsi148_remove() as well, before<br /> tsi148_bridge is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix path resolution in ksmbd_vfs_kern_path_create<br /> <br /> The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the<br /> create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an<br /> absolute path with convert_to_unix_name() and resolves it from AT_FDCWD<br /> via start_creating_path(), so a ".." component is walked from the real<br /> filesystem root and escapes the export.<br /> <br /> An authenticated client races a missing path component so the rooted open<br /> lookup returns -ENOENT (taking the create branch) while the same component<br /> is present (a directory) when the create walk runs; the create then<br /> resolves ".." out of the share.<br /> <br /> Root the create walk at the share like the lookup and rename paths already<br /> are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH,<br /> &amp;share_conf-&gt;vfs_path) and create the final component with<br /> start_creating_noperm(). convert_to_unix_name() then has no callers and is<br /> removed.

URL Redirection to Untrusted Site (&amp;#39;Open Redirect&amp;#39;) vulnerability in phoenixframework phoenix_live_view allows an attacker to send a victim&amp;#39;s browser to an origin of the attacker&amp;#39;s choosing via a :to value containing ASCII tab, LF or CR.<br /> <br /> redirect/2 validates :to through the private validate_local_url!/2 in lib/phoenix_live_view.ex, which is intended to guarantee the target is a path within the application. It rejects a leading // and any backslash, but not ASCII tab, LF or CR. Browsers strip those three characters before parsing a URL, so a value such as //example.com passes validation as a path and is then resolved as the scheme-relative URL //example.com. The live navigation functions share the guard but are not affected, because the client expands their target against the current origin. push_patch/2 is also affected before 0.7.0, which is when that expansion was added.<br /> <br /> This issue affects phoenix_live_view: from 0.5.0 before 1.0.19, from 1.1.0-rc.0 before 1.1.33, and from 1.2.0-rc.0 before 1.2.9.