H A D | if_clone.c | 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure. 434dbbb3 Thu Nov 24 18:56:14 GMT 2005 Ruslan Ermilov <ru@FreeBSD.org> Fix the following bugs:
- In ifc_name2unit(), disallow leading zeroes in a unit.
Exploit: ifconfig lo01 create
- In ifc_name2unit(), properly handle overflows. Otherwise, either of two local panic()'s can occur, either because no interface with such a name could be found after it was successfully created, or because the code will bogusly assume that it's a wildcard (unit < 0 due to overflow).
Exploit: ifconfig lo<overflowed_integer> create
- Previous revision made the following sequence trigger a KASSERT() failure in queue(3):
Exploit: ifconfig lo0 destroy; ifconfig lo0 destroy
This is because IFC_IFLIST_REMOVE() is always called before ifc->ifc_destroy() has been run, not accounting for the fact that the latter can fail and leave the interface operating (like is the case for "lo0"). So we ended up calling LIST_REMOVE() twice. We cannot defer IFC_IFLIST_REMOVE() until after a call to ifc->ifc_destroy() because the ifnet may have been removed and its memory has been freed, so recover from this by re-inserting the ifnet in the cloned interfaces list if ifc->ifc_destroy() indicates a failure.
|