| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7615: fix memory leak in mt7615_coredump_work
Similar to the issue fixed in mt7921_coredump_work, fix a possible memory
leak in mt7615_coredump_work routine. |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: connac: fix kernel warning adding monitor interface
Fix the following kernel warning adding a monitor interface in
mt76_connac_mcu_uni_add_dev routine.
[ 507.984882] ------------[ cut here ]------------
[ 507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[ 508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0
[ 508.065461] Hardware name: MT7622_MT7531 RFB (DT)
[ 508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[ 508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[ 508.087367] sp : ffffffc013a33930
[ 508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0
[ 508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008
[ 508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610
[ 508.106577] x23: ffffff801d022990 x22: ffffff801d024de8
[ 508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8
[ 508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000
[ 508.122482] x17: 00000000ffffffff x16: 0000000000000000
[ 508.127785] x15: 0000000000000080 x14: ffffff801d704000
[ 508.133087] x13: 0000000000000040 x12: 0000000000000002
[ 508.138389] x11: 000000000000000c x10: 0000000000000000
[ 508.143691] x9 : 0000000000000020 x8 : 0000000000000001
[ 508.148992] x7 : 0000000000000000 x6 : 0000000000000000
[ 508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006
[ 508.159596] x3 : 0000000000000001 x2 : 0000000000000000
[ 508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0
[ 508.170200] Call trace:
[ 508.172640] mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[ 508.179159] mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[ 508.184394] drv_add_interface+0x34/0x88 [mac80211]
[ 508.189271] ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211]
[ 508.195277] ieee80211_do_open+0x86c/0x918 [mac80211]
[ 508.200328] ieee80211_do_open+0x900/0x918 [mac80211]
[ 508.205372] __dev_open+0xcc/0x150
[ 508.208763] __dev_change_flags+0x134/0x198
[ 508.212937] dev_change_flags+0x20/0x60
[ 508.216764] devinet_ioctl+0x3e8/0x748
[ 508.220503] inet_ioctl+0x1e4/0x350
[ 508.223983] sock_do_ioctl+0x48/0x2a0
[ 508.227635] sock_ioctl+0x310/0x4f8
[ 508.231116] do_vfs_ioctl+0xa4/0xac0
[ 508.234681] ksys_ioctl+0x44/0x90
[ 508.237985] __arm64_sys_ioctl+0x1c/0x48
[ 508.241901] el0_svc_common.constprop.1+0x7c/0x100
[ 508.246681] el0_svc_handler+0x18/0x20
[ 508.250421] el0_svc+0x8/0x1c8
[ 508.253465] ---[ end trace c7b90fee13d72c39 ]---
[ 508.261278] ------------[ cut here ]------------ |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix txrate reporting
Properly check rate_info to fix unexpected reporting.
[ 1215.161863] Call trace:
[ 1215.164307] cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]
[ 1215.170139] ieee80211s_update_metric+0x80/0xc0 [mac80211]
[ 1215.175624] ieee80211_tx_status_ext+0x508/0x838 [mac80211]
[ 1215.181190] mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]
[ 1215.186580] mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]
[ 1215.191623] mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]
[ 1215.196582] mt76_dma_cleanup+0x7b0/0x11d0 [mt76]
[ 1215.201276] __napi_poll+0x38/0xf8
[ 1215.204668] napi_workfn+0x40/0x80
[ 1215.208062] process_one_work+0x1fc/0x390
[ 1215.212062] worker_thread+0x48/0x4d0
[ 1215.215715] kthread+0x120/0x128
[ 1215.218935] ret_from_fork+0x10/0x1c |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix kernel crash when the firmware fails to download
Fix kernel crash when the firmware is missing or fails to download.
[ 9.444758] kernel BUG at drivers/pci/msi.c:375!
[ 9.449363] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 9.501033] pstate: a0400009 (NzCv daif +PAN -UAO)
[ 9.505814] pc : free_msi_irqs+0x180/0x184
[ 9.509897] lr : free_msi_irqs+0x40/0x184
[ 9.513893] sp : ffffffc015193870
[ 9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2
[ 9.522492] x27: 0000000000000acd x26: 000000000000009a
[ 9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8
[ 9.533087] x23: ffffffdbb38628d0 x22: 0000000000040200
[ 9.538384] x21: ffffff8cf7de7318 x20: ffffff8cd65a2480
[ 9.543681] x19: ffffff8cf7de7000 x18: 0000000000000000
[ 9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34
[ 9.554277] x15: 0000000000000000 x14: 0000000000080800
[ 9.559575] x13: ffffff8cd65a2980 x12: 0000000000000000
[ 9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45d6d0
[ 9.570171] x9 : 0000000000000040 x8 : ffffff8ccef1b780
[ 9.575469] x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000
[ 9.580766] x5 : ffffffdc13824900 x4 : ffffff8ccefe0000
[ 9.586063] x3 : 0000000000000000 x2 : 0000000000000000
[ 9.591362] x1 : 0000000000000125 x0 : ffffff8ccefe0000
[ 9.596660] Call trace:
[ 9.599095] free_msi_irqs+0x180/0x184
[ 9.602831] pci_disable_msi+0x100/0x130
[ 9.606740] pci_free_irq_vectors+0x24/0x30
[ 9.610915] mt7921_pci_probe+0xbc/0x250 [mt7921e]
[ 9.615693] pci_device_probe+0xd4/0x14c
[ 9.619604] really_probe+0x134/0x2ec
[ 9.623252] driver_probe_device+0x64/0xfc
[ 9.627335] device_driver_attach+0x4c/0x6c
[ 9.631506] __driver_attach+0xac/0xc0
[ 9.635243] bus_for_each_dev+0x8c/0xd4
[ 9.639066] driver_attach+0x2c/0x38
[ 9.642628] bus_add_driver+0xfc/0x1d0
[ 9.646365] driver_register+0x64/0xf8
[ 9.650101] __pci_register_driver+0x6c/0x7c
[ 9.654360] init_module+0x28/0xfdc [mt7921e]
[ 9.658704] do_one_initcall+0x13c/0x2d0
[ 9.662615] do_init_module+0x58/0x1e8
[ 9.666351] load_module+0xd80/0xeb4
[ 9.669912] __arm64_sys_finit_module+0xa8/0xe0
[ 9.674430] el0_svc_common+0xa4/0x16c
[ 9.678168] el0_svc_compat_handler+0x2c/0x40
[ 9.682511] el0_svc_compat+0x8/0x10
[ 9.686076] Code: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000)
[ 9.692155] ---[ end trace 7621f966afbf0a29 ]---
[ 9.697385] Kernel panic - not syncing: Fatal exception
[ 9.702599] SMP: stopping secondary CPUs
[ 9.706549] Kernel Offset: 0x1c03600000 from 0xffffffc010000000
[ 9.712456] PHYS_OFFSET: 0xfffffff440000000
[ 9.716625] CPU features: 0x080026,2a80aa18
[ 9.720795] Memory Limit: none |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-clt: destroy sysfs after removing session from active list
A session can be removed dynamically by sysfs interface "remove_path" that
eventually calls rtrs_clt_remove_path_from_sysfs function. The current
rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and
frees sess->stats object. Second it removes the session from the active
list.
Therefore some functions could access non-connected session and access the
freed sess->stats object even-if they check the session status before
accessing the session.
For instance rtrs_clt_request and get_next_path_min_inflight check the
session status and try to send IO to the session. The session status
could be changed when they are trying to send IO but they could not catch
the change and update the statistics information in sess->stats object,
and generate use-after-free problem.
(see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its
stats")
This patch changes the rtrs_clt_remove_path_from_sysfs to remove the
session from the active session list and then destroy the sysfs
interfaces.
Each function still should check the session status because closing or
error recovery paths can change the status. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Always enable the clk on resume
In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:
[ 1.586104] infra_m4u already disabled
[ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[ 1.598108] Modules linked in:
[ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[ 1.617487] Hardware name: Google Elm (DT)
[ 1.617491] Workqueue: pm pm_runtime_work
[ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)
[ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 1.659297] pc : clk_core_disable+0xb0/0xb8
[ 1.663475] lr : clk_core_disable+0xb0/0xb8
[ 1.667652] sp : ffff800011b9bbe0
[ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
[ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
[ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
[ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90
[ 1.692189] x21: 000000000000000a x20: ffff0000c0048500
[ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[ 1.702804] x17: 0000000000000000 x16: 0000000000000000
[ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000
[ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720
[ 1.718727] x11: 0720072007200720 x10: 0720072007200720
[ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
[ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
[ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
[ 1.750572] Call trace:
[ 1.753010] clk_core_disable+0xb0/0xb8
[ 1.756840] clk_core_disable_lock+0x24/0x40
[ 1.761105] clk_disable+0x20/0x30
[ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8
[ 1.769114] pm_generic_runtime_suspend+0x2c/0x48
[ 1.773815] __rpm_callback+0xe0/0x178
[ 1.777559] rpm_callback+0x24/0x88
[ 1.781041] rpm_suspend+0xdc/0x470
[ 1.784523] rpm_idle+0x12c/0x170
[ 1.787831] pm_runtime_work+0xa8/0xc0
[ 1.791573] process_one_work+0x1e8/0x360
[ 1.795580] worker_thread+0x44/0x478
[ 1.799237] kthread+0x150/0x158
[ 1.802460] ret_from_fork+0x10/0x30
[ 1.806034] ---[ end trace 82402920ef64573b ]---
[ 1.810728] ------------[ cut here ]------------
In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume. |
| In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: fix port event handling on init
For some reason there might be a crash during ports creation if port
events are handling at the same time because fw may send initial
port event with down state.
The crash points to cancel_delayed_work() which is called when port went
is down. Currently I did not find out the real cause of the issue, so
fixed it by cancel port stats work only if previous port's state was up
& runnig.
The following is the crash which can be triggered:
[ 28.311104] Unable to handle kernel paging request at virtual address
000071775f776600
[ 28.319097] Mem abort info:
[ 28.321914] ESR = 0x96000004
[ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits
[ 28.330350] SET = 0, FnV = 0
[ 28.333430] EA = 0, S1PTW = 0
[ 28.336597] Data abort info:
[ 28.339499] ISV = 0, ISS = 0x00000004
[ 28.343362] CM = 0, WnR = 0
[ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000
[ 28.352842] [000071775f776600] pgd=0000000000000000,
p4d=0000000000000000
[ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 28.365310] Modules linked in: prestera_pci(+) prestera
uio_pdrv_genirq
[ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted
5.11.0-rc4 #1
[ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT)
[ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn
[prestera_pci]
[ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 28.397468] pc : get_work_pool+0x48/0x60
[ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0
[ 28.406018] sp : ffff80001391bc60
[ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000
[ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88
[ 28.420089] x25: 0000000000000000 x24: ffff000106119760
[ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000
[ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0
[ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0
[ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88
[ 28.446898] x15: 0000000000000001 x14: 00000000000002ba
[ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4
[ 28.457622] x11: 0000000000000030 x10: 000000000000000c
[ 28.462985] x9 : 000000000000000c x8 : 0000000000000030
[ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758
[ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60
[ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060
[ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8
[ 28.489791] Call trace:
[ 28.492259] get_work_pool+0x48/0x60
[ 28.495874] cancel_delayed_work+0x38/0xb0
[ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera]
[ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera]
[ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci]
[ 28.516660] process_one_work+0x1e8/0x360
[ 28.520710] worker_thread+0x44/0x480
[ 28.524412] kthread+0x154/0x160
[ 28.527670] ret_from_fork+0x10/0x38
[ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020)
[ 28.537429] ---[ end trace 5eced933df3a080b ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7615: fix memleak when mt7615_unregister_device()
mt7615_tx_token_put() should get call before mt76_free_pending_txwi(). |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix memleak when mt7915_unregister_device()
mt7915_tx_token_put() should get call before mt76_free_pending_txwi(). |
| In the Linux kernel, the following vulnerability has been resolved:
soundwire: stream: fix memory leak in stream config error path
When stream config is failed, master runtime will release all
slave runtime in the slave_rt_list, but slave runtime is not
added to the list at this time. This patch frees slave runtime
in the config error path to fix the memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix possible invalid register access
Disable the interrupt and synchronze for the pending irq handlers to ensure
the irq tasklet is not being scheduled after the suspend to avoid the
possible invalid register access acts when the host pcie controller is
suspended.
[17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs
[17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00
[17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs
[17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc
[17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs
...
17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300
[17933.620666] Call trace:
[17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76]
[17933.627234] mt7921_rr+0x38/0x44 [mt7921e]
[17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e]
[17933.636309] tasklet_action_common+0x12c/0x16c
[17933.640754] tasklet_action+0x24/0x2c
[17933.644418] __do_softirq+0x16c/0x344
[17933.648082] irq_exit+0xa8/0xac
[17933.651224] scheduler_ipi+0xd4/0x148
[17933.654890] handle_IPI+0x164/0x2d4
[17933.658379] gic_handle_irq+0x140/0x178
[17933.662216] el1_irq+0xb8/0x180
[17933.665361] cpuidle_enter_state+0xf8/0x204
[17933.669544] cpuidle_enter+0x38/0x4c
[17933.673122] do_idle+0x1a4/0x2a8
[17933.676352] cpu_startup_entry+0x24/0x28
[17933.680276] rest_init+0xd4/0xe0
[17933.683508] arch_call_rest_init+0x10/0x18
[17933.687606] start_kernel+0x340/0x3b4
[17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113)
[17933.697373] ---[ end trace a24b8e26ffbda3c5 ]---
[17933.767846] Kernel panic - not syncing: Fatal exception in interrupt |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/64: Fix the definition of the fixmap area
At the time being, the fixmap area is defined at the top of
the address space or just below KASAN.
This definition is not valid for PPC64.
For PPC64, use the top of the I/O space.
Because of circular dependencies, it is not possible to include
asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size
AREA at the top of the I/O space for fixmap and ensure during
build that the size is big enough. |
| In the Linux kernel, the following vulnerability has been resolved:
ath10k: Fix a use after free in ath10k_htc_send_bundle
In ath10k_htc_send_bundle, the bundle_skb could be freed by
dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later
by bundle_skb->len.
As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to
skb_len after the bundle_skb was freed. |
| In the Linux kernel, the following vulnerability has been resolved:
m68k: mvme147,mvme16x: Don't wipe PCC timer config bits
Don't clear the timer 1 configuration bits when clearing the interrupt flag
and counter overflow. As Michael reported, "This results in no timer
interrupts being delivered after the first. Initialization then hangs
in calibrate_delay as the jiffies counter is not updated."
On mvme16x, enable the timer after requesting the irq, consistent with
mvme147. |
| In the Linux kernel, the following vulnerability has been resolved:
net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send
In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
If some error happens in emac_tx_fill_tpd(), the skb will be freed via
dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).
As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,
thus my patch assigns skb->len to 'len' before the possible free and
use 'len' instead of skb->len later. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix a use after free in siw_alloc_mr
Our code analyzer reported a UAF.
In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of
siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via
kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a
freed object. After, the execution continue up to the err_out branch of
siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr).
My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {}
section, to avoid the uaf. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: memcontrol: slab: fix obtain a reference to a freeing memcg
Patch series "Use obj_cgroup APIs to charge kmem pages", v5.
Since Roman's series "The new cgroup slab memory controller" applied.
All slab objects are charged with the new APIs of obj_cgroup. The new
APIs introduce a struct obj_cgroup to charge slab objects. It prevents
long-living objects from pinning the original memory cgroup in the
memory. But there are still some corner objects (e.g. allocations
larger than order-1 page on SLUB) which are not charged with the new
APIs. Those objects (include the pages which are allocated from buddy
allocator directly) are charged as kmem pages which still hold a
reference to the memory cgroup.
E.g. We know that the kernel stack is charged as kmem pages because the
size of the kernel stack can be greater than 2 pages (e.g. 16KB on
x86_64 or arm64). If we create a thread (suppose the thread stack is
charged to memory cgroup A) and then move it from memory cgroup A to
memory cgroup B. Because the kernel stack of the thread hold a
reference to the memory cgroup A. The thread can pin the memory cgroup
A in the memory even if we remove the cgroup A. If we want to see this
scenario by using the following script. We can see that the system has
added 500 dying cgroups (This is not a real world issue, just a script
to show that the large kmallocs are charged as kmem pages which can pin
the memory cgroup in the memory).
#!/bin/bash
cat /proc/cgroups | grep memory
cd /sys/fs/cgroup/memory
echo 1 > memory.move_charge_at_immigrate
for i in range{1..500}
do
mkdir kmem_test
echo $$ > kmem_test/cgroup.procs
sleep 3600 &
echo $$ > cgroup.procs
echo `cat kmem_test/cgroup.procs` > cgroup.procs
rmdir kmem_test
done
cat /proc/cgroups | grep memory
This patchset aims to make those kmem pages to drop the reference to
memory cgroup by using the APIs of obj_cgroup. Finally, we can see that
the number of the dying cgroups will not increase if we run the above test
script.
This patch (of 7):
The rcu_read_lock/unlock only can guarantee that the memcg will not be
freed, but it cannot guarantee the success of css_get (which is in the
refill_stock when cached memcg changed) to memcg.
rcu_read_lock()
memcg = obj_cgroup_memcg(old)
__memcg_kmem_uncharge(memcg)
refill_stock(memcg)
if (stock->cached != memcg)
// css_get can change the ref counter from 0 back to 1.
css_get(&memcg->css)
rcu_read_unlock()
This fix is very like the commit:
eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge")
Fix this by holding a reference to the memcg which is passed to the
__memcg_kmem_uncharge() before calling __memcg_kmem_uncharge(). |
| In the Linux kernel, the following vulnerability has been resolved:
net: Only allow init netns to set default tcp cong to a restricted algo
tcp_set_default_congestion_control() is netns-safe in that it writes
to &net->ipv4.tcp_congestion_control, but it also sets
ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced.
This has the unintended side-effect of changing the global
net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it
is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control
readonly in non-init netns")
Resolve this netns "leak" by only allowing the init netns to set the
default algorithm to one that is restricted. This restriction could be
removed if tcp_allowed_congestion_control were namespace-ified in the
future.
This bug was uncovered with
https://github.com/JonathonReinhart/linux-netns-sysctl-verify |
| In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix memory leak on object td
Two error return paths are neglecting to free allocated object td,
causing a memory leak. Fix this by returning via the error return
path that securely kfree's td.
Fixes clang scan-build warning:
security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential
memory leak [unix.Malloc] |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Make sure GHCB is mapped before updating
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB might not be mapped (depending on the previous VMEXIT),
which will result in a NULL pointer dereference.
The svm_complete_emulated_msr() routine will update the GHCB to inform
the caller of a RDMSR/WRMSR operation about any errors. While it is likely
that the GHCB will be mapped in this situation, add a safe guard
in this path to be certain a NULL pointer dereference is not encountered. |
