Fix NPE during public IP listing when a removed network or VPC ID is informed for associatenetworkid parameter#12372
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #12372 +/- ##
============================================
- Coverage 17.76% 17.76% -0.01%
Complexity 15861 15861
============================================
Files 5923 5923
Lines 530470 530474 +4
Branches 64823 64825 +2
============================================
- Hits 94253 94251 -2
- Misses 425673 425678 +5
- Partials 10544 10545 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@blueorangutan package |
|
@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
There was a problem hiding this comment.
Pull request overview
This PR fixes a NullPointerException that occurs when listing public IP addresses with a removed network or VPC ID as a parameter. When a User account attempts to list IPs using a removed resource ID, the database query returns null, causing an NPE during access checks.
Key Changes
- Added null checks before accessing network and VPC objects when validating access permissions
- Search criteria parameters are now conditionally set only when the associated resource exists
- Added VpcVO import to support the VPC null check logic
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16258 |
|
@erikbocks , would this also apply to version 20 and 22? (not just main?) |
|
@erikbocks as this is a bug fix, could you target 4.20? |
3e34da6 to
0d2f34a
Compare
|
@DaanHoogland @winterhazel, sure. The PR was re-targeted to the |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (associatedNetworkId != null) { | ||
| _accountMgr.checkAccess(caller, null, false, networkDao.findById(associatedNetworkId)); | ||
| sc.setParameters("associatedNetworkIdEq", associatedNetworkId); | ||
| NetworkVO associatedNetwork = networkDao.findById(associatedNetworkId); | ||
|
|
||
| if (associatedNetwork != null) { | ||
| _accountMgr.checkAccess(caller, null, false, associatedNetwork); | ||
| sc.setParameters("associatedNetworkIdEq", associatedNetworkId); | ||
| } | ||
| } | ||
|
|
||
| if (vpcId != null) { | ||
| _accountMgr.checkAccess(caller, null, false, _vpcDao.findById(vpcId)); | ||
| sc.setParameters("vpcId", vpcId); | ||
| VpcVO vpc = _vpcDao.findById(vpcId); | ||
|
|
||
| if (vpc != null) { | ||
| _accountMgr.checkAccess(caller, null, false, vpc); | ||
| sc.setParameters("vpcId", vpcId); | ||
| } | ||
| } |
There was a problem hiding this comment.
The fix addresses the NPE on lines 2584-2598, but there's a similar vulnerability later in the same method. Lines 2614-2621 also retrieve the network using findById and directly access its properties (getDataCenterId() on line 2616 and getAccountId() on line 2621) without null checks. This code path is executed when listing free IP addresses (when isAllocatedOrReserved is false and vlanType is not DirectAttached). If a removed network ID is provided, this will still result in a NullPointerException.
The same null check pattern should be applied here to prevent this additional NPE scenario.
| if (associatedNetworkId != null) { | ||
| _accountMgr.checkAccess(caller, null, false, networkDao.findById(associatedNetworkId)); | ||
| sc.setParameters("associatedNetworkIdEq", associatedNetworkId); | ||
| NetworkVO associatedNetwork = networkDao.findById(associatedNetworkId); | ||
|
|
||
| if (associatedNetwork != null) { | ||
| _accountMgr.checkAccess(caller, null, false, associatedNetwork); | ||
| sc.setParameters("associatedNetworkIdEq", associatedNetworkId); | ||
| } | ||
| } | ||
|
|
||
| if (vpcId != null) { | ||
| _accountMgr.checkAccess(caller, null, false, _vpcDao.findById(vpcId)); | ||
| sc.setParameters("vpcId", vpcId); | ||
| VpcVO vpc = _vpcDao.findById(vpcId); | ||
|
|
||
| if (vpc != null) { | ||
| _accountMgr.checkAccess(caller, null, false, vpc); | ||
| sc.setParameters("vpcId", vpcId); | ||
| } | ||
| } |
There was a problem hiding this comment.
The current fix silently ignores removed networks and VPCs by not adding them to the search criteria when they are null. However, this behavior is inconsistent with other parts of the codebase. For example, at lines 2507-2509 and 2514-2515, when an entity is not found (null), the code throws an InvalidParameterValueException with a descriptive error message.
Consider whether the API should throw an InvalidParameterValueException when a user explicitly provides an ID for a removed or non-existent network/VPC, rather than silently returning an empty result set. This would provide clearer feedback to API consumers about why their query is not returning expected results. The current behavior could be confusing - users might think there are simply no IPs associated with that network, when in reality the network itself doesn't exist or has been removed.
| if (associatedNetworkId != null) { | ||
| _accountMgr.checkAccess(caller, null, false, networkDao.findById(associatedNetworkId)); | ||
| sc.setParameters("associatedNetworkIdEq", associatedNetworkId); | ||
| NetworkVO associatedNetwork = networkDao.findById(associatedNetworkId); | ||
|
|
||
| if (associatedNetwork != null) { | ||
| _accountMgr.checkAccess(caller, null, false, associatedNetwork); | ||
| sc.setParameters("associatedNetworkIdEq", associatedNetworkId); | ||
| } | ||
| } | ||
|
|
||
| if (vpcId != null) { | ||
| _accountMgr.checkAccess(caller, null, false, _vpcDao.findById(vpcId)); | ||
| sc.setParameters("vpcId", vpcId); | ||
| VpcVO vpc = _vpcDao.findById(vpcId); | ||
|
|
||
| if (vpc != null) { | ||
| _accountMgr.checkAccess(caller, null, false, vpc); | ||
| sc.setParameters("vpcId", vpcId); | ||
| } | ||
| } |
There was a problem hiding this comment.
The fix changes the behavior of the listPublicIpAddresses API when given a removed network or VPC ID. Consider adding test cases to verify this new behavior, specifically:
- Test that no NullPointerException is thrown when a User account calls listPublicIpAddresses with a removed network ID
- Test that no NullPointerException is thrown when a User account calls listPublicIpAddresses with a removed VPC ID
- Test the expected return value when a removed entity ID is provided (currently returns empty list)
The existing tests in ManagementServerImplTest.java test the setParameters method but don't cover the access control check scenario that was causing the NPE.
|
@blueorangutan package |
|
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16709 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-15384)
|
Description
When listing public IPs associated to a network, the database query only considers records that are not marked as removed. If the ID of an removed resource is informed, a
nullvalue is returned in the database query. If the caller is aUsertype account, during the access checks the code tries to access one of the value's properties, resulting in anNullPointerException.A validation was added to this flow to prevent the property access when the resource is
null, and the listing behavior was standardized. The same validation was added to handle removed VPCs, as the same behavior was presented for them.Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
Behavior before the change
Behavior after the change
How Has This Been Tested?
First, I created an isolated network, informing a public IP address to be assigned as the network's source NAT. After that, the network was removed. Then, I authenticated with an
Usertype account in CloudMonkey and called thelistPublicIpAddressesAPI, informing the removed network's UUID as theassociatednetworkidparameter. As expected, the exception was thrown.Exception stack trace in Management Server's logs
After applying the code with my changes to my local environment, the same steps were executed, and I validated that the behavior was fixed. The same steps were reproduced for removed VPCs.
The code was also compiled with tests on Maven.