{"id":"OESA-2026-1946","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().\n\nsyzbot reported divide-by-zero in __tcp_select_window() by\nMPTCP socket. [0]\n\nWe had a similar issue for the bare TCP and fixed in commit\n499350a5a6e7 ("tcp: initialize rcv_mss to TCP_MIN_MSS instead\nof 0").\n\nLet's apply the same fix to mptcp_do_fastclose().\n\n[0]:\nOops: divide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336\nCode: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00\nRSP: 0018:ffffc90003017640 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028\nR10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0\nCall Trace:\n <TASK>\n tcp_select_window net/ipv4/tcp_output.c:281 [inline]\n __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568\n tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline]\n tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836\n mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793\n mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253\n mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776\n mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0xe5/0x270 net/socket.c:742\n __sys_sendto+0x3bd/0x520 net/socket.c:2244\n __do_sys_sendto net/socket.c:2251 [inline]\n __se_sys_sendto net/socket.c:2247 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2247\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f66e998f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006\n </TASK>(CVE-2025-68291)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: secure_seq: add back ports to TS offset\n\nThis reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")\n\ntcp_tw_recycle went away in 2017.\n\nZhouyan Deng reported off-path TCP source port leakage via\nSYN cookie side-channel that can be fixed in multiple ways.\n\nOne of them is to bring back TCP ports in TS offset randomization.\n\nAs a bonus, we perform a single siphash() computation\nto provide both an ISN and a TS offset.(CVE-2026-23247)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: validate DFA start states are in bounds in unpack_pdb\n\nStart states are read from untrusted data and used as indexes into the\nDFA state tables. The aa_dfa_next() function call in unpack_pdb() will\naccess dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds\nthe number of states in the DFA, this results in an out-of-bound read.\n\n==================================================================\n BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360\n Read of size 4 at addr ffff88811956fb90 by task su/1097\n ...\n\nReject policies with out-of-bounds start states during unpacking\nto prevent the issue.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race condition during IPSec ESN update\n\nIn IPSec full offload mode, the device reports an ESN (Extended\nSequence Number) wrap event to the driver. The driver validates this\nevent by querying the IPSec ASO and checking that the esn_event_arm\nfield is 0x0, which indicates an event has occurred. After handling\nthe event, the driver must re-arm the context by setting esn_event_arm\nback to 0x1.\n\nA race condition exists in this handling path. After validating the\nevent, the driver calls mlx5_accel_esp_modify_xfrm() to update the\nkernel's xfrm state. This function temporarily releases and\nre-acquires the xfrm state lock.\n\nSo, need to acknowledge the event first by setting esn_event_arm to\n0x1. This prevents the driver from reprocessing the same ESN update if\nthe hardware sends events for other reason. Since the next ESN update\nonly occurs after nearly 2^31 packets are received, there's no risk of\nmissing an update, as it will happen long after this handling has\nfinished.\n\nProcessing the event twice causes the ESN high-order bits (esn_msb) to\nbe incremented incorrectly. The driver then programs the hardware with\nthis invalid ESN state, which leads to anti-replay failures and a\ncomplete halt of IPSec traffic.\n\nFix this by re-arming the ESN event immediately after it is validated,\nbefore calling mlx5_accel_esp_modify_xfrm(). This ensures that any\nspurious, duplicate events are correctly ignored, closing the race\nwindow.(CVE-2026-23440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent concurrent access to IPSec ASO context\n\nThe query or updating IPSec offload object is through Access ASO WQE.\nThe driver uses a single mlx5e_ipsec_aso struct for each PF, which\ncontains a shared DMA-mapped context for all ASO operations.\n\nA race condition exists because the ASO spinlock is released before\nthe hardware has finished processing WQE. If a second operation is\ninitiated immediately after, it overwrites the shared context in the\nDMA area.\n\nWhen the first operation's completion is processed later, it reads\nthis corrupted context, leading to unexpected behavior and incorrect\nresults.\n\nThis commit fixes the race by introducing a private context within\neach IPSec offload object. The shared ASO context is now copied to\nthis private context while the ASO spinlock is held. Subsequent\nprocessing uses this saved, per-object context, ensuring its integrity\nis maintained.(CVE-2026-23441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: always free skb on ieee80211_tx_prepare_skb() failure\n\nieee80211_tx_prepare_skb() has three error paths, but only two of them\nfree the skb. The first error path (ieee80211_tx_prepare() returning\nTX_DROP) does not free it, while invoke_tx_handlers() failure and the\nfragmentation check both do.\n\nAdd kfree_skb() to the first error path so all three are consistent,\nand remove the now-redundant frees in callers (ath9k, mt76,\nmac80211_hwsim) to avoid double-free.\n\nDocument the skb ownership guarantee in the function's kdoc.(CVE-2026-23444)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user\n\nAfter commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in\nhci_chan_del"), l2cap_conn_del() uses conn->lock to protect access to\nconn->users. However, l2cap_register_user() and l2cap_unregister_user()\ndon't use conn->lock, creating a race condition where these functions can\naccess conn->users and conn->hchan concurrently with l2cap_conn_del().\n\nThis can lead to use-after-free and list corruption bugs, as reported\nby syzbot.\n\nFix this by changing l2cap_register_user() and l2cap_unregister_user()\nto use conn->lock instead of hci_dev_lock(), ensuring consistent locking\nfor the l2cap_conn structure.(CVE-2026-23461)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access\n\nl2cap_information_rsp() checks that cmd_len covers the fixed\nl2cap_info_rsp header (type + result, 4 bytes) but then reads\nrsp->data without verifying that the payload is present:\n\n - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp->data), which reads\n   4 bytes past the header (needs cmd_len >= 8).\n\n - L2CAP_IT_FIXED_CHAN reads rsp->data[0], 1 byte past the header\n   (needs cmd_len >= 5).\n\nA truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an\nout-of-bounds read of adjacent skb data.\n\nGuard each data access with the required payload length check.  If the\npayload is too short, skip the read and let the state machine complete\nwith safe defaults (feat_mask and remote_fixed_chan remain zero from\nkzalloc), so the info timer cleanup and l2cap_conn_start() still run\nand the connection is not stalled.(CVE-2026-31393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm/bus: Fix potential use after free in asynchronous initialization\n\nDingisoul with KASAN reports a use after free if device_add() fails in\nnd_async_device_register().\n\nCommit b6eae0f61db2 ("libnvdimm: Hold reference on parent while\nscheduling async init") correctly added a reference on the parent device\nto be held until asynchronous initialization was complete.  However, if\ndevice_add() results in an allocation failure the ref count of the\ndevice drops to 0 prior to the parent pointer being accessed.  Thus\nresulting in use after free.\n\nThe bug bot AI correctly identified the fix.  Save a reference to the\nparent pointer to be used to drop the parent reference regardless of the\noutcome of device_add().(CVE-2026-31399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-net: fix OOB access in ULE extension header tables\n\nThe ule_mandatory_ext_handlers[] and ule_optional_ext_handlers[] tables\nin handle_one_ule_extension() are declared with 255 elements (valid\nindices 0-254), but the index htype is derived from network-controlled\ndata as (ule_sndu_type & 0x00FF), giving a range of 0-255. When\nhtype equals 255, an out-of-bounds read occurs on the function pointer\ntable, and the OOB value may be called as a function pointer.\n\nAdd a bounds check on htype against the array size before either table\nis accessed. Out-of-range values now cause the SNDU to be discarded.(CVE-2026-31405)\n\nIn the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)","modified":"2026-04-17T13:20:06.620834Z","published":"2026-04-17T13:01:29Z","upstream":["CVE-2025-68291","CVE-2026-23247","CVE-2026-23269","CVE-2026-23389","CVE-2026-23440","CVE-2026-23441","CVE-2026-23444","CVE-2026-23461","CVE-2026-31393","CVE-2026-31399","CVE-2026-31405","CVE-2026-31408"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1946"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68291"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23247"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23389"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23440"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23441"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23444"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23461"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31393"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31399"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31405"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31408"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.0.3.131.oe2403"}]}],"ecosystem_specific":{"x86_64":["bpftool-6.6.0-145.0.3.131.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-devel-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-headers-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-source-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-tools-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-145.0.3.131.oe2403.x86_64.rpm","perf-6.6.0-145.0.3.131.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm","python3-perf-6.6.0-145.0.3.131.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.0.3.131.oe2403.x86_64.rpm"],"aarch64":["bpftool-6.6.0-145.0.3.131.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-devel-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-headers-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-source-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-tools-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-145.0.3.131.oe2403.aarch64.rpm","perf-6.6.0-145.0.3.131.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm","python3-perf-6.6.0-145.0.3.131.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.0.3.131.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-145.0.3.131.oe2403.src.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-1946.json"}}],"schema_version":"1.7.5"}