Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: temperature: mlx90635: Fix ERR_PTR dereference in mlx90635_probe()<br /> <br /> When devm_regmap_init_i2c() fails, regmap_ee could be error pointer,<br /> instead of checking for IS_ERR(regmap_ee), regmap is checked which looks<br /> like a copy paste error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: fix the error condition in ethtool_get_phy_stats_ethtool()<br /> <br /> Clang static checker (scan-build) warning:<br /> net/ethtool/ioctl.c:line 2233, column 2<br /> Called function pointer is null (null dereference).<br /> <br /> Return &amp;#39;-EOPNOTSUPP&amp;#39; when &amp;#39;ops-&gt;get_ethtool_phy_stats&amp;#39; is NULL to fix<br /> this typo error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mst: fix suspicious rcu usage in br_mst_set_state<br /> <br /> I converted br_mst_set_state to RCU to avoid a vlan use-after-free<br /> but forgot to change the vlan group dereference helper. Switch to vlan<br /> group RCU deref helper to fix the suspicious rcu usage warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state<br /> <br /> Pass the already obtained vlan group pointer to br_mst_vlan_set_state()<br /> instead of dereferencing it again. Each caller has already correctly<br /> dereferenced it for their context. This change is required for the<br /> following suspicious RCU dereference fix. No functional changes<br /> intended.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dpt: Make DPT object unshrinkable<br /> <br /> In some scenarios, the DPT object gets shrunk but<br /> the actual framebuffer did not and thus its still<br /> there on the DPT&amp;#39;s vm-&gt;bound_list. Then it tries to<br /> rewrite the PTEs via a stale CPU mapping. This causes panic.<br /> <br /> [vsyrjala: Add TODO comment]<br /> (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Handle TD clearing for multiple streams case<br /> <br /> When multiple streams are in use, multiple TDs might be in flight when<br /> an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for<br /> each, to ensure everything is reset properly and the caches cleared.<br /> Change the logic so that any N&gt;1 TDs found active for different streams<br /> are deferred until after the first one is processed, calling<br /> xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to<br /> queue another command until we are done with all of them. Also change<br /> the error/"should never happen" paths to ensure we at least clear any<br /> affected TDs, even if we can&amp;#39;t issue a command to clear the hardware<br /> cache, and complain loudly with an xhci_warn() if this ever happens.<br /> <br /> This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct<br /> assumptions about number of rings per endpoint.") early on in the XHCI<br /> driver&amp;#39;s life, when stream support was first added.<br /> It was then identified but not fixed nor made into a warning in commit<br /> 674f8438c121 ("xhci: split handling halted endpoints into two steps"),<br /> which added a FIXME comment for the problem case (without materially<br /> changing the behavior as far as I can tell, though the new logic made<br /> the problem more obvious).<br /> <br /> Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some<br /> cached cancelled URBs."), it was acknowledged again.<br /> <br /> [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached<br /> cancelled URBs.") was a targeted regression fix to the previously mentioned<br /> patch. Users reported issues with usb stuck after unmounting/disconnecting<br /> UAS devices. This rolled back the TD clearing of multiple streams to its<br /> original state.]<br /> <br /> Apparently the commit author was aware of the problem (yet still chose<br /> to submit it): It was still mentioned as a FIXME, an xhci_dbg() was<br /> added to log the problem condition, and the remaining issue was mentioned<br /> in the commit description. The choice of making the log type xhci_dbg()<br /> for what is, at this point, a completely unhandled and known broken<br /> condition is puzzling and unfortunate, as it guarantees that no actual<br /> users would see the log in production, thereby making it nigh<br /> undebuggable (indeed, even if you turn on DEBUG, the message doesn&amp;#39;t<br /> really hint at there being a problem at all).<br /> <br /> It took me *months* of random xHC crashes to finally find a reliable<br /> repro and be able to do a deep dive debug session, which could all have<br /> been avoided had this unhandled, broken condition been actually reported<br /> with a warning, as it should have been as a bug intentionally left in<br /> unfixed (never mind that it shouldn&amp;#39;t have been left in at all).<br /> <br /> &gt; Another fix to solve clearing the caches of all stream rings with<br /> &gt; cancelled TDs is needed, but not as urgent.<br /> <br /> 3 years after that statement and 14 years after the original bug was<br /> introduced, I think it&amp;#39;s finally time to fix it. And maybe next time<br /> let&amp;#39;s not leave bugs unfixed (that are actually worse than the original<br /> bug), and let&amp;#39;s actually get people to review kernel commits please.<br /> <br /> Fixes xHC crashes and IOMMU faults with UAS devices when handling<br /> errors/faults. Easiest repro is to use `hdparm` to mark an early sector<br /> (e.g. 1024) on a disk as bad, then `cat /dev/sdX &gt; /dev/null` in a loop.<br /> At least in the case of JMicron controllers, the read errors end up<br /> having to cancel two TDs (for two queued requests to different streams)<br /> and the one that didn&amp;#39;t get cleared properly ends up faulting the xHC<br /> entirely when it tries to access DMA pages that have since been unmapped,<br /> referred to by the stale TDs. This normally happens quickly (after two<br /> or three loops). After this fix, I left the `cat` in a loop running<br /> overnight and experienced no xHC failures, with all read errors<br /> recovered properly. Repro&amp;#39;d and tested on an Apple M1 Mac Mini<br /> (dwc3 host).<br /> <br /> On systems without an IOMMU, this bug would instead silently corrupt<br /> freed memory, making this a<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: check n_ssids before accessing the ssids<br /> <br /> In some versions of cfg80211, the ssids poinet might be a valid one even<br /> though n_ssids is 0. Accessing the pointer in this case will cuase an<br /> out-of-bound access. Fix this by checking n_ssids first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: ensure snd_una is properly initialized on connect<br /> <br /> This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt<br /> is properly initialized on connect"). It turns out that syzkaller can<br /> trigger the retransmit after fallback and before processing any other<br /> incoming packet - so that snd_una is still left uninitialized.<br /> <br /> Address the issue explicitly initializing snd_una together with snd_nxt<br /> and write_seq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/exynos/vidi: fix memory leak in .get_modes()<br /> <br /> The duplicated EDID is never freed. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()<br /> <br /> Fix a memory leak on logi_dj_recv_send_report() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a potential use-after-free in bpf_link_free()<br /> <br /> After commit 1a80dbcb2dba, bpf_link can be freed by<br /> link-&gt;ops-&gt;dealloc_deferred, but the code still tests and uses<br /> link-&gt;ops-&gt;dealloc afterward, which leads to a use-after-free as<br /> reported by syzbot. Actually, one of them should be sufficient, so<br /> just call one of them instead of both. Also add a WARN_ON() in case<br /> of any problematic implementation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memblock: make memblock_set_node() also warn about use of MAX_NUMNODES<br /> <br /> On an (old) x86 system with SRAT just covering space above 4Gb:<br /> <br /> ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug<br /> <br /> the commit referenced below leads to this NUMA configuration no longer<br /> being refused by a CONFIG_NUMA=y kernel (previously<br /> <br /> NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used.<br /> No NUMA configuration found<br /> Faking a node at [mem 0x0000000000000000-0x000000027fffffff]<br /> <br /> was seen in the log directly after the message quoted above), because of<br /> memblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This<br /> in turn led to memblock_alloc_range_nid()&amp;#39;s warning about MAX_NUMNODES<br /> triggering, followed by a NULL deref in memmap_init() when trying to<br /> access node 64&amp;#39;s (NODE_SHIFT=6) node data.<br /> <br /> To compensate said change, make memblock_set_node() warn on and adjust<br /> a passed in value of MAX_NUMNODES, just like various other functions<br /> already do.