virtualsquare / virtualsquare/vde-2
vde_switch crashes if vlan # 0 is removed
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 255
- Forks
- 45
- PR merge metrics
- No merged PRs in 30d
Description
In older versions of vde2 the following switch startup configuration worked like a charm:
vlan/create 1 # isolated w/o real network access
vlan/create 2 # access to local samba server
vlan/create 3 # bridged to hypervisor
port/setvlan 1 1
port/setvlan 2 3
port/create 3
port/setvlan 3 2
vlan/remove 0
In other words, I set up 3 new VLANs and then removed the default VLAN # 0.
I did this because this default VLAN seemed to be special in that it was exempt from VLAN filtering and could therefore see all the traffic. I considered that a security risk and therefore deleted the VLAN.
However, current versions of vde_switch crash when adding new ports after VLAN # 0 has been removed.
Core dump analysis shows the crash happens in line 170 of file src/vde_switch/port.c where the expression
ba_set(vlant[0].table,i)
is evaluated with vlant[0].table containing a null pointer.
Suggested course of action: Either the code should check whether vlant[0].table contains a null pointer and then avoid dereferencing it, or removal of VLAN # 0 should be forbidden because then there will not be a null pointer.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/vde_switch/port.c at line 170 and reproduce the startup sequence that creates VLANs, removes VLAN 0, and then adds a port. Inspect how vlant[0].table is handled after removal and determine whether the intended behavior is to guard the null pointer or reject VLAN 0 removal. Done means adding a port no longer crashes and the chosen behavior is covered by the relevant project checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100