Search for packages
| purl | pkg:deb/debian/linux@6.18.12-1?distro=trixie |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-2gsp-11ma-tqac | kernel: ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths |
CVE-2026-23220
|
| VCID-3nxj-regq-v3ca | kernel: Linux kernel: Denial of Service in SMB client due to race condition |
CVE-2026-23230
|
| VCID-7nxb-qm5n-g7e2 | kernel: Linux kernel qla2xxx driver: Denial of Service via NULL pointer dereference during fabric async scan cleanup |
CVE-2025-71236
|
| VCID-8fy6-bzh4-4fhq | kernel: bus: fsl-mc: fix use-after-free in driver_override_show() |
CVE-2026-23221
|
| VCID-at5e-qm3c-73fa | kernel: wifi: rtw88: Fix alignment fault in rtw_core_enable_beacon() |
CVE-2025-71229
|
| VCID-cgj5-5hrz-e3b9 | kernel: Kernel: Denial of Service in virtio-crypto due to missing spinlock protection |
CVE-2026-23229
|
| VCID-dzwp-79xg-k3hw | kernel: hfs: ensure sb->s_fs_info is always cleaned up |
CVE-2025-71230
|
| VCID-fff1-3j8x-sfa1 | In the Linux kernel, the following vulnerability has been resolved: smb: server: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. This fixes regression Namjae reported with the 6.18 release. |
CVE-2026-31538
|
| VCID-jq8m-nxpa-p3hy | In the Linux kernel, the following vulnerability has been resolved: smb: server: let send_done handle a completion without IB_SEND_SIGNALED With smbdirect_send_batch processing we likely have requests without IB_SEND_SIGNALED, which will be destroyed in the final request that has IB_SEND_SIGNALED set. If the connection is broken all requests are signaled even without explicit IB_SEND_SIGNALED. |
CVE-2026-31536
|
| VCID-jzxs-k6k4-vqhw | kernel: nilfs2: Fix potential block overflow that cause system hang |
CVE-2025-71237
|
| VCID-ncvu-jm25-q3a8 | kernel: xfs: fix UAF in xchk_btree_check_block_owner |
CVE-2026-23223
|
| VCID-pyy2-vrpz-yfbk | kernel: scsi: qla2xxx: Delay module unload while fabric scan in progress |
CVE-2025-71235
|
| VCID-qfhn-abrw-2ydg | kernel: smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection() |
CVE-2026-23228
|
| VCID-smr6-fm2b-a7e1 | kernel: Linux kernel: Denial of Service due to out-of-bounds index in IAA crypto module |
CVE-2025-71231
|
| VCID-t3mh-2tfp-kyhw | In the Linux kernel, the following vulnerability has been resolved: smb: client: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. |
CVE-2026-31535
|
| VCID-tp92-5gfk-1qb5 | In the Linux kernel, the following vulnerability has been resolved: smb: server: make use of smbdirect_socket.send_io.bcredits It turns out that our code will corrupt the stream of reassabled data transfer messages when we trigger an immendiate (empty) send. In order to fix this we'll have a single 'batch' credit per connection. And code getting that credit is free to use as much messages until remaining_length reaches 0, then the batch credit it given back and the next logical send can happen. |
CVE-2026-31537
|
| VCID-vs7k-6jqm-mfd4 | kernel: Linux kernel: Denial of Service via NULL pointer dereference in PCI endpoint configfs during asynchronous sub-group creation |
CVE-2025-71233
|
| VCID-wcu7-me4d-bugc | kernel: ksmbd: add chann_lock to protect ksmbd_chann_list xarray |
CVE-2026-23226
|
| VCID-wxjw-jp79-87gk | kernel: Linux kernel erofs: Denial of Service via Use-After-Free in file-backed directio mounts |
CVE-2026-23224
|
| VCID-yaz4-szyc-afg8 | kernel: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free |
CVE-2026-23227
|
| VCID-yekj-1715-eybs | kernel: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly |
CVE-2026-23222
|
| VCID-ymwr-jmku-q7cd | kernel: scsi: qla2xxx: Free sp in error path to fix system crash |
CVE-2025-71232
|
| VCID-ytcy-u8pc-skhj | In the Linux kernel, the following vulnerability has been resolved: smb: smbdirect: introduce smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. |
CVE-2026-31539
|
| VCID-zrux-w2vg-e7cp | kernel: wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add |
CVE-2025-71234
|