Обнаружена очередная local root уязвимость в ядре Linux 3.8

Каким образом оно должно это узнать, если кода для разбора пакета в ядре нет?

код для разбора пакета в ядре есть, и это писалось уже неоднократно

анонимус, ты меня не читаешь полностью из-за дислексии или скажем тебе твоя религия запрещает?

однако, этот код stateless и очень туп — на уровне смещений в пакете (или file magic)

(а когда необходимо сделать что-то stateful, скажем nat, то этим занимается не ядро — какой-то демон регистрируется как обработчик *всех* пакетов)

какому из сотен запущенных процессов его надо отдать или куда дальше его надо завернуть

ядро знает что такое процесс; ядро также знает что такое порт-определенного-протокола, и какие процессы висят на каких портах (в частности, оно может не позволять двоим процессам слушать один порт или позволить это (если надо))

т.е. ядро все-таки оперирует кое-каким state-ом, однако *логически* это state процесса (процесс pid=12345 слушает порты 67 и 890), хотя *физически* это скорее всего будет таблица скажем 64Кпорта*4байта=256кб на каждый сетевой интерфейс

еще раз — поскольку *логически* слушаемые порты являются состоянием *процесса*, а не сети, ядро об этом знает и работает с этим, ибо ядро работает с процессами

а вот уже досылка пропавших пакетов, скорость передачи, всевозможные буфера сокета и т.п. — это дело сетевого стека

ядро знает что такое процесс; ядро также знает что такое порт-определенного-протокола, и какие процессы висят на каких портах

вот тут уже напрочь поехала твоя красивая архитектура полного разделения уровней. И возникает вопрос стоит ли так извращаться. На твоём месте я бы каждому процессу выделил по ipv6 адресу и в ядре смотрел только адрес назначения. А уже внутри приложения оно бы запускало всякие libtcp итп. В таком случае логики на уровне ядра почти не будет.

вот тут уже напрочь поехала твоя красивая архитектура полного разделения уровней. И возникает вопрос стоит ли так извращаться. На твоём месте я бы каждому процессу выделил по ipv6 адресу

ну так это то же самое: true_admin_ipv6=strcat(ip4addr, ip4port)

и нет, архитектура не поехала

ну так это то же самое

а потом ты вспомнишь про icmp, igmp, туннели...

а потом ты вспомнишь про icmp, igmp, туннели...

это *ты* вспомнишь; твой «один ipv6» это неудачное архитектурное предложение

давай лучше найди недостатки или неясности в том, что я предложил

ядро знает что такое процесс; ядро также знает что такое порт-определенного-протокола, и какие процессы висят на каких портах (в частности, оно может не позволять двоим процессам слушать один порт или позволить это (если надо))

Ты сейчас, что-ли, выкидываешь все протоколы кроме TCP и UDP? Ладно, фиг с ARP. Но как будет работать UDP-мультикаст, которому нужен IGMP? Как будут работать утилиты ping и mtr? Наконец, как твой процесс получит какой-нибудь ICMP connection refused?

хотя *физически* это скорее всего будет таблица скажем 64Кпорта*4байта=256кб на каждый сетевой интерфейс

Во-первых, забываешь про TCP+UDP, и что любое количество процессов могут юзать один порт (форкающийся апач — как пример)... Во-вторых, а маршрутизация тут где будет? Если я посылаю пакет на 192.168.1.5, то как ядро узнает, в какой интерфейс надо выплюнуть этот пакет? А может вообще не в интерфейс, может это мой адрес, и надо передать его другому процессу?

Отдельную головную боль ты заработаешь, когда попытаешься описать обеспечение безопасности в такой системе. А то получится, что у тебя процесс любого юзера, открывший 80й порт, будет получать все http-пакеты и снифать все пароли. И файрвол у тебя не будет ничего блокировать, потому что будет всего лишь одним процессом из многих равноправных.

код для разбора пакета в ядре есть [...] однако, этот код stateless и очень туп — на уровне смещений в пакете (или file magic)

Насколько «туп»? VLAN-тегирование может изменить тебе все смещения в пакете, вланы будут разбираться в ядре? Но IP-пакет может быть фрагментирован и в очередном фрагменте может вообще не быть номера порта, IP тоже будет разбираться в ядре? TCP-порт из пакета тоже, очевидно, будет разбираться в ядре. А если пакет придет на закрытый порт, кто будет посылать RST-ответ? Генерация TCP-пакетов тоже будет в ядре? А что ж тогда будет в твоей библиотеке?