kernel-4.18.0-553.100.1.el8_10
エラータID: AXSA:2026-139:07
以下項目について対処しました。
[Security Fix]
- kernel の TCP の実装には、整数オーバーフローの問題があるため、
リモートの攻撃者により、サービス拒否攻撃を可能とする脆弱性が存在
します。(CVE-2022-50865)
- kernel の Infiniband hfi1 ドライバには、オフバイワンエラーの
問題があるため、ローカルの攻撃者により、サービス拒否攻撃を可能
とする脆弱性が存在します。(CVE-2024-26766)
- kernel の Infiniband ドライバには、ロック処理に不備があるため、
ローカルの攻撃者により、情報の漏洩、およびサービス拒否攻撃を可能
とする脆弱性が存在します。(CVE-2025-38022)
- kernel の RDMA の実装には、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-38024)
- kernel の Squashfs の実装には、戻り値のチェック処理が欠落して
いるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-38415)
- kernel の ATM の実装には、無限ループの発生に至る問題があるため、
ローカルの攻撃者により、サービス拒否攻撃を可能とする脆弱性が存在
します。(CVE-2025-38459)
- kernel の USB ドライバには、メモリ領域の範囲外読み取りの問題が
あるため、ローカルの攻撃者により、情報の漏洩、およびサービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2025-39760)
- kernel のマルチパス TCP の実装には、競合状態に至る問題があるため、
ローカルの攻撃者により、情報の漏洩、データ破壊、およびサービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2025-40258)
- kernel の proc ファイルシステムの実装には、メモリ領域の解放後
利用の問題があるため、ローカルの攻撃者により、情報の漏洩、データ
破壊、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2025-40271)
- kernel の fbdev サブシステムの bit_putcs_aligned() 関数および
unaligned() 関数には、組み込みフォント配列の範囲外読み取りの問題
があるため、ローカルの攻撃者により、情報の漏洩、およびサービス
拒否攻撃を可能とする脆弱性が存在します。(CVE-2025-40322)
パッケージをアップデートしてください。
In the Linux kernel, the following vulnerability has been resolved: tcp: fix a signed-integer-overflow bug in tcp_add_backlog() The type of sk_rcvbuf and sk_sndbuf in struct sock is int, and in tcp_add_backlog(), the variable limit is caculated by adding sk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max value of int and overflow. This patch reduces the limit budget by halving the sndbuf to solve this issue since ACK packets are much smaller than the payload.
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off-by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990]
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes. The root cause is: the function ib_device_rename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time. The solution is to add the lock protection when this name is accessed in the function kobject_uevent().
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug Call Trace:
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize().
In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix infinite recursive call of clip_push(). syzbot reported the splat below. [0] This happens if we call ioctl(ATMARP_MKIP) more than once. During the first call, clip_mkip() sets clip_push() to vcc->push(), and the second call copies it to clip_vcc->old_push(). Later, when the socket is close()d, vcc_destroy_socket() passes NULL skb to clip_push(), which calls clip_vcc->old_push(), triggering the infinite recursion. Let's prevent the second ioctl(ATMARP_MKIP) by checking vcc->user_back, which is allocated by the first call as clip_vcc. Note also that we use lock_sock() to prevent racy calls. [0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace:
In the Linux kernel, the following vulnerability has been resolved: usb: core: config: Prevent OOB read in SS endpoint companion parsing usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size. Fix this up by checking the size first before looking at any of the fields in the descriptor.
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace:
In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)
In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_putcs* bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot.
N/A
SRPMS
- kernel-4.18.0-553.100.1.el8_10.src.rpm
MD5: ee16c9d42f1b6133af5598d0eef68278
SHA-256: 0b0e5c14216e72d05411d8791d04bd79088cf7fad3f350434e7a166e7c22c870
Size: 132.33 MB
Asianux Server 8 for x86_64
- bpftool-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 60df09a0d7c7f3163e2bd8e4d409b0a6
SHA-256: 6ac0470c2a8ebae9c6e82156e8026b7c70b6677c854c38cd93f837a8f42ceec5
Size: 11.28 MB - kernel-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 9f96ae5b1640bfc5f9e0bbc6cc767b40
SHA-256: 9bf002fbed822ca7d601fd16734820ee19230128f1358c4e0a4a108449694f7c
Size: 10.55 MB - kernel-abi-stablelists-4.18.0-553.100.1.el8_10.noarch.rpm
MD5: cbafd9c289143813ef144c8ded06d6ef
SHA-256: f7711a2d0075b33741ae779343de86f3950872a54d3dec38bac5fb526f94fe4a
Size: 10.57 MB - kernel-core-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 0ba27ae2541793e006fe861329a45615
SHA-256: 36796d015765950cb1168871891810be562a5f8bc0a86a898b85541ceb5cbd63
Size: 43.58 MB - kernel-cross-headers-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 3058abf313fd85595a83616a2953a438
SHA-256: ad43abffa4a49259e45f16560309dcd4f4c944593407e5dd3dc614d2d571d3a2
Size: 15.89 MB - kernel-debug-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: a1b1aa92edead07958e5bc62b70f5e59
SHA-256: abfce3dfa648c834d6b7ea2a07ee721c99866c4a47b6877acace5e641d2a66d6
Size: 10.55 MB - kernel-debug-core-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 680ed9e3e3a58b56354a1bec2b165e17
SHA-256: 953b9e8467c61360411f3bc2cd7789857dd2765079006e5b5a5d512e5ef1a05c
Size: 72.87 MB - kernel-debug-devel-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: fcba1201495715b0f0e47275df44f85b
SHA-256: ab8e09fb9eef91eae187e39f489ca08fe51265d2ae2c6f8d334c52fb0507da34
Size: 24.39 MB - kernel-debug-modules-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 55056ba8f317d51500bf7acd64aeca08
SHA-256: cdde49df17b41a5a2c89b209f0b264b4211a622aa3773fd0fb3f7c4c816d352d
Size: 65.99 MB - kernel-debug-modules-extra-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 451934b3857945924cc626843ec86a65
SHA-256: b82e29c2cfc230e145fdc51972c4f4d5965546fa2ee9c45b63c50231fd0cef9f
Size: 11.93 MB - kernel-devel-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 706caafaa635fe85a2c76a37776348ac
SHA-256: 5a14e70583166338e167378426cd2ada7c95df3f4e462047e165f443bbf467b0
Size: 24.19 MB - kernel-doc-4.18.0-553.100.1.el8_10.noarch.rpm
MD5: 99592d955948c284586af57d92e1b54d
SHA-256: c73c3f23a644c6d589779fa2c3217d9f2998336cb2053a9d5c5f79f911d3f57f
Size: 28.42 MB - kernel-headers-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 554952a80f9113efe2d0e06ff9418ad9
SHA-256: f634b45cba17a593a83abd5c499f9e36ff4a963c755797b0af8c6950d18782e9
Size: 11.90 MB - kernel-modules-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 131d77d794428ed6791525d41d5faa75
SHA-256: 06dd4921a2f5cbf1f2578255c5cb768d4690de25524ff237bf689a57fbeefc22
Size: 36.38 MB - kernel-modules-extra-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: fd2610dc17f399a923d090ee11a11777
SHA-256: c471e2ca92cdc99242eba327b36dbfbbd8fe01b46e170bccd9b3d24e34087d2e
Size: 11.24 MB - kernel-tools-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: d2bf7b602497e18ce586b7a9d1ada59f
SHA-256: 15bf3e785cec998d7d46d36e4bf887d0db91db0d32290cbf1ba864f1a936effc
Size: 10.77 MB - kernel-tools-libs-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 81f1ee4d5a8866b10791c72e22bb8339
SHA-256: eae82fe21bce005a3ccc3e06fc3fd4d7ae3035f56c917f29ded1ea28c88e7e86
Size: 10.56 MB - kernel-tools-libs-devel-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: e5d8f9c55619145005052e13999834ba
SHA-256: 47da657cfd405d68c18b499d8d9b799d768352315b7781da4227f082e2cb35a3
Size: 10.55 MB - perf-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: ce1adaca561c613f51b1f2b291abd1a2
SHA-256: b410dc51b8c5c54b0adb42200d7f9236ccbed1e6701fc6b74a014e7ff8cc5516
Size: 12.87 MB - python3-perf-4.18.0-553.100.1.el8_10.x86_64.rpm
MD5: 12b3c4366c36507c55061c7b0763e9f4
SHA-256: 69859711c8f0e229e5729484fa84fff506b18bd22ead6fb678d4fbf8a28a1bb0
Size: 10.67 MB