Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi/capsule-loader: fix incorrect allocation size<br /> <br /> gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures<br /> is not enough for a 64-bit phys_addr_t:<br /> <br /> drivers/firmware/efi/capsule-loader.c: In function &amp;#39;efi_capsule_open&amp;#39;:<br /> drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size &amp;#39;4&amp;#39; for type &amp;#39;phys_addr_t&amp;#39; {aka &amp;#39;long long unsigned int&amp;#39;} with size &amp;#39;8&amp;#39; [-Werror=alloc-size]<br /> 295 | cap_info-&gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);<br /> | ^<br /> <br /> Use the correct type instead here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back<br /> <br /> In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks<br /> IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic<br /> in the function `rtnl_bridge_setlink` to enable the loop to also check<br /> the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment<br /> removed the `break` statement and led to an error logic of the flags<br /> writing back at the end of this function.<br /> <br /> if (have_flags)<br /> memcpy(nla_data(attr), &amp;flags, sizeof(flags));<br /> // attr should point to IFLA_BRIDGE_FLAGS NLA !!!<br /> <br /> Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS.<br /> However, this is not necessarily true fow now as the updated loop will let<br /> the attr point to the last NLA, even an invalid NLA which could cause<br /> overflow writes.<br /> <br /> This patch introduces a new variable `br_flag` to save the NLA pointer<br /> that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned<br /> error logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: bq27xxx-i2c: Do not free non existing IRQ<br /> <br /> The bq27xxx i2c-client may not have an IRQ, in which case<br /> client-&gt;irq will be 0. bq27xxx_battery_i2c_probe() already has<br /> an if (client-&gt;irq) check wrapping the request_threaded_irq().<br /> <br /> But bq27xxx_battery_i2c_remove() unconditionally calls<br /> free_irq(client-&gt;irq) leading to:<br /> <br /> [ 190.310742] ------------[ cut here ]------------<br /> [ 190.310843] Trying to free already-free IRQ 0<br /> [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310<br /> <br /> Followed by a backtrace when unbinding the driver. Add<br /> an if (client-&gt;irq) to bq27xxx_battery_i2c_remove() mirroring<br /> probe() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: confirm multicast packets before passing them up the stack<br /> <br /> conntrack nf_confirm logic cannot handle cloned skbs referencing<br /> the same nf_conn entry, which will happen for multicast (broadcast)<br /> frames on bridges.<br /> <br /> Example:<br /> macvlan0<br /> |<br /> br0<br /> / \<br /> ethX ethY<br /> <br /> ethX (or Y) receives a L2 multicast or broadcast packet containing<br /> an IP packet, flow is not yet in conntrack table.<br /> <br /> 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.<br /> -&gt; skb-&gt;_nfct now references a unconfirmed entry<br /> 2. skb is broad/mcast packet. bridge now passes clones out on each bridge<br /> interface.<br /> 3. skb gets passed up the stack.<br /> 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb<br /> and schedules a work queue to send them out on the lower devices.<br /> <br /> The clone skb-&gt;_nfct is not a copy, it is the same entry as the<br /> original skb. The macvlan rx handler then returns RX_HANDLER_PASS.<br /> 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.<br /> <br /> The Macvlan broadcast worker and normal confirm path will race.<br /> <br /> This race will not happen if step 2 already confirmed a clone. In that<br /> case later steps perform skb_clone() with skb-&gt;_nfct already confirmed (in<br /> hash table). This works fine.<br /> <br /> But such confirmation won&amp;#39;t happen when eb/ip/nftables rules dropped the<br /> packets before they reached the nf_confirm step in postrouting.<br /> <br /> Pablo points out that nf_conntrack_bridge doesn&amp;#39;t allow use of stateful<br /> nat, so we can safely discard the nf_conn entry and let inet call<br /> conntrack again.<br /> <br /> This doesn&amp;#39;t work for bridge netfilter: skb could have a nat<br /> transformation. Also bridge nf prevents re-invocation of inet prerouting<br /> via &amp;#39;sabotage_in&amp;#39; hook.<br /> <br /> Work around this problem by explicit confirmation of the entry at LOCAL_IN<br /> time, before upper layer has a chance to clone the unconfirmed entry.<br /> <br /> The downside is that this disables NAT and conntrack helpers.<br /> <br /> Alternative fix would be to add locking to all code parts that deal with<br /> unconfirmed packets, but even if that could be done in a sane way this<br /> opens up other problems, for example:<br /> <br /> -m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4<br /> -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5<br /> <br /> For multicast case, only one of such conflicting mappings will be<br /> created, conntrack only handles 1:1 NAT mappings.<br /> <br /> Users should set create a setup that explicitly marks such traffic<br /> NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass<br /> them, ruleset might have accept rules for untracked traffic already,<br /> so user-visible behaviour would change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: reject iftype change with mesh ID change<br /> <br /> It&amp;#39;s currently possible to change the mesh ID when the<br /> interface isn&amp;#39;t yet in mesh mode, at the same time as<br /> changing it into mesh mode. This leads to an overwrite<br /> of data in the wdev-&gt;u union for the interface type it<br /> currently has, causing cfg80211_change_iface() to do<br /> wrong things when switching.<br /> <br /> We could probably allow setting an interface to mesh<br /> while setting the mesh ID at the same time by doing a<br /> different order of operations here, but realistically<br /> there&amp;#39;s no userspace that&amp;#39;s going to do this, so just<br /> disallow changes in iftype when setting mesh ID.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup<br /> <br /> The Linked list element and pointer are not stored in the same memory as<br /> the eDMA controller register. If the doorbell register is toggled before<br /> the full write of the linked list a race condition error will occur.<br /> In remote setup we can only use a readl to the memory to assure the full<br /> write has occurred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: dw-edma: HDMA: Add sync read before starting the DMA transfer in remote setup<br /> <br /> The Linked list element and pointer are not stored in the same memory as<br /> the HDMA controller register. If the doorbell register is toggled before<br /> the full write of the linked list a race condition error will occur.<br /> In remote setup we can only use a readl to the memory to assure the full<br /> write has occurred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: keep DMA buffers required for suspend/resume<br /> <br /> Nouveau deallocates a few buffers post GPU init which are required for GPU suspend/resume to function correctly.<br /> This is likely not as big an issue on systems where the NVGPU is the only GPU, but on multi-GPU set ups it leads to a regression where the kernel module errors and results in a system-wide rendering freeze.<br /> <br /> This commit addresses that regression by moving the two buffers required for suspend and resume to be deallocated at driver unload instead of post init.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fixed overflow check in mi_enum_attr()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_flow_offload: reset dst in route object after setting up flow<br /> <br /> dst is transferred to the flow object, route object does not own it<br /> anymore. Reset dst in route object, otherwise if flow_offload_add()<br /> fails, error path releases dst twice, leading to a refcount underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix data races on remote_id<br /> <br /> Similar to the previous patch, address the data race on<br /> remote_id, adding the suitable ONCE annotations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/Kconfig.debug: TEST_IOV_ITER depends on MMU<br /> <br /> Trying to run the iov_iter unit test on a nommu system such as the qemu<br /> kc705-nommu emulation results in a crash.<br /> <br /> KTAP version 1<br /> # Subtest: iov_iter<br /> # module: kunit_iov_iter<br /> 1..9<br /> BUG: failure at mm/nommu.c:318/vmap()!<br /> Kernel panic - not syncing: BUG!<br /> <br /> The test calls vmap() directly, but vmap() is not supported on nommu<br /> systems, causing the crash. TEST_IOV_ITER therefore needs to depend on<br /> MMU.