[libvirt] [PATCH] util: netdev: Don't crash in virNetDevSetIPAddress if @peer is NULL
VIR_SOCKET_ADDR_VALID dereferences the pointer, thus if we pass NULL into virNetDevSetIPAddress it crashes. Regression introduced by b3d069872ce53eb. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325120 --- src/util/virnetdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 712c3bc..0d030a3 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1129,7 +1129,7 @@ int virNetDevSetIPAddress(const char *ifname, unsigned int recvbuflen; /* The caller needs to provide a correct address */ - if (VIR_SOCKET_ADDR_FAMILY(addr) == AF_INET && !VIR_SOCKET_ADDR_VALID(peer)) { + if (VIR_SOCKET_ADDR_FAMILY(addr) == AF_INET && peer && !VIR_SOCKET_ADDR_VALID(peer)) { /* compute a broadcast address if this is IPv4 */ if (VIR_ALLOC(broadcast) < 0) return -1; -- 2.8.0
2016-04-08 14:55 GMT+03:00 Peter Krempa <pkrempa@redhat.com>:
VIR_SOCKET_ADDR_VALID dereferences the pointer, thus if we pass NULL into virNetDevSetIPAddress it crashes. Regression introduced by b3d069872ce53eb.
My fail, thanks! -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
On Fri, 2016-04-08 at 13:55 +0200, Peter Krempa wrote:
VIR_SOCKET_ADDR_VALID dereferences the pointer, thus if we pass NULL into virNetDevSetIPAddress it crashes. Regression introduced by b3d069872ce53eb.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325120 --- src/util/virnetdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 712c3bc..0d030a3 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1129,7 +1129,7 @@ int virNetDevSetIPAddress(const char *ifname, unsigned int recvbuflen;
/* The caller needs to provide a correct address */ - if (VIR_SOCKET_ADDR_FAMILY(addr) == AF_INET && !VIR_SOCKET_ADDR_VALID(peer)) { + if (VIR_SOCKET_ADDR_FAMILY(addr) == AF_INET && peer && !VIR_SOCKET_ADDR_VALID(peer)) { /* compute a broadcast address if this is IPv4 */ if (VIR_ALLOC(broadcast) < 0) return -1;
The other version of virNetDevSetIPAddress() starting on line 1435 needs to be fixed in a similar fashion. Also, doesn't 'addr' need to be checked as well? I'd like to have all of these fixed in a single patch, but this change is good even by itself so it's up to you :) ACK -- Andrea Bolognani Software Engineer - Virtualization Team
On Fri, Apr 08, 2016 at 14:11:00 +0200, Andrea Bolognani wrote:
On Fri, 2016-04-08 at 13:55 +0200, Peter Krempa wrote:
VIR_SOCKET_ADDR_VALID dereferences the pointer, thus if we pass NULL into virNetDevSetIPAddress it crashes. Regression introduced by b3d069872ce53eb.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325120 --- src/util/virnetdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 712c3bc..0d030a3 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1129,7 +1129,7 @@ int virNetDevSetIPAddress(const char *ifname, unsigned int recvbuflen;
/* The caller needs to provide a correct address */ - if (VIR_SOCKET_ADDR_FAMILY(addr) == AF_INET && !VIR_SOCKET_ADDR_VALID(peer)) { + if (VIR_SOCKET_ADDR_FAMILY(addr) == AF_INET && peer && !VIR_SOCKET_ADDR_VALID(peer)) { /* compute a broadcast address if this is IPv4 */ if (VIR_ALLOC(broadcast) < 0) return -1;
The other version of virNetDevSetIPAddress() starting on line 1435 needs to be fixed in a similar fashion. Also, doesn't 'addr' need to be checked as well?
'addr' is declared as ATTRIBUTE_NONNULL. Also it wasn't touched by that patch so I don't thinkso. Ah, right. I do have linux and libnl. I hate conditionally compiled code.
I'd like to have all of these fixed in a single patch, but this change is good even by itself so it's up to you :)
I'll squash the second fix in. I just didn't bother to look for a possible second instance.
ACK
Does that apply to the fixed version? Peter
On Fri, 2016-04-08 at 14:17 +0200, Peter Krempa wrote:
doesn't 'addr' need to be checked as well?
'addr' is declared as ATTRIBUTE_NONNULL. Also it wasn't touched by that patch so I don't thinkso.
Right, never mind then.
I'd like to have all of these fixed in a single patch, but this change is good even by itself so it's up to you :)
I'll squash the second fix in. I just didn't bother to look for a possible second instance.
Well, I touched that code mere hours ago so I didn't even have to look ;)
ACK
Does that apply to the fixed version?
Even more so! Push away :) Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team
participants (3)
-
Andrea Bolognani -
Peter Krempa -
Vasiliy Tolstov