Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver<br /> <br /> at91_adc_interrupt can call at91_adc_touch_data_handler function<br /> to start the work by schedule_work(&amp;st-&gt;touch_st.workq).<br /> <br /> If we remove the module which will call at91_adc_remove to<br /> make cleanup, it will free indio_dev through iio_device_unregister but<br /> quite a bit later. While the work mentioned above will be used. The<br /> sequence of operations that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | at91_adc_workq_handler<br /> at91_adc_remove |<br /> iio_device_unregister(indio_dev) |<br /> //free indio_dev a bit later |<br /> | iio_push_to_buffers(indio_dev)<br /> | //use indio_dev<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in at91_adc_remove.

n8n is an open source workflow automation platform. From version 1.65.0 to before 1.114.3, the use of Buffer.allocUnsafe() and Buffer.allocUnsafeSlow() in the task runner allowed untrusted code to allocate uninitialized memory. Such uninitialized buffers could contain residual data from within the same Node.js process (for example, data from prior requests, tasks, secrets, or tokens), resulting in potential information disclosure. This issue has been patched in version 1.114.3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ena: fix missing lock when update devlink params<br /> <br /> Fix assert lock warning while calling devl_param_driverinit_value_set()<br /> in ena.<br /> <br /> WARNING: net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0: kworker/0:0/9<br /> CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.19.0-rc2+ #1 PREEMPT(lazy)<br /> Hardware name: Amazon EC2 m8i-flex.4xlarge/, BIOS 1.0 10/16/2017<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:devl_assert_locked+0x62/0x90<br /> <br /> Call Trace:<br /> <br /> devl_param_driverinit_value_set+0x15/0x1c0<br /> ena_devlink_alloc+0x18c/0x220 [ena]<br /> ? __pfx_ena_devlink_alloc+0x10/0x10 [ena]<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? devm_ioremap_wc+0x9a/0xd0<br /> ena_probe+0x4d2/0x1b20 [ena]<br /> ? __lock_acquire+0x56a/0xbd0<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ? local_clock+0x15/0x30<br /> ? __lock_release.isra.0+0x1c9/0x340<br /> ? mark_held_locks+0x40/0x70<br /> ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170<br /> ? trace_hardirqs_on+0x18/0x140<br /> ? lockdep_hardirqs_on+0x8c/0x130<br /> ? __raw_spin_unlock_irqrestore+0x5d/0x80<br /> ? __raw_spin_unlock_irqrestore+0x46/0x80<br /> ? __pfx_ena_probe+0x10/0x10 [ena]<br /> ......<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: fix device mismatch in devm_kzalloc/devm_kfree<br /> <br /> Initial rss_hdr allocation uses virtio_device-&gt;device,<br /> but virtnet_set_queues() frees using net_device-&gt;device.<br /> This device mismatch causing below devres warning<br /> <br /> [ 3788.514041] ------------[ cut here ]------------<br /> [ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463<br /> [ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]<br /> [ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT<br /> [ 3788.514067] Tainted: [W]=WARN<br /> [ 3788.514069] Hardware name: Marvell CN106XX board (DT)<br /> [ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> [ 3788.514074] pc : devm_kfree+0x84/0x98<br /> [ 3788.514076] lr : devm_kfree+0x54/0x98<br /> [ 3788.514079] sp : ffff800084e2f220<br /> [ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f<br /> [ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080<br /> [ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018<br /> [ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000<br /> [ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff<br /> [ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff<br /> [ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c<br /> [ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f<br /> [ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080<br /> [ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 3788.514123] Call trace:<br /> [ 3788.514125] devm_kfree+0x84/0x98 (P)<br /> [ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]<br /> [ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]<br /> [ 3788.514139] virtio_dev_probe+0x1e0/0x338<br /> [ 3788.514144] really_probe+0xc8/0x3a0<br /> [ 3788.514149] __driver_probe_device+0x84/0x170<br /> [ 3788.514152] driver_probe_device+0x44/0x120<br /> [ 3788.514155] __device_attach_driver+0xc4/0x168<br /> [ 3788.514158] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514161] __device_attach+0xa4/0x1c0<br /> [ 3788.514164] device_initial_probe+0x1c/0x30<br /> [ 3788.514168] bus_probe_device+0xb4/0xc0<br /> [ 3788.514170] device_add+0x614/0x828<br /> [ 3788.514173] register_virtio_device+0x214/0x258<br /> [ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]<br /> [ 3788.514179] vdpa_dev_probe+0xa8/0xd8<br /> [ 3788.514183] really_probe+0xc8/0x3a0<br /> [ 3788.514186] __driver_probe_device+0x84/0x170<br /> [ 3788.514189] driver_probe_device+0x44/0x120<br /> [ 3788.514192] __device_attach_driver+0xc4/0x168<br /> [ 3788.514195] bus_for_each_drv+0x8c/0xf0<br /> [ 3788.514197] __device_attach+0xa4/0x1c0<br /> [ 3788.514200] device_initial_probe+0x1c/0x30<br /> [ 3788.514203] bus_probe_device+0xb4/0xc0<br /> [ 3788.514206] device_add+0x614/0x828<br /> [ 3788.514209] _vdpa_register_device+0x58/0x88<br /> [ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]<br /> [ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0<br /> [ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158<br /> [ 3788.514222] genl_rcv_msg+0x218/0x298<br /> [ 3788.514225] netlink_rcv_skb+0x64/0x138<br /> [ 3788.514229] genl_rcv+0x40/0x60<br /> [ 3788.514233] netlink_unicast+0x32c/0x3b0<br /> [ 3788.514237] netlink_sendmsg+0x170/0x3b8<br /> [ 3788.514241] __sys_sendto+0x12c/0x1c0<br /> [ 3788.514246] __arm64_sys_sendto+0x30/0x48<br /> [ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8<br /> [ 3788.514255] do_el0_svc+0x48/0xd0<br /> [ 3788.514259] el0_svc+0x48/0x210<br /> [ 3788.514264] el0t_64_sync_handler+0xa0/0xe8<br /> [ 3788.514268] el0t_64_sync+0x198/0x1a0<br /> [ 3788.514271] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix by using virtio_device-&gt;device consistently for<br /> allocation and deallocation

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: make calc_target() set t-&gt;paused, not just clear it<br /> <br /> Currently calc_target() clears t-&gt;paused if the request shouldn&amp;#39;t be<br /> paused anymore, but doesn&amp;#39;t ever set t-&gt;paused even though it&amp;#39;s able to<br /> determine when the request should be paused. Setting t-&gt;paused is left<br /> to __submit_request() which is fine for regular requests but doesn&amp;#39;t<br /> work for linger requests -- since __submit_request() doesn&amp;#39;t operate<br /> on linger requests, there is nowhere for lreq-&gt;t.paused to be set.<br /> One consequence of this is that watches don&amp;#39;t get reestablished on<br /> paused -&gt; unpaused transitions in cases where requests have been paused<br /> long enough for the (paused) unwatch request to time out and for the<br /> subsequent (re)watch request to enter the paused state. On top of the<br /> watch not getting reestablished, rbd_reregister_watch() gets stuck with<br /> rbd_dev-&gt;watch_mutex held:<br /> <br /> rbd_register_watch<br /> __rbd_register_watch<br /> ceph_osdc_watch<br /> linger_reg_commit_wait<br /> <br /> It&amp;#39;s waiting for lreq-&gt;reg_commit_wait to be completed, but for that to<br /> happen the respective request needs to end up on need_resend_linger list<br /> and be kicked when requests are unpaused. There is no chance for that<br /> if the request in question is never marked paused in the first place.<br /> <br /> The fact that rbd_dev-&gt;watch_mutex remains taken out forever then<br /> prevents the image from getting unmapped -- "rbd unmap" would inevitably<br /> hang in D state on an attempt to grab the mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: call skb_orphan() before skb_attempt_defer_free()<br /> <br /> Standard UDP receive path does not use skb-&gt;destructor.<br /> <br /> But skmsg layer does use it, since it calls skb_set_owner_sk_safe()<br /> from udp_read_skb().<br /> <br /> This then triggers this warning in skb_attempt_defer_free():<br /> <br /> DEBUG_NET_WARN_ON_ONCE(skb-&gt;destructor);<br /> <br /> We must call skb_orphan() to fix this issue.

A vulnerability exists in F5 BIG-IP Container Ingress Services that may allow excessive permissions to read cluster secrets.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211_hwsim: fix typo in frequency notification<br /> <br /> The NAN notification is for 5745 MHz which corresponds to channel 149<br /> and not 5475 which is not actually a valid channel. This could result in<br /> a NULL pointer dereference in cfg80211_next_nan_dw_notif.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix NULL pointer crash in bnxt_ptp_enable during error cleanup<br /> <br /> When bnxt_init_one() fails during initialization (e.g.,<br /> bnxt_init_int_mode returns -ENODEV), the error path calls<br /> bnxt_free_hwrm_resources() which destroys the DMA pool and sets<br /> bp-&gt;hwrm_dma_pool to NULL. Subsequently, bnxt_ptp_clear() is called,<br /> which invokes ptp_clock_unregister().<br /> <br /> Since commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to<br /> disable events"), ptp_clock_unregister() now calls<br /> ptp_disable_all_events(), which in turn invokes the driver&amp;#39;s .enable()<br /> callback (bnxt_ptp_enable()) to disable PTP events before completing the<br /> unregistration.<br /> <br /> bnxt_ptp_enable() attempts to send HWRM commands via bnxt_ptp_cfg_pin()<br /> and bnxt_ptp_cfg_event(), both of which call hwrm_req_init(). This<br /> function tries to allocate from bp-&gt;hwrm_dma_pool, causing a NULL<br /> pointer dereference:<br /> <br /> bnxt_en 0000:01:00.0 (unnamed net_device) (uninitialized): bnxt_init_int_mode err: ffffffed<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> Call Trace:<br /> __hwrm_req_init (drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c:72)<br /> bnxt_ptp_enable (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:323 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:517)<br /> ptp_disable_all_events (drivers/ptp/ptp_chardev.c:66)<br /> ptp_clock_unregister (drivers/ptp/ptp_clock.c:518)<br /> bnxt_ptp_clear (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:1134)<br /> bnxt_init_one (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16889)<br /> <br /> Lines are against commit f8f9c1f4d0c7 ("Linux 6.19-rc3")<br /> <br /> Fix this by clearing and unregistering ptp (bnxt_ptp_clear()) before<br /> freeing HWRM resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix aux device unplugging when rdma is not supported by vport<br /> <br /> If vport flags do not contain VIRTCHNL2_VPORT_ENABLE_RDMA, driver does not<br /> allocate vdev_info for this vport. This leads to kernel NULL pointer<br /> dereference in idpf_idc_vport_dev_down(), which references vdev_info for<br /> every vport regardless.<br /> <br /> Check, if vdev_info was ever allocated before unplugging aux device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix NULL pointer dereference in do_abort_log_replay()<br /> <br /> Coverity reported a NULL pointer dereference issue (CID 1666756) in<br /> do_abort_log_replay(). When btrfs_alloc_path() fails in<br /> replay_one_buffer(), wc-&gt;subvol_path is NULL, but btrfs_abort_log_replay()<br /> calls do_abort_log_replay() which unconditionally dereferences<br /> wc-&gt;subvol_path when attempting to print debug information. Fix this by<br /> adding a NULL check before dereferencing wc-&gt;subvol_path in<br /> do_abort_log_replay().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: hibernate: Fix crash when freeing invalid crypto compressor<br /> <br /> When crypto_alloc_acomp() fails, it returns an ERR_PTR value, not NULL.<br /> <br /> The cleanup code in save_compressed_image() and load_compressed_image()<br /> unconditionally calls crypto_free_acomp() without checking for ERR_PTR,<br /> which causes crypto_acomp_tfm() to dereference an invalid pointer and<br /> crash the kernel.<br /> <br /> This can be triggered when the compression algorithm is unavailable<br /> (e.g., CONFIG_CRYPTO_LZO not enabled).<br /> <br /> Fix by adding IS_ERR_OR_NULL() checks before calling crypto_free_acomp()<br /> and acomp_request_free(), similar to the existing kthread_stop() check.<br /> <br /> [ rjw: Added 2 empty code lines ]