This is a bit confusing; the DBG_ prefix seems related to the debug.h stuff, but it's function to convert switch-case to a string. Maybe rename to CASE_TO_STRING() or so.

I'd also suggest using str (and strx) as an argument for the macro rather than hiding any variable use in the macros. The strx+2 looks unnecessary, as you can use "0x" in the snprintf() (just "0x%02hhx").

It is a part of a debug-only code.

The macro purpose is just a simplification of the repeated pieces of the code that cannot be covered by a function.

str and strx as a parameter would make more sense in case if we want to move this code to debug.h. In this single use case it would again create repeated parts in the code.

strx+2 just saved copying 2 bytes on each run (at cost of worse readability).

Maybe rename to ip_rating_as_string() to make it more readable..

Changing.

return -ENOMEM; to be compatible with usual util-linux code patterns/

and maybe the DBG() is overkill in this rare case :-)

Changing.

Do we need all the errorN gotos there? If you use calloc(), then you can use

error:
            if (newaddr) {
                      free(newaddr->ifa_local);
                      free(newaddr->ifa_address);
                      free(newaddr);
            }
            return NULL;

or better:

error:
       ul_nl_addr_free(newaddr);
       return NULL;

Changing.b

rc = -ENOMEM; as ul_nl_addr_dup() can fail only on memory allocation.

Changing and again removing DBG here and in similar cases.

It's better when free()-like functions are robust enough to accept NULL as an argument (like libc free()). It means

void ul_nl_addr_free (struct ul_nl_addr *addr)
{
    if (addr) {
	free(addr->ifa_address);
	free(addr->ifa_local);
	free(addr->ifname);
	free(addr);
    }
}

Then you can call the function in an arbitrary situation, including error cases, when you need to clean up anything.

Changing.

-ENOMEM; :-)

I would also suggest using calloc() to ensure greater robustness for future changes to the struct. This is a generic recommendation when working with structs in an interface, especially if you do not plan to use a function like memcpy() after malloc().

Changing and removing explicit zeroing.

please, no else-after-return ;-)

Ok.

4096 -> BUFSIZ ?

Actually, there is no exact size defined. If we don't want to handle MSG_TRUNC, it should cover sizeof (struct nlmsghdr) plus the expected message payload size. BUFSIZ (8192) is surely more safe than 4096.

Should be there ie->nl.fd = -1; ?

I think if (ie->nl.fd >= 0)

The code was indeed intended to represent 0 as no fd opened, supposing that fd channel 0 is never used for the netlink socket. But not fully, select() uses 0 as an active value. -1 is for sure safer and the more convenient value.

Updating code in the comments as well.

And actually, it needs to update the initialization in show_issue to:
struct issue ie = { .output = NULL, .nl.fd = -1 };

And, actually, also another struct issue initialization needs update as well:
struct issue issue = {
.mem = NULL,
.nl.fd = -1
};