Linuxでは、子プロセスのPIDは常にその親のPIDよりも大きいですか？
カーネル2.6以降としましょう。
システムで実行中のすべてのプロセスを監視します。
子供のPIDは常に親のPIDよりも大きいですか？
「反転」の特別なケースを持つことは可能ですか？
いいえ、PIDが持つことができる最大の数値があるという非常に単純な理由で。プロセスが最も高いPIDを持っている場合、そのプロセスがフォークする子がより大きなPIDを持つことはできません。子に低いPIDを与える代わりに、fork()を完全に失敗させることもできますが、あまり生産的ではありません。
PIDは順番に割り当てられ、最も高いPIDが使用された後、システムは循環して（無料の）より低いPIDを再利用するため、他の場合でも子のPIDを低くすることができます。
私のシステムのデフォルトの最大PID（/proc/sys/kernel/pid_max）は32768なので、ラップアラウンドが発生する状態に到達することは難しくありません。
$ echo $$
27468
$ bash -c 'echo $$'
1296
$ bash -c 'echo $$'
1297
システムがPIDを（Linuxのように）連続的にではなく（ OpenBSDのように のように）ランダムに割り当てる場合、2つのオプションがあります。ランダムな選択が可能なPIDのスペース全体にわたって行われた場合、その場合、子のPIDが親のPIDよりも低くなる可能性があることは明らかです。または、子のPIDは、親のPIDより大きい値からランダムに選択され、平均して親のPIDと最大値の中間に置かれます。プロセスを再帰的にフォークすると、すぐに最大値に達し、上記と同じポイントになります。新しいフォークでは、成功するために低いPIDを使用する必要があります。
また、カーネル通知を使用し、プロセステーブルスキャンによる検出を回避するために自分自身をフォークすることで、セキュリティの脆弱性が存在する可能性もあります。これを正しく行うと、プロセスのPIDが低くなり、問題のプロセスがプロセスツールに表示されなくなります。
http://cve.circl.lu/cve/CVE-2018-1121
procps-ng、procpsは、競合状態を介して隠れているプロセスに対して脆弱です。カーネルのproc_pid_readdir（）は昇順のPIDエントリを返すため、高いPIDを占めるプロセスは、inotifyイベントを使用してプロセスリストがスキャンされているタイミングを判断し、fork/execを使用して低いPIDを取得することで、列挙を回避できます。非特権の攻撃者は、/ proc/PIDエントリを読み取る際の競合状態を悪用することにより、procps-ngのユーティリティからプロセスを隠すことができます。この脆弱性は、バージョン3.3.15までのprocpsおよびprocps-ngに影響します。新しいバージョンも影響を受ける可能性があります。