| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix potential memory leak in wilc_mac_xmit()
The wilc_mac_xmit() returns NETDEV_TX_OK without freeing skb, add
dev_kfree_skb() to fix it. Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: pm8001: Fix running_req for internal abort commands
Disabling the remote phy for a SATA disk causes a hang:
root@(none)$ more /sys/class/sas_phy/phy-0:0:8/target_port_protocols
sata
root@(none)$ echo 0 > sys/class/sas_phy/phy-0:0:8/enable
root@(none)$ [ 67.855950] sas: ex 500e004aaaaaaa1f phy08 change count has changed
[ 67.920585] sd 0:0:2:0: [sdc] Synchronizing SCSI cache
[ 67.925780] sd 0:0:2:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK
[ 67.935094] sd 0:0:2:0: [sdc] Stopping disk
[ 67.939305] sd 0:0:2:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK
...
[ 123.998998] INFO: task kworker/u192:1:642 blocked for more than 30 seconds.
[ 124.005960] Not tainted 6.0.0-rc1-205202-gf26f8f761e83 #218
[ 124.012049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 124.019872] task:kworker/u192:1 state:D stack:0 pid: 642 ppid: 2 flags:0x00000008
[ 124.028223] Workqueue: 0000:04:00.0_event_q sas_port_event_worker
[ 124.034319] Call trace:
[ 124.036758] __switch_to+0x128/0x278
[ 124.040333] __schedule+0x434/0xa58
[ 124.043820] schedule+0x94/0x138
[ 124.047045] schedule_timeout+0x2fc/0x368
[ 124.051052] wait_for_completion+0xdc/0x200
[ 124.055234] __flush_workqueue+0x1a8/0x708
[ 124.059328] sas_porte_broadcast_rcvd+0xa8/0xc0
[ 124.063858] sas_port_event_worker+0x60/0x98
[ 124.068126] process_one_work+0x3f8/0x660
[ 124.072134] worker_thread+0x70/0x700
[ 124.075793] kthread+0x1a4/0x1b8
[ 124.079014] ret_from_fork+0x10/0x20
The issue is that the per-device running_req read in
pm8001_dev_gone_notify() never goes to zero and we never make progress.
This is caused by missing accounting for running_req for when an internal
abort command completes.
In commit 2cbbf489778e ("scsi: pm8001: Use libsas internal abort support")
we started to send internal abort commands as a proper sas_task. In this
when we deliver a sas_task to HW the per-device running_req is incremented
in pm8001_queue_command(). However it is never decremented for internal
abort commnds, so decrement in pm8001_mpi_task_abort_resp(). |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: via-sdmmc: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
Fix this by checking the return value and goto error path which
will call mmc_free_host(). |
| In the Linux kernel, the following vulnerability has been resolved:
tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leak
In check_acpi_tpm2(), we get the TPM2 table just to make
sure the table is there, not used after the init, so the
acpi_put_table() should be added to release the ACPI memory. |
| In the Linux kernel, the following vulnerability has been resolved:
NFSD: Finish converting the NFSv2 GETACL result encoder
The xdr_stream conversion inadvertently left some code that set the
page_len of the send buffer. The XDR stream encoders should handle
this automatically now.
This oversight adds garbage past the end of the Reply message.
Clients typically ignore the garbage, but NFSD does not need to send
it, as it leaks stale memory contents onto the wire. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio: devices: fix missing put_device in mport_cdev_open
When kfifo_alloc fails, the refcount of chdev->dev is left incremental.
We should use put_device(&chdev->dev) to decrease the ref count of
chdev->dev to avoid refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio: rio: fix possible name leak in rio_register_mport()
If device_register() returns error, the name allocated by dev_set_name()
need be freed. It should use put_device() to give up the reference in the
error path, so that the name can be freed in kobject_cleanup(), and
list_del() is called to delete the port from rio_mports. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: apple-admac: Fix 'current_tx' not getting freed
In terminate_all we should queue up all submitted descriptors to be
freed. We do that for the content of the 'issued' and 'submitted' lists,
but the 'current_tx' descriptor falls through the cracks as it's
removed from the 'issued' list once it gets assigned to be the current
descriptor. Explicitly queue up freeing of the 'current_tx' descriptor
to address a memory leak that is otherwise present. |
| In the Linux kernel, the following vulnerability has been resolved:
drivers: dio: fix possible memory leak in dio_init()
If device_register() returns error, the 'dev' and name needs be
freed. Add a release function, and then call put_device() in the
error path, so the name is freed in kobject_cleanup() and to the
'dev' is freed in release function. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failed
There is a null-ptr-deref when mount.cifs over rdma:
BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe]
Read of size 8 at addr 0000000000000018 by task mount.cifs/3046
CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
kasan_report+0xad/0x130
rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe]
execute_in_process_context+0x25/0x90
__rxe_cleanup+0x101/0x1d0 [rdma_rxe]
rxe_create_qp+0x16a/0x180 [rdma_rxe]
create_qp.part.0+0x27d/0x340
ib_create_qp_kernel+0x73/0x160
rdma_create_qp+0x100/0x230
_smbd_get_connection+0x752/0x20f0
smbd_get_connection+0x21/0x40
cifs_get_tcp_session+0x8ef/0xda0
mount_get_conns+0x60/0x750
cifs_mount+0x103/0xd00
cifs_smb3_do_mount+0x1dd/0xcb0
smb3_get_tree+0x1d5/0x300
vfs_get_tree+0x41/0xf0
path_mount+0x9b3/0xdd0
__x64_sys_mount+0x190/0x1d0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The root cause of the issue is the socket create failed in
rxe_qp_init_req().
So move the reset rxe_qp_do_cleanup() after the NULL ptr check. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable preemption in bpf_event_output
We received report [1] of kernel crash, which is caused by
using nesting protection without disabled preemption.
The bpf_event_output can be called by programs executed by
bpf_prog_run_array_cg function that disabled migration but
keeps preemption enabled.
This can cause task to be preempted by another one inside the
nesting protection and lead eventually to two tasks using same
perf_sample_data buffer and cause crashes like:
BUG: kernel NULL pointer dereference, address: 0000000000000001
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
...
? perf_output_sample+0x12a/0x9a0
? finish_task_switch.isra.0+0x81/0x280
? perf_event_output+0x66/0xa0
? bpf_event_output+0x13a/0x190
? bpf_event_output_data+0x22/0x40
? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb
? xa_load+0x87/0xe0
? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0
? release_sock+0x3e/0x90
? sk_setsockopt+0x1a1/0x12f0
? udp_pre_connect+0x36/0x50
? inet_dgram_connect+0x93/0xa0
? __sys_connect+0xb4/0xe0
? udp_setsockopt+0x27/0x40
? __pfx_udp_push_pending_frames+0x10/0x10
? __sys_setsockopt+0xdf/0x1a0
? __x64_sys_connect+0xf/0x20
? do_syscall_64+0x3a/0x90
? entry_SYSCALL_64_after_hwframe+0x72/0xdc
Fixing this by disabling preemption in bpf_event_output.
[1] https://github.com/cilium/cilium/issues/26756 |
| In the Linux kernel, the following vulnerability has been resolved:
keys: Fix linking a duplicate key to a keyring's assoc_array
When making a DNS query inside the kernel using dns_query(), the request
code can in rare cases end up creating a duplicate index key in the
assoc_array of the destination keyring. It is eventually found by
a BUG_ON() check in the assoc_array implementation and results in
a crash.
Example report:
[2158499.700025] kernel BUG at ../lib/assoc_array.c:652!
[2158499.700039] invalid opcode: 0000 [#1] SMP PTI
[2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3
[2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs]
[2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40
[2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff <0f> 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f
[2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282
[2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005
[2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000
[2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000
[2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28
[2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740
[2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000
[2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0
[2158499.700702] Call Trace:
[2158499.700741] ? key_alloc+0x447/0x4b0
[2158499.700768] ? __key_link_begin+0x43/0xa0
[2158499.700790] __key_link_begin+0x43/0xa0
[2158499.700814] request_key_and_link+0x2c7/0x730
[2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver]
[2158499.700873] ? key_default_cmp+0x20/0x20
[2158499.700898] request_key_tag+0x43/0xa0
[2158499.700926] dns_query+0x114/0x2ca [dns_resolver]
[2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs]
[2158499.701164] ? scnprintf+0x49/0x90
[2158499.701190] ? __switch_to_asm+0x40/0x70
[2158499.701211] ? __switch_to_asm+0x34/0x70
[2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs]
[2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs]
[2158499.701632] process_one_work+0x1f8/0x3e0
[2158499.701658] worker_thread+0x2d/0x3f0
[2158499.701682] ? process_one_work+0x3e0/0x3e0
[2158499.701703] kthread+0x10d/0x130
[2158499.701723] ? kthread_park+0xb0/0xb0
[2158499.701746] ret_from_fork+0x1f/0x40
The situation occurs as follows:
* Some kernel facility invokes dns_query() to resolve a hostname, for
example, "abcdef". The function registers its global DNS resolver
cache as current->cred.thread_keyring and passes the query to
request_key_net() -> request_key_tag() -> request_key_and_link().
* Function request_key_and_link() creates a keyring_search_context
object. Its match_data.cmp method gets set via a call to
type->match_preparse() (resolves to dns_resolver_match_preparse()) to
dns_resolver_cmp().
* Function request_key_and_link() continues and invokes
search_process_keyrings_rcu() which returns that a given key was not
found. The control is then passed to request_key_and_link() ->
construct_alloc_key().
* Concurrently to that, a second task similarly makes a DNS query for
"abcdef." and its result gets inserted into the DNS resolver cache.
* Back on the first task, function construct_alloc_key() first runs
__key_link_begin() to determine an assoc_array_edit operation to
insert a new key. Index keys in the array are compared exactly as-is,
using keyring_compare_object(). The operation
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()
The ucmd->log_sq_bb_count variable is controlled by the user so this
shift can wrap. Fix it by using check_shl_overflow() in the same way
that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined
behavior in hns_roce_set_user_sq_size()"). |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: fix pin_assignment_show
This patch fixes negative indexing of buf array in pin_assignment_show
when get_current_pin_assignments returns 0 i.e. no compatible pin
assignments are found.
BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c
...
Call trace:
dump_backtrace+0x110/0x204
dump_stack_lvl+0x84/0xbc
print_report+0x358/0x974
kasan_report+0x9c/0xfc
__do_kernel_fault+0xd4/0x2d4
do_bad_area+0x48/0x168
do_tag_check_fault+0x24/0x38
do_mem_abort+0x6c/0x14c
el1_abort+0x44/0x68
el1h_64_sync_handler+0x64/0xa4
el1h_64_sync+0x78/0x7c
pin_assignment_show+0x26c/0x33c
dev_attr_show+0x50/0xc0 |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: fix filter idr initialization
The cited commit moved idr initialization too early in fl_change() which
allows concurrent users to access the filter that is still being
initialized and is in inconsistent state, which, in turn, can cause NULL
pointer dereference [0]. Since there is no obvious way to fix the ordering
without reverting the whole cited commit, alternative approach taken to
first insert NULL pointer into idr in order to allocate the handle but
still cause fl_get() to return NULL and prevent concurrent users from
seeing the filter while providing miss-to-action infrastructure with valid
handle id early in fl_change().
[ 152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
[ 152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5
[ 152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 152.439644] RIP: 0010:fl_dump_key+0x8b/0x1d10 [cls_flower]
[ 152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 <0f> b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57
[ 152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246
[ 152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900
[ 152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240
[ 152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900
[ 152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738
[ 152.448756] FS: 00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000
[ 152.449888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0
[ 152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 152.453588] Call Trace:
[ 152.454032] <TASK>
[ 152.454447] ? netlink_sendmsg+0x7a1/0xcb0
[ 152.455109] ? sock_sendmsg+0xc5/0x190
[ 152.455689] ? ____sys_sendmsg+0x535/0x6b0
[ 152.456320] ? ___sys_sendmsg+0xeb/0x170
[ 152.456916] ? do_syscall_64+0x3d/0x90
[ 152.457529] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 152.458321] ? ___sys_sendmsg+0xeb/0x170
[ 152.458958] ? __sys_sendmsg+0xb5/0x140
[ 152.459564] ? do_syscall_64+0x3d/0x90
[ 152.460122] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 152.460852] ? fl_dump_key_options.part.0+0xea0/0xea0 [cls_flower]
[ 152.461710] ? _raw_spin_lock+0x7a/0xd0
[ 152.462299] ? _raw_read_lock_irq+0x30/0x30
[ 152.462924] ? nla_put+0x15e/0x1c0
[ 152.463480] fl_dump+0x228/0x650 [cls_flower]
[ 152.464112] ? fl_tmplt_dump+0x210/0x210 [cls_flower]
[ 152.464854] ? __kmem_cache_alloc_node+0x1a7/0x330
[ 152.465592] ? nla_put+0x15e/0x1c0
[ 152.466160] tcf_fill_node+0x515/0x9a0
[ 152.466766] ? tc_setup_offload_action+0xf0/0xf0
[ 152.467463] ? __alloc_skb+0x13c/0x2a0
[ 152.468067] ? __build_skb_around+0x330/0x330
[ 152.468814] ? fl_get+0x107/0x1a0 [cls_flower]
[ 152.469503] tc_del_tfilter+0x718/0x1330
[ 152.470115] ? is_bpf_text_address+0xa/0x20
[ 152.470765] ? tc_ctl_chain+0xee0/0xee0
[ 152.471335] ? __kernel_text_address+0xe/0x30
[ 152.471948] ? unwind_get_return_address+0x56/0xa0
[ 152.472639] ? __thaw_task+0x150/0x150
[ 152.473218] ? arch_stack_walk+0x98/0xf0
[ 152.473839] ? __stack_depot_save+0x35/0x4c0
[ 152.474501] ? stack_trace_save+0x91/0xc0
[ 152.475119] ? security_capable+0x51/0x90
[ 152.475741] rtnetlink_rcv_msg+0x2c1/0x9d0
[ 152.476387] ? rtnl_calcit.isra.0+0x2b0/0x2b0
[ 152.477042]
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: stm32: Fix refcount leak in stm32_pctrl_get_irq_domain
of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
net: stream: purge sk_error_queue in sk_stream_kill_queues()
Changheon Lee reported TCP socket leaks, with a nice repro.
It seems we leak TCP sockets with the following sequence:
1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket.
Each ACK will cook an skb put in error queue, from __skb_tstamp_tx().
__skb_tstamp_tx() is using skb_clone(), unless
SOF_TIMESTAMPING_OPT_TSONLY was also requested.
2) If the application is also using MSG_ZEROCOPY, then we put in the
error queue cloned skbs that had a struct ubuf_info attached to them.
Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc()
does a sock_hold().
As long as the cloned skbs are still in sk_error_queue,
socket refcount is kept elevated.
3) Application closes the socket, while error queue is not empty.
Since tcp_close() no longer purges the socket error queue,
we might end up with a TCP socket with at least one skb in
error queue keeping the socket alive forever.
This bug can be (ab)used to consume all kernel memory
and freeze the host.
We need to purge the error queue, with proper synchronization
against concurrent writers. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in init_smb2_rsp_hdr
When smb1 mount fails, KASAN detect slab-out-of-bounds in
init_smb2_rsp_hdr like the following one.
For smb1 negotiate(56bytes) , init_smb2_rsp_hdr() for smb2 is called.
The issue occurs while handling smb1 negotiate as smb2 server operations.
Add smb server operations for smb1 (get_cmd_val, init_rsp_hdr,
allocate_rsp_buf, check_user_session) to handle smb1 negotiate so that
smb2 server operation does not handle it.
[ 411.400423] CIFS: VFS: Use of the less secure dialect vers=1.0 is
not recommended unless required for access to very old servers
[ 411.400452] CIFS: Attempting to mount \\192.168.45.139\homes
[ 411.479312] ksmbd: init_smb2_rsp_hdr : 492
[ 411.479323] ==================================================================
[ 411.479327] BUG: KASAN: slab-out-of-bounds in
init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479369] Read of size 16 at addr ffff888488ed0734 by task kworker/14:1/199
[ 411.479379] CPU: 14 PID: 199 Comm: kworker/14:1 Tainted: G
OE 6.1.21 #3
[ 411.479386] Hardware name: ASUSTeK COMPUTER INC. Z10PA-D8
Series/Z10PA-D8 Series, BIOS 3801 08/23/2019
[ 411.479390] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]
[ 411.479425] Call Trace:
[ 411.479428] <TASK>
[ 411.479432] dump_stack_lvl+0x49/0x63
[ 411.479444] print_report+0x171/0x4a8
[ 411.479452] ? kasan_complete_mode_report_info+0x3c/0x200
[ 411.479463] ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479497] kasan_report+0xb4/0x130
[ 411.479503] ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479537] kasan_check_range+0x149/0x1e0
[ 411.479543] memcpy+0x24/0x70
[ 411.479550] init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]
[ 411.479585] handle_ksmbd_work+0x109/0x760 [ksmbd]
[ 411.479616] ? _raw_spin_unlock_irqrestore+0x50/0x50
[ 411.479624] ? smb3_encrypt_resp+0x340/0x340 [ksmbd]
[ 411.479656] process_one_work+0x49c/0x790
[ 411.479667] worker_thread+0x2b1/0x6e0
[ 411.479674] ? process_one_work+0x790/0x790
[ 411.479680] kthread+0x177/0x1b0
[ 411.479686] ? kthread_complete_and_exit+0x30/0x30
[ 411.479692] ret_from_fork+0x22/0x30
[ 411.479702] </TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: fix race condition UAF in i915_perf_add_config_ioctl
Userspace can guess the id value and try to race oa_config object creation
with config remove, resulting in a use-after-free if we dereference the
object after unlocking the metrics_lock. For that reason, unlocking the
metrics_lock must be done after we are done dereferencing the object.
[tursulin: Manually added stable tag.]
(cherry picked from commit 49f6f6483b652108bcb73accd0204a464b922395) |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mei: fix potential NULL-ptr deref after clone
If cloning the SKB fails, don't try to use it, but rather return
as if we should pass it.
Coverity CID: 1503456 |
