| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: Don't expose hw_counters outside of init net namespace
Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs
attributes") accidentally almost exposed hw counters to non-init net
namespaces. It didn't expose them fully, as an attempt to read any of
those counters leads to a crash like this one:
[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028
[42021.814463] #PF: supervisor read access in kernel mode
[42021.819549] #PF: error_code(0x0000) - not-present page
[42021.824636] PGD 0 P4D 0
[42021.827145] Oops: 0000 [#1] SMP PTI
[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX
[42021.841697] Hardware name: XXX
[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]
[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48
[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287
[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000
[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0
[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000
[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530
[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000
[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000
[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0
[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[42021.949324] Call Trace:
[42021.951756] <TASK>
[42021.953842] [<ffffffff86c58674>] ? show_regs+0x64/0x70
[42021.959030] [<ffffffff86c58468>] ? __die+0x78/0xc0
[42021.963874] [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0
[42021.969749] [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0
[42021.975549] [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30
[42021.981517] [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]
[42021.988482] [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core]
[42021.995438] [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50
[42022.000803] [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0
[42022.006508] [<ffffffff86a11134>] seq_read_iter+0xf4/0x410
[42022.011954] [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0
[42022.017058] [<ffffffff869f50ee>] ksys_read+0x6e/0xe0
[42022.022073] [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0
[42022.027441] [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2
The problem can be reproduced using the following steps:
ip netns add foo
ip netns exec foo bash
cat /sys/class/infiniband/mlx4_0/hw_counters/*
The panic occurs because of casting the device pointer into an
ib_device pointer using container_of() in hw_stat_device_show() is
wrong and leads to a memory corruption.
However the real problem is that hw counters should never been exposed
outside of the non-init net namespace.
Fix this by saving the index of the corresponding attribute group
(it might be 1 or 2 depending on the presence of driver-specific
attributes) and zeroing the pointer to hw_counters group for compat
devices during the initialization.
With this fix applied hw_counters are not available in a non-init
net namespace:
find /sys/class/infiniband/mlx4_0/ -name hw_counters
/sys/class/infiniband/mlx4_0/ports/1/hw_counters
/sys/class/infiniband/mlx4_0/ports/2/hw_counters
/sys/class/infiniband/mlx4_0/hw_counters
ip netns add foo
ip netns exec foo bash
find /sys/class/infiniband/mlx4_0/ -name hw_counters |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix NULL dereference in SR-IOV VF creation error path
Clean up when virtfn setup fails to prevent NULL pointer dereference
during device removal. The kernel oops below occurred due to incorrect
error handling flow when pci_setup_device() fails.
Add pci_iov_scan_device(), which handles virtfn allocation and setup and
cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn't need
to call pci_stop_and_remove_bus_device(). This prevents accessing
partially initialized virtfn devices during removal.
BUG: kernel NULL pointer dereference, address: 00000000000000d0
RIP: 0010:device_del+0x3d/0x3d0
Call Trace:
pci_remove_bus_device+0x7c/0x100
pci_iov_add_virtfn+0xfa/0x200
sriov_enable+0x208/0x420
mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]
sriov_numvfs_store+0xae/0x1a0
[bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly] |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: avoid NPD when ASIC does not support DMUB
ctx->dmub_srv will de NULL if the ASIC does not support DMUB, which is
tested in dm_dmub_sw_init.
However, it will be dereferenced in dmub_hw_lock_mgr_cmd if
should_use_dmub_lock returns true.
This has been the case since dmub support has been added for PSR1.
Fix this by checking for dmub_srv in should_use_dmub_lock.
[ 37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058
[ 37.447808] #PF: supervisor read access in kernel mode
[ 37.452959] #PF: error_code(0x0000) - not-present page
[ 37.458112] PGD 0 P4D 0
[ 37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88
[ 37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[ 37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0
[ 37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 <48> 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5
[ 37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202
[ 37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358
[ 37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000
[ 37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5
[ 37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000
[ 37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000
[ 37.551725] FS: 0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000
[ 37.559814] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0
[ 37.572697] Call Trace:
[ 37.575152] <TASK>
[ 37.577258] ? __die_body+0x66/0xb0
[ 37.580756] ? page_fault_oops+0x3e7/0x4a0
[ 37.584861] ? exc_page_fault+0x3e/0xe0
[ 37.588706] ? exc_page_fault+0x5c/0xe0
[ 37.592550] ? asm_exc_page_fault+0x22/0x30
[ 37.596742] ? dmub_hw_lock_mgr_cmd+0x77/0xb0
[ 37.601107] dcn10_cursor_lock+0x1e1/0x240
[ 37.605211] program_cursor_attributes+0x81/0x190
[ 37.609923] commit_planes_for_stream+0x998/0x1ef0
[ 37.614722] update_planes_and_stream_v2+0x41e/0x5c0
[ 37.619703] dc_update_planes_and_stream+0x78/0x140
[ 37.624588] amdgpu_dm_atomic_commit_tail+0x4362/0x49f0
[ 37.629832] ? srso_return_thunk+0x5/0x5f
[ 37.633847] ? mark_held_locks+0x6d/0xd0
[ 37.637774] ? _raw_spin_unlock_irq+0x24/0x50
[ 37.642135] ? srso_return_thunk+0x5/0x5f
[ 37.646148] ? lockdep_hardirqs_on+0x95/0x150
[ 37.650510] ? srso_return_thunk+0x5/0x5f
[ 37.654522] ? _raw_spin_unlock_irq+0x2f/0x50
[ 37.658883] ? srso_return_thunk+0x5/0x5f
[ 37.662897] ? wait_for_common+0x186/0x1c0
[ 37.666998] ? srso_return_thunk+0x5/0x5f
[ 37.671009] ? drm_crtc_next_vblank_start+0xc3/0x170
[ 37.675983] commit_tail+0xf5/0x1c0
[ 37.679478] drm_atomic_helper_commit+0x2a2/0x2b0
[ 37.684186] drm_atomic_commit+0xd6/0x100
[ 37.688199] ? __cfi___drm_printfn_info+0x10/0x10
[ 37.692911] drm_atomic_helper_update_plane+0xe5/0x130
[ 37.698054] drm_mode_cursor_common+0x501/0x670
[ 37.702600] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10
[ 37.707572] drm_mode_cursor_ioctl+0x48/0x70
[ 37.711851] drm_ioctl_kernel+0xf2/0x150
[ 37.715781] drm_ioctl+0x363/0x590
[ 37.719189] ? __cfi_drm_mode_cursor_ioctl+0x10/0x10
[ 37.724165] amdgpu_drm_ioctl+0x41/0x80
[ 37.728013] __se_sys_ioctl+0x7f/0xd0
[ 37.731685] do_syscall_64+0x87/0x100
[ 37.735355] ? vma_end_read+0x12/0xe0
[ 37.739024] ? srso_return_thunk+0x5/0x5f
[ 37.743041] ? find_held_lock+0x47/0xf0
[ 37.746884] ? vma_end_read+0x12/0xe0
[ 37.750552] ? srso_return_thunk+0x5/0
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/perf: Fix ref-counting on the PMU 'vpa_pmu'
Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa
counters") introduced 'vpa_pmu' to expose Book3s-HV nested APIv2 provided
L1<->L2 context switch latency counters to L1 user-space via
perf-events. However the newly introduced PMU named 'vpa_pmu' doesn't
assign ownership of the PMU to the module 'vpa_pmu'. Consequently the
module 'vpa_pmu' can be unloaded while one of the perf-events are still
active, which can lead to kernel oops and panic of the form below on a
Pseries-LPAR:
BUG: Kernel NULL pointer dereference on read at 0x00000058
<snip>
NIP [c000000000506cb8] event_sched_out+0x40/0x258
LR [c00000000050e8a4] __perf_remove_from_context+0x7c/0x2b0
Call Trace:
[c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable)
[c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0
[c00000025fc3fcd0] [c000000000501e70] event_function+0xa8/0x120
<snip>
Kernel panic - not syncing: Aiee, killing interrupt handler!
Fix this by adding the module ownership to 'vpa_pmu' so that the module
'vpa_pmu' is ref-counted and prevented from being unloaded when perf-events
are initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: brcmstb: Fix error path after a call to regulator_bulk_get()
If the regulator_bulk_get() returns an error and no regulators
are created, we need to set their number to zero.
If we don't do this and the PCIe link up fails, a call to the
regulator_bulk_free() will result in a kernel panic.
While at it, print the error value, as we cannot return an error
upwards as the kernel will WARN() on an error from add_bus().
[kwilczynski: commit log, use comma in the message to match style with
other similar messages] |
| In the Linux kernel, the following vulnerability has been resolved:
spufs: fix gang directory lifetimes
prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have
a problem with gang lifetimes - creation of a gang returns opened
gang directory, which normally gets removed when that gets closed,
but if somebody has created a context belonging to that gang and
kept it alive until the gang got closed, removal failed and we
ended up with a leak.
Unfortunately, it had been fixed the wrong way. Dentry of gang
directory was no longer pinned, and rmdir on close was gone.
One problem was that failure of open kept calling simple_rmdir()
as cleanup, which meant an unbalanced dput(). Another bug was
in the success case - gang creation incremented link count on
root directory, but that was no longer undone when gang got
destroyed.
Fix consists of
* reverting the commit in question
* adding a counter to gang, protected by ->i_rwsem
of gang directory inode.
* having it set to 1 at creation time, dropped
in both spufs_dir_close() and spufs_gang_close() and bumped
in spufs_create_context(), provided that it's not 0.
* using simple_recursive_removal() to take the gang
directory out when counter reaches zero. |
| In the Linux kernel, the following vulnerability has been resolved:
net: airoha: Fix qid report in airoha_tc_get_htb_get_leaf_queue()
Fix the following kernel warning deleting HTB offloaded leafs and/or root
HTB qdisc in airoha_eth driver properly reporting qid in
airoha_tc_get_htb_get_leaf_queue routine.
$tc qdisc replace dev eth1 root handle 10: htb offload
$tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit
$tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \
quanta 1514 3028 4542 6056 7570 9084 10598 12112
$tc qdisc del dev eth1 root
[ 55.827864] ------------[ cut here ]------------
[ 55.832493] WARNING: CPU: 3 PID: 2678 at 0xffffffc0798695a4
[ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: G O 6.6.71 #0
[ 55.963557] Hardware name: Airoha AN7581 Evaluation Board (DT)
[ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 55.976344] pc : 0xffffffc0798695a4
[ 55.979851] lr : 0xffffffc079869a20
[ 55.983358] sp : ffffffc0850536a0
[ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001
[ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800
[ 56.000935] x23: 0000000000000001 x22: 0000000000000000 x21: ffffff8008b19000
[ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 0000000000000000
[ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000
[ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001
[ 56.029478] x11: ffffffc081471008 x10: ffffffc081575a98 x9 : 0000000000000000
[ 56.036614] x8 : ffffffc08167fd40 x7 : ffffffc08069e104 x6 : ffffff8007f86000
[ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001
[ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000
[ 56.058020] Call trace:
[ 56.060459] 0xffffffc0798695a4
[ 56.063618] 0xffffffc079869a20
[ 56.066777] __qdisc_destroy+0x40/0xa0
[ 56.070528] qdisc_put+0x54/0x6c
[ 56.073748] qdisc_graft+0x41c/0x648
[ 56.077324] tc_get_qdisc+0x168/0x2f8
[ 56.080978] rtnetlink_rcv_msg+0x230/0x330
[ 56.085076] netlink_rcv_skb+0x5c/0x128
[ 56.088913] rtnetlink_rcv+0x14/0x1c
[ 56.092490] netlink_unicast+0x1e0/0x2c8
[ 56.096413] netlink_sendmsg+0x198/0x3c8
[ 56.100337] ____sys_sendmsg+0x1c4/0x274
[ 56.104261] ___sys_sendmsg+0x7c/0xc0
[ 56.107924] __sys_sendmsg+0x44/0x98
[ 56.111492] __arm64_sys_sendmsg+0x20/0x28
[ 56.115580] invoke_syscall.constprop.0+0x58/0xfc
[ 56.120285] do_el0_svc+0x3c/0xbc
[ 56.123592] el0_svc+0x18/0x4c
[ 56.126647] el0t_64_sync_handler+0x118/0x124
[ 56.131005] el0t_64_sync+0x150/0x154
[ 56.134660] ---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")
added support for getting VF port and node GUIDs in netlink ifinfo
messages, but their size was not taken into consideration in the
function that allocates the netlink message, causing the following
warning when a netlink message is filled with many VF port and node
GUIDs:
# echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs
# ip link show dev ib0
RTNETLINK answers: Message too long
Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0
Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core
CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:rtnl_getlink+0x586/0x5a0
Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00
RSP: 0018:ffff888113557348 EFLAGS: 00010246
RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000
RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8
RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000
R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00
R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff
FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
<TASK>
? __warn+0xa5/0x230
? rtnl_getlink+0x586/0x5a0
? report_bug+0x22d/0x240
? handle_bug+0x53/0xa0
? exc_invalid_op+0x14/0x50
? asm_exc_invalid_op+0x16/0x20
? skb_trim+0x6a/0x80
? rtnl_getlink+0x586/0x5a0
? __pfx_rtnl_getlink+0x10/0x10
? rtnetlink_rcv_msg+0x1e5/0x860
? __pfx___mutex_lock+0x10/0x10
? rcu_is_watching+0x34/0x60
? __pfx_lock_acquire+0x10/0x10
? stack_trace_save+0x90/0xd0
? filter_irq_stacks+0x1d/0x70
? kasan_save_stack+0x30/0x40
? kasan_save_stack+0x20/0x40
? kasan_save_track+0x10/0x30
rtnetlink_rcv_msg+0x21c/0x860
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
? __pfx_rtnetlink_rcv_msg+0x10/0x10
? arch_stack_walk+0x9e/0xf0
? rcu_is_watching+0x34/0x60
? lock_acquire+0xd5/0x410
? rcu_is_watching+0x34/0x60
netlink_rcv_skb+0xe0/0x210
? __pfx_rtnetlink_rcv_msg+0x10/0x10
? __pfx_netlink_rcv_skb+0x10/0x10
? rcu_is_watching+0x34/0x60
? __pfx___netlink_lookup+0x10/0x10
? lock_release+0x62/0x200
? netlink_deliver_tap+0xfd/0x290
? rcu_is_watching+0x34/0x60
? lock_release+0x62/0x200
? netlink_deliver_tap+0x95/0x290
netlink_unicast+0x31f/0x480
? __pfx_netlink_unicast+0x10/0x10
? rcu_is_watching+0x34/0x60
? lock_acquire+0xd5/0x410
netlink_sendmsg+0x369/0x660
? lock_release+0x62/0x200
? __pfx_netlink_sendmsg+0x10/0x10
? import_ubuf+0xb9/0xf0
? __import_iovec+0x254/0x2b0
? lock_release+0x62/0x200
? __pfx_netlink_sendmsg+0x10/0x10
____sys_sendmsg+0x559/0x5a0
? __pfx_____sys_sendmsg+0x10/0x10
? __pfx_copy_msghdr_from_user+0x10/0x10
? rcu_is_watching+0x34/0x60
? do_read_fault+0x213/0x4a0
? rcu_is_watching+0x34/0x60
___sys_sendmsg+0xe4/0x150
? __pfx____sys_sendmsg+0x10/0x10
? do_fault+0x2cc/0x6f0
? handle_pte_fault+0x2e3/0x3d0
? __pfx_handle_pte_fault+0x10/0x10
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
exfat: fix missing shutdown check
xfstests generic/730 test failed because after deleting the device
that still had dirty data, the file could still be read without
returning an error. The reason is the missing shutdown check in
->read_iter.
I also noticed that shutdown checks were missing from ->write_iter,
->splice_read, and ->mmap. This commit adds shutdown checks to all
of them. |
| In the Linux kernel, the following vulnerability has been resolved:
Revert "smb: client: fix TCP timers deadlock after rmmod"
This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.
Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after
rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is
mentioned as CVE-2024-54680, but is actually did not fix anything;
The issue can be reproduced on top of it. [0]
Also, it reverted the change by commit ef7134c7fc48 ("smb: client:
Fix use-after-free of network namespace.") and introduced a real
issue by reviving the kernel TCP socket.
When a reconnect happens for a CIFS connection, the socket state
transitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()
in tcp_close() stops all timers for the socket.
If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1
forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.
Usually, FIN can be retransmitted by the peer, but if the peer aborts
the connection, the issue comes into reality.
I warned about this privately by pointing out the exact report [1],
but the bogus fix was finally merged.
So, we should not stop the timers to finally kill the connection on
our side in that case, meaning we must not use a kernel socket for
TCP whose sk->sk_net_refcnt is 0.
The kernel socket does not have a reference to its netns to make it
possible to tear down netns without cleaning up every resource in it.
For example, tunnel devices use a UDP socket internally, but we can
destroy netns without removing such devices and let it complete
during exit. Otherwise, netns would be leaked when the last application
died.
However, this is problematic for TCP sockets because TCP has timers to
close the connection gracefully even after the socket is close()d. The
lifetime of the socket and its netns is different from the lifetime of
the underlying connection.
If the socket user does not maintain the netns lifetime, the timer could
be fired after the socket is close()d and its netns is freed up, resulting
in use-after-free.
Actually, we have seen so many similar issues and converted such sockets
to have a reference to netns.
That's why I converted the CIFS client socket to have a reference to
netns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope
of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right
fix**.
Regarding the LOCKDEP issue, we can prevent the module unload by
bumping the module refcount when switching the LOCKDDEP key in
sock_lock_init_class_and_name(). [2]
For a while, let's revert the bogus fix.
Note that now we can use sk_net_refcnt_upgrade() for the socket
conversion, but I'll do so later separately to make backport easy. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: vchiq_arm: Fix possible NPR of keep-alive thread
In case vchiq_platform_conn_state_changed() is never called or fails before
driver removal, ka_thread won't be a valid pointer to a task_struct. So
do the necessary checks before calling kthread_stop to avoid a crash. |
| In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: Prevent parser TCAM memory corruption
Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.
Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.
This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't unregister hook when table is dormant
When nf_tables_updchain encounters an error, hook registration needs to
be rolled back.
This should only be done if the hook has been registered, which won't
happen when the table is flagged as dormant (inactive).
Just move the assignment into the registration block. |
| In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak in spufs_create_context()
Leak fixes back in 2008 missed one case - if we are trying to set affinity
and spufs_mkdir() fails, we need to drop the reference to neighbor. |
| In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak on spufs_new_file() failure
It's called from spufs_fill_dir(), and caller of that will do
spufs_rmdir() in case of failure. That does remove everything
we'd managed to create, but... the problem dentry is still
negative. IOW, it needs to be explicitly dropped. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
On the following path, flush_tlb_range() can be used for zapping normal
PMD entries (PMD entries that point to page tables) together with the PTE
entries in the pointed-to page table:
collapse_pte_mapped_thp
pmdp_collapse_flush
flush_tlb_range
The arm64 version of flush_tlb_range() has a comment describing that it can
be used for page table removal, and does not use any last-level
invalidation optimizations. Fix the X86 version by making it behave the
same way.
Currently, X86 only uses this information for the following two purposes,
which I think means the issue doesn't have much impact:
- In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be
IPI'd to avoid issues with speculative page table walks.
- In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
The patch "x86/mm: only invalidate final translations with INVLPGB" which
is currently under review (see
<https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>)
would probably be making the impact of this a lot worse. |
| A vulnerability was found in code-projects E-Commerce Website 1.0. Affected is an unknown function of the file /pages/product_add.php. The manipulation of the argument prod_name/prod_desc/prod_cost results in cross site scripting. It is possible to launch the attack remotely. The exploit has been made public and could be used. |
| In the Linux kernel, the following vulnerability has been resolved:
uprobes/x86: Harden uretprobe syscall trampoline check
Jann reported a possible issue when trampoline_check_ip returns
address near the bottom of the address space that is allowed to
call into the syscall if uretprobes are not set up:
https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf
Though the mmap minimum address restrictions will typically prevent
creating mappings there, let's make sure uretprobe syscall checks
for that. |
| A flaw has been found in SourceCodester Student Grades Management System 1.0. This affects the function delete_user of the file /admin.php. Executing manipulation can lead to cross site scripting. The attack may be performed from remote. The exploit has been published and may be used. |
| A vulnerability was determined in code-projects E-Commerce Website 1.0. Affected by this vulnerability is an unknown functionality of the file /pages/supplier_update.php. This manipulation of the argument supp_name/supp_address causes cross site scripting. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. |
