Vladimir Oltean

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A NULL pointer dereference issue exists in the Linux kernel, specifically in the `dsa port reset vlan filtering()` function. The issue arises when the `ds` iterator variable overwrites the `dp` argument, which is later used to call `dsa port vlan filtering()`. This can cause switches to dereference an invalid `dp` after leaving a VLAN-aware bridge. The issue affects switches where `vlan filtering is global=true`. **Recommendations** To resolve this issue, use a dedicated `other dp` iterator variable in the `dsa port reset vlan filtering()` function to avoid overwriting the `dp` argument. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A vulnerability has been resolved in the Linux kernel where the ENETC PF and VF drivers share a function to configure MQPRIO, but only PF can configure preemptible TCs. This is because only PF has related registers, while VF does not. As a result, VF will access an invalid pointer when trying to access a non-existent register, causing a crash issue. Some PFs, such as eno1 and eno3 on LS1028A, also do not support configuring preemptible TCs and should be prevented from accessing these unimplemented registers. **Recommendations** To resolve the issue, update to a version of the Linux kernel that includes the fix, such as version 6.6.74 or later. Additionally, consider disabling the `enetc setup tc mqprio()` function for VF drivers until a patch is available. Restrict access to the `enetc change preemptible tcs()` function for PF drivers that do not support configuring preemptible TCs, such as eno1 and eno3 on LS1028A.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: A vulnerability in the Linux kernel has been resolved, related to the allocation of vf state during PF probes. In the previous implementation, vf state is allocated memory only when VF is enabled. However, `net device ops::ndo set vf mac()` may be called before VF is enabled to configure the MAC address of VF. If this is the case, `enetc pf set vf mac()` will access `vf state`, resulting in access to a null pointer. This issue can be triggered by setting the MAC address of VF using the `ip link set` command, such as `ip link set eno0 vf 1 mac 00:0c:e7:66:77:89`. The error log shows a NULL pointer dereference at virtual address 0000000000000004. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the `qbman` component of the Linux kernel, where the `smp call function` always runs its callback in hard IRQ context, even on `PREEMPT RT`, where spinlocks can sleep. This requires the use of a raw spinlock for `cgr lock` to prevent waiting on a sleeping task. The bug was not apparent until commit `ef2a8d5478b9` ("net: dpaa: Adjust queue depth on rate change") which invokes `smp call function single` via `qman update cgr safe` every time a link goes up or down. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the iommu/arm-smmu-v3 component in the Linux kernel. It is caused by the driver calling iommu device unregister() from the shutdown path, which removes the IOMMU groups without coordination with their users. This can lead to NULL pointer dereferences in the drivers' DMA API calls. The problem is similar to the one in SMMUv2. Instead of calling the full arm smmu device remove() from arm smmu device shutdown(), the relevant function call arm smmu device disable() is used, which is more or less the reverse of arm smmu device reset(). The exploitation of this issue may allow an attacker to cause a denial of service. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The vulnerability is caused by an API design decision in the Linux kernel's net/sched component, specifically in the taprio qdisc. When attempting full offload, the taprio qdisc starts with invalid flags, which are then replaced with parsed flags from netlink. However, in the taprio destroy function, the taprio disable offload function is called based on the FULL OFFLOAD IS ENABLED macro, which performs a bitwise check on the flags. If the flags contain TAPRIO FLAGS INVALID, the macro will return true, leading to a potential kernel crash if user space forces an error between setting the flags and calling taprio enable offload. This is because drivers do not expect the offload to be disabled when it was never enabled. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A vulnerability in the Linux kernel has been resolved, related to the DSA ( Distributed Switch Architecture) probing process. The issue occurs when a multi-chip tree fails to probe, causing a panic on shutdown. This happens because the driver binds to the device successfully but does not initialize the tree, leading to NULL pointer dereferences when the shutdown method is called. The problem is solved by checking if the setup has been previously initialized for the switch being shut down. **Recommendations** For the affected Linux kernel versions, to resolve the issue, apply the provided patch that fixes the panic on shutdown by checking whether the setup has been previously initialized for the switch being shut down. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the `ocelot vlan del()` function in the Linux kernel's Microsemi network adapter driver, which is vulnerable to a use-after-free condition. This occurs because `ocelot vlan member del()` frees the `struct ocelot bridge vlan`, and if this is the same as the port's `pvid vlan`, accessing it afterwards results in accessing freed memory. This could potentially impact the confidentiality, integrity, and availability of protected information. **Recommendations** To resolve the issue, determine whether to clear `ocelot port->pvid vlan` prior to calling `ocelot vlan member del()`. As a temporary workaround, consider restricting access to the vulnerable `ocelot vlan del()` function until a patch is available. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to errors in resource management. When `mdiobus free()` is called from `devm mdiobus free()`, it will panic if the mdiobus was not previously unregistered. This can occur when the DSA master is on a bus that calls `->remove` from `->shutdown`, and there is a device link between the switch and the DSA master. The Felix VSC9959 switch, a PCI device, is affected by this issue. To resolve this, the same treatment must be applied to all DSA switch drivers, which is to either use devres for both the mdiobus allocation and registration, or don't use devres at all. **Recommendations** Replace `devm mdiobus alloc size()` with the non-devres variant, and add manual free where necessary, to ensure that devres does not free a still-registered bus. As a temporary workaround, consider disabling the `mdiobus free()` function until a patch is available. Restrict access to the vulnerable `mdiobus` module to minimize the risk of exploitation. Avoid using the `devres` parameter in the affected API endpoint until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.