> Т.е. может быть всё, что угодно. В том числе и "неуспешное освобождение".

Для функции "free" в стандарте ничего не сказано про то что эта операция вообще может обломаться. С таким же успехом можно предположить что имелось в виду что это - "should never happen", а если все же happen это баг имплементации.

> 2 Note 1 to entry: Possible undefined behavior ranges from ignoring the
> situation completely with unpredictable results,

Маленький нюанс в том что в доке описывающей free() про UB вообще совсем ничего не упомянуто. То-есть не специфицировано что оно может обломаться и что при этом будет UB. Это вы сами от себя додумали. Откуда это следует я не знаю.

Как более жесткий пример: если я вызываю void something(void) - тут прямо на уровне прототипа прозрачный намек что оно не обламывается, и с таким прототипом как правило предполагается что оно всегда успешно - например, в чистой математике нечему обламываться. И в освобождении памяти в его изначальном понимании тоже: все ресурсы на этот момент уже выделены а новых выделять не надо.

> и разрешено документировать поведение, что как раз и оправдано в ядре.

Ну вот в ядре могли бы и сделать зануление указателей и жесткий завал если null на входе оказался. Там местами некая смежная активность есть, скажем они научились в зануление памяти при alloc/free оного (выбираемо для каждого из) - это тоже так то полезно для безопасности и утечек информации.

Может не особо парятся потому что кому сильно надо KASAN всякие использовали при пуске на этом syzbot и тому подобных штук.