Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net-shapers: don&amp;#39;t free reply skb after genlmsg_reply()<br /> <br /> genlmsg_reply() hands the reply skb to netlink, and<br /> netlink_unicast() consumes it on all return paths, whether the<br /> skb is queued successfully or freed on an error path.<br /> <br /> net_shaper_nl_get_doit() and net_shaper_nl_cap_get_doit()<br /> currently jump to free_msg after genlmsg_reply() fails and call<br /> nlmsg_free(msg), which can hit the same skb twice.<br /> <br /> Return the genlmsg_reply() error directly and keep free_msg<br /> only for pre-reply failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp3x-rt5682-max9836: Add missing error check for clock acquisition<br /> <br /> The acp3x_5682_init() function did not check the return value of<br /> clk_get(), which could lead to dereferencing error pointers in<br /> rt5682_clk_enable().<br /> <br /> Fix this by:<br /> 1. Changing clk_get() to the device-managed devm_clk_get().<br /> 2. Adding proper IS_ERR() checks for both clock acquisitions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect<br /> <br /> Remove redundant netif_napi_del() call from disconnect path.<br /> <br /> A WARN may be triggered in __netif_napi_del_locked() during USB device<br /> disconnect:<br /> <br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> <br /> This happens because netif_napi_del() is called in the disconnect path while<br /> NAPI is still enabled. However, it is not necessary to call netif_napi_del()<br /> explicitly, since unregister_netdev() will handle NAPI teardown automatically<br /> and safely. Removing the redundant call avoids triggering the warning.<br /> <br /> Full trace:<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV<br /> lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV<br /> lan78xx 1-1:1.0 enu1: Link is Down<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> Modules linked in: flexcan can_dev fuse<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT<br /> Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)<br /> Workqueue: usb_hub_wq hub_event<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __netif_napi_del_locked+0x2b4/0x350<br /> lr : __netif_napi_del_locked+0x7c/0x350<br /> sp : ffffffc085b673c0<br /> x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8<br /> x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb<br /> x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000<br /> x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000<br /> x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028<br /> x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8<br /> x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000<br /> x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001<br /> x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000<br /> Call trace:<br /> __netif_napi_del_locked+0x2b4/0x350 (P)<br /> lan78xx_disconnect+0xf4/0x360<br /> usb_unbind_interface+0x158/0x718<br /> device_remove+0x100/0x150<br /> device_release_driver_internal+0x308/0x478<br /> device_release_driver+0x1c/0x30<br /> bus_remove_device+0x1a8/0x368<br /> device_del+0x2e0/0x7b0<br /> usb_disable_device+0x244/0x540<br /> usb_disconnect+0x220/0x758<br /> hub_event+0x105c/0x35e0<br /> process_one_work+0x760/0x17b0<br /> worker_thread+0x768/0xce8<br /> kthread+0x3bc/0x690<br /> ret_from_fork+0x10/0x20<br /> irq event stamp: 211604<br /> hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98<br /> hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80<br /> softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8<br /> softirqs last disabled at (210993): [] __do_softirq+0x18/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-core: Disable LPM on ST1000DM010-2EP102<br /> <br /> According to a user report, the ST1000DM010-2EP102 has problems with LPM,<br /> causing random system freezes. The drive belongs to the same BarraCuda<br /> family as the ST2000DM008-2FR102 which has the same issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults<br /> <br /> contpte_ptep_set_access_flags() compared the gathered ptep_get() value<br /> against the requested entry to detect no-ops. ptep_get() ORs AF/dirty<br /> from all sub-PTEs in the CONT block, so a dirty sibling can make the<br /> target appear already-dirty. When the gathered value matches entry, the<br /> function returns 0 even though the target sub-PTE still has PTE_RDONLY<br /> set in hardware.<br /> <br /> For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may<br /> set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered<br /> across the CONT range. But page-table walkers that evaluate each<br /> descriptor individually (e.g. a CPU without DBM support, or an SMMU<br /> without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the<br /> unchanged target sub-PTE, causing an infinite fault loop.<br /> <br /> Gathering can therefore cause false no-ops when only a sibling has been<br /> updated:<br /> - write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared)<br /> - read faults: target still lacks PTE_AF<br /> <br /> Fix by checking each sub-PTE against the requested AF/dirty/write state<br /> (the same bits consumed by __ptep_set_access_flags()), using raw<br /> per-PTE values rather than the gathered ptep_get() view, before<br /> returning no-op. Keep using the raw target PTE for the write-bit unfold<br /> decision.<br /> <br /> Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT<br /> range may become the effective cached translation and software must<br /> maintain consistent attributes across the range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau/gsp: drop WARN_ON in ACPI probes<br /> <br /> These WARN_ONs seem to trigger a lot, and we don&amp;#39;t seem to have a<br /> plan to fix them, so just drop them, as they are most likely<br /> harmless.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: core: Avoid bitfield RMW for claim/retune flags<br /> <br /> Move claimed and retune control flags out of the bitfield word to<br /> avoid unrelated RMW side effects in asynchronous contexts.<br /> <br /> The host-&gt;claimed bit shared a word with retune flags. Writes to claimed<br /> in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite<br /> other bits when concurrent updates happen in other contexts, triggering<br /> spurious WARN_ON(!host-&gt;claimed). Convert claimed, can_retune,<br /> retune_now and retune_paused to bool to remove shared-word coupling.

A vulnerability exists in the ngx_http_scgi_module and ngx_http_uwsgi_module modules that may result in excessive memory allocation or an over-read of data. When scgi_pass or uwsgi_pass is configured, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to read the memory of the NGINX worker process or restart it.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Incorrect permission assignment vulnerabilities exist in BIG-IP and BIG-IQ TMOS Shell (tmsh) arp and ndp commands, and in BIG-IP iControl REST. These vulnerabilities may allow an authenticated attacker to view adjacent network information. <br /> <br /> <br /> <br /> Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. This vulnerability exists when the rewrite directive is followed by a rewrite, if, or set directive and an unnamed Perl-Compatible Regular Expression (PCRE) capture (for example, $1, $2) with a replacement string that includes a question mark (?). An unauthenticated attacker along with conditions beyond its control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.  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 /> ASoC: codecs: rt1011: Use component to get the dapm context in spk_mode_put<br /> <br /> The correct helper to use in rt1011_recv_spk_mode_put() to retrieve the<br /> DAPM context is snd_soc_component_to_dapm(), from kcontrol we will<br /> receive NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL<br /> <br /> Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE<br /> before enabling TRANS_DDI_FUNC_CTL.<br /> <br /> Personally I was only able to reproduce a hang (on an Dell XPS 7390<br /> 2-in-1) with an external display connected via a dock using a dodgy<br /> type-C cable that made the link training fail. After the failed<br /> link training the machine would hang. TGL seemed immune to the<br /> problem for whatever reason.<br /> <br /> BSpec does tell us to configure VRR after enabling TRANS_DDI_FUNC_CTL<br /> as well. The DMC firmware also does the VRR restore in two stages:<br /> - first stage seems to be unconditional and includes TRANS_VRR_CTL<br /> and a few other VRR registers, among other things<br /> - second stage is conditional on the DDI being enabled,<br /> and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/VMIN/FLIPLINE,<br /> among other things<br /> <br /> So let&amp;#39;s reorder the steps to match to avoid the hang, and<br /> toss in an extra WARN to make sure we don&amp;#39;t screw this up later.<br /> <br /> BSpec: 22243<br /> (cherry picked from commit 93f3a267c3dd4d811b224bb9e179a10d81456a74)