Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST<br /> <br /> If we received HCI_EV_IO_CAPA_REQUEST while<br /> HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote<br /> does support SSP since otherwise this event shouldn&amp;#39;t be generated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()<br /> <br /> It seems that if userspace provides a correct IFA_TARGET_NETNSID value<br /> but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()<br /> returns -EINVAL with an elevated "struct net" refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: Fix data-races around sysctl_net_busy_read<br /> <br /> We need to protect the reader reading the sysctl value because the<br /> value can be changed concurrently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp: take ownership of skb in mctp_local_output<br /> <br /> Currently, mctp_local_output only takes ownership of skb on success, and<br /> we may leak an skb if mctp_local_output fails in specific states; the<br /> skb ownership isn&amp;#39;t transferred until the actual output routing occurs.<br /> <br /> Instead, make mctp_local_output free the skb on all error paths up to<br /> the route action, so it always consumes the passed skb.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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.