In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe
Call of_node_put(platform_node) to avoid refcount leak in
the error path.
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: governor: Use kobject release() method to free dbs_data
The struct dbs_data embeds a struct gov_attr_set and
the struct gov_attr_set embeds a kobject. Since every kobject must have
a release() method and we can't use kfree() to free it directly,
so introduce cpufreq_dbs_data_release() to release the dbs_data via
the kobject::release() method. This fixes the calltrace like below:
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34
WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
Modules linked in:
CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536
Hardware name: Marvell OcteonTX CN96XX board (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : debug_print_object+0xb8/0x100
lr : debug_print_object+0xb8/0x100
sp : ffff80001dfcf9a0
x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000
x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210
x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118
x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000
x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8
x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14
x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0
x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001
x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040
Call trace:
debug_print_object+0xb8/0x100
__debug_check_no_obj_freed+0x1d0/0x25c
debug_check_no_obj_freed+0x24/0xa0
kfree+0x11c/0x440
cpufreq_dbs_governor_exit+0xa8/0xac
cpufreq_exit_governor+0x44/0x90
cpufreq_set_policy+0x29c/0x570
store_scaling_governor+0x110/0x154
store+0xb0/0xe0
sysfs_kf_write+0x58/0x84
kernfs_fop_write_iter+0x12c/0x1c0
new_sync_write+0xf0/0x18c
vfs_write+0x1cc/0x220
ksys_write+0x74/0x100
__arm64_sys_write+0x28/0x3c
invoke_syscall.constprop.0+0x58/0xf0
do_el0_svc+0x70/0x170
el0_svc+0x54/0x190
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x1a0/0x1a4
irq event stamp: 189006
hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0
hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0
softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0
softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4
[ rjw: Because can be freed by the gov_attr_set_put() in
cpufreq_dbs_governor_exit() now, it is also necessary to put the
invocation of the governor ->exit() callback into the new
cpufreq_dbs_data_release() function. ]
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: denali: Use managed device resources
All of the resources used by this driver has managed interfaces, so use
them. Otherwise we will get the following splat:
[ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000
[ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5
[ 4.473538] nand: No NAND device found
[ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410
[ 4.475169] #PF: supervisor write access in kernel mode
[ 4.475579] #PF: error_code(0x0002) - not-present page
[ 4.478362] RIP: 0010:iowrite32+0x9/0x50
[ 4.486068] Call Trace:
[ 4.486269] <IRQ>
[ 4.486443] denali_isr+0x15b/0x300 [denali]
[ 4.486788] ? denali_direct_write+0x50/0x50 [denali]
[ 4.487189] __handle_irq_event_percpu+0x161/0x3b0
[ 4.487571] handle_irq_event+0x7d/0x1b0
[ 4.487884] handle_fasteoi_irq+0x2b0/0x770
[ 4.488219] __common_interrupt+0xc8/0x1b0
[ 4.488549] common_interrupt+0x9a/0xc0
In the Linux kernel, the following vulnerability has been resolved:
fbdev: defio: fix the pagelist corruption
Easily hit the below list corruption:
==
list_add corruption. prev->next should be next (ffffffffc0ceb090), but
was ffffec604507edc8. (prev=ffffec604507edc8).
WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26
__list_add_valid+0x53/0x80
CPU: 65 PID: 3959 Comm: fbdev Tainted: G U
RIP: 0010:__list_add_valid+0x53/0x80
Call Trace:
<TASK>
fb_deferred_io_mkwrite+0xea/0x150
do_page_mkwrite+0x57/0xc0
do_wp_page+0x278/0x2f0
__handle_mm_fault+0xdc2/0x1590
handle_mm_fault+0xdd/0x2c0
do_user_addr_fault+0x1d3/0x650
exc_page_fault+0x77/0x180
? asm_exc_page_fault+0x8/0x30
asm_exc_page_fault+0x1e/0x30
RIP: 0033:0x7fd98fc8fad1
==
Figure out the race happens when one process is adding &page->lru into
the pagelist tail in fb_deferred_io_mkwrite(), another process is
re-initializing the same &page->lru in fb_deferred_io_fault(), which is
not protected by the lock.
This fix is to init all the page lists one time during initialization,
it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()
redundantly.
V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)
In the Linux kernel, the following vulnerability has been resolved:
drm/omap: fix NULL but dereferenced coccicheck error
Fix the following coccicheck warning:
./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL
but dereferenced.
Here should be ovl->idx rather than r_ovl->idx.
In the Linux kernel, the following vulnerability has been resolved:
regulator: da9121: Fix uninit-value in da9121_assign_chip_model()
KASAN report slab-out-of-bounds in __regmap_init as follows:
BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841
Read of size 1 at addr ffff88803678cdf1 by task xrun/9137
CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88
print_report.cold+0xcd/0x69b mm/kasan/report.c:313
kasan_report+0x8e/0xc0 mm/kasan/report.c:491
__regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841
__devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266
__devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394
da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039
i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563
This happend when da9121 device is probe by da9121_i2c_id, but with
invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later
da9121_assign_chip_model() will access 'regmap' without init it.
Fix it by return -EINVAL from da9121_assign_chip_model() if
'chip->subvariant_id' is invalid.
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add vblank register/unregister callback functions
We encountered a kernel panic issue that callback data will be NULL when
it's using in ovl irq handler. There is a timing issue between
mtk_disp_ovl_irq_handler() and mtk_ovl_disable_vblank().
To resolve this issue, we use the flow to register/unregister vblank cb:
- Register callback function and callback data when crtc creates.
- Unregister callback function and callback data when crtc destroies.
With this solution, we can assure callback data will not be NULL when
vblank is disable.
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Inhibit aborts if external loopback plug is inserted
After running a short external loopback test, when the external loopback is
removed and a normal cable inserted that is directly connected to a target
device, the system oops in the llpfc_set_rrq_active() routine.
When the loopback was inserted an FLOGI was transmit. As we're looped back,
we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same
wppn thus understand it's a loopback. However, as the ABTS sends address
information the port is not set to (fffffe), the ABTS is dropped on the
wire. A short 1 frame loopback test is run and completes before the ABTS
times out. The looback is unplugged and the new cable plugged in, and the
an FLOGI to the new device occurs and completes. Due to a mixup in ref
counting the completion of the new FLOGI releases the fabric ndlp. Then the
original ABTS completes and references the released ndlp generating the
oops.
Correct by no-op'ing the ABTS when in loopback mode (it will be dropped
anyway). Added a flag to track the mode to recognize when it should be
no-op'd.
In the Linux kernel, the following vulnerability has been resolved:
media: rga: fix possible memory leak in rga_probe
rga->m2m_dev needs to be freed when rga_probe fails.
In the Linux kernel, the following vulnerability has been resolved:
wl1251: dynamically allocate memory used for DMA
With introduction of vmap'ed stacks, stack parameters can no
longer be used for DMA and now leads to kernel panic.
It happens at several places for the wl1251 (e.g. when
accessed through SDIO) making it unuseable on e.g. the
OpenPandora.
We solve this by allocating temporary buffers or use wl1251_read32().
Tested on v5.18-rc5 with OpenPandora.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix null pointer dereferences without iommu
Check if 'aspace' is set before using it as it will stay null without
IOMMU, such as on msm8974.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Check for null pointer of pointer substream before dereferencing it
Pointer substream is being dereferenced on the assignment of pointer card
before substream is being null checked with the macro PCM_RUNTIME_CHECK.
Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the
the pointer check before card is assigned.
In the Linux kernel, the following vulnerability has been resolved:
net: remove two BUG() from skb_checksum_help()
I have a syzbot report that managed to get a crash in skb_checksum_help()
If syzbot can trigger these BUG(), it makes sense to replace
them with more friendly WARN_ON_ONCE() since skb_checksum_help()
can instead return an error code.
Note that syzbot will still crash there, until real bug is fixed.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/hdmi: check return value after calling platform_get_resource_byname()
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value.
Patchwork: https://patchwork.freedesktop.org/patch/482992/
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
And use devm_platform_get_and_ioremap_resource() to simplify code.
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags
In nvme_alloc_admin_tags, the admin_q can be set to an error (typically
-ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which
is checked immediately after the call. However, when we return the error
message up the stack, to nvme_reset_work the error takes us to
nvme_remove_dead_ctrl()
nvme_dev_disable()
nvme_suspend_queue(&dev->queues[0]).
Here, we only check that the admin_q is non-NULL, rather than not
an error or NULL, and begin quiescing a queue that never existed, leading
to bad / NULL pointer dereference.
In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()
It will cause null-ptr-deref in resource_size(), if platform_get_resource()
returns NULL, move calling resource_size() after devm_ioremap_resource() that
will check 'res' to avoid null-ptr-deref.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected
mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring
the modeset lock, but currently mdp5_pipe_release doesn't check for if
an error is returned. Because of this, there is a possibility of
mdp5_pipe_release hitting a NULL dereference error.
To avoid this, let's have mdp5_pipe_release check if
mdp5_get_global_state returns an error and propogate that error.
Changes since v1:
- Separated declaration and initialization of *new_state to avoid
compiler warning
- Fixed some spelling mistakes in commit message
Changes since v2:
- Return 0 in case where hwpipe is NULL as this is considered normal
behavior
- Added 2nd patch in series to fix a similar NULL dereference issue in
mdp5_mixer_release
Patchwork: https://patchwork.freedesktop.org/patch/485179/
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected
There is a possibility for mdp5_get_global_state to return
-EDEADLK when acquiring the modeset lock, but currently global_state in
mdp5_mixer_release doesn't check for if an error is returned.
To avoid a NULL dereference error, let's have mdp5_mixer_release
check if an error is returned and propagate that error.
Patchwork: https://patchwork.freedesktop.org/patch/485181/
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe()
It will cause null-ptr-deref when using 'res', if platform_get_resource()
returns NULL, so move using 'res' after devm_ioremap_resource() that
will check it to avoid null-ptr-deref.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe
of_find_i2c_device_by_node() takes a reference,
In error paths, we should call put_device() to drop
the reference to aviod refount leak.
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Fix null pointer dereference of pointer perfmon
In the unlikely event that pointer perfmon is null the WARN_ON return path
occurs after the pointer has already been deferenced. Fix this by only
dereferencing perfmon after it has been null checked.
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector
Fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector
routine if the chip does not support dbdc and the hw reports band_idx
set to 1.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/disp/dpu1: avoid clearing hw interrupts if hw_intr is null during drm uninit
If edp modeset init is failed due to panel being not ready and
probe defers during drm bind, avoid clearing irqs and dereference
hw_intr when hw_intr is null.
BUG: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Call trace:
dpu_core_irq_uninstall+0x50/0xb0
dpu_irq_uninstall+0x18/0x24
msm_drm_uninit+0xd8/0x16c
msm_drm_bind+0x580/0x5fc
try_to_bring_up_master+0x168/0x1c0
__component_add+0xb4/0x178
component_add+0x1c/0x28
dp_display_probe+0x38c/0x400
platform_probe+0xb0/0xd0
really_probe+0xcc/0x2c8
__driver_probe_device+0xbc/0xe8
driver_probe_device+0x48/0xf0
__device_attach_driver+0xa0/0xc8
bus_for_each_drv+0x8c/0xd8
__device_attach+0xc4/0x150
device_initial_probe+0x1c/0x28
Changes in V2:
- Update commit message and coreect fixes tag.
Patchwork: https://patchwork.freedesktop.org/patch/484430/
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
In the Linux kernel, the following vulnerability has been resolved:
regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt
of_node_get() returns a node with refcount incremented.
Calling of_node_put() to drop the reference when not needed anymore.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: imx-hdmi: Fix refcount leak in imx_hdmi_probe
of_find_device_by_node() takes reference, we should use put_device()
to release it. when devm_kzalloc() fails, it doesn't have a
put_device(), it will cause refcount leak.
Add missing put_device() to fix this.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: samsung: Fix refcount leak in aries_audio_probe
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
If extcon_find_edev_by_node() fails, it doesn't call of_node_put()
Calling of_node_put() after extcon_find_edev_by_node() to fix this.
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname()
It will cause null-ptr-deref if platform_get_resource_byname() returns NULL,
we need check the return value.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_*
of_parse_phandle() 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: phy: micrel: Allow probing without .driver_data
Currently, if the .probe element is present in the phy_driver structure
and the .driver_data is not, a NULL pointer dereference happens.
Allow passing .probe without .driver_data by inserting NULL checks
for priv->type.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix anon_dev leak in create_subvol()
When btrfs_qgroup_inherit(), btrfs_alloc_tree_block, or
btrfs_insert_root() fail in create_subvol(), we return without freeing
anon_dev. Reorganize the error handling in create_subvol() to fix this.
In the Linux kernel, the following vulnerability has been resolved:
thermal/core: Fix memory leak in __thermal_cooling_device_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff888010080000 (size 264312):
comm "182", pid 102533, jiffies 4296434960 (age 10.100s)
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@.......
backtrace:
[<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969
[<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510
[<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586
[<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927
[<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041
[<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211
[<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561
If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called
to free the memory allocated in thermal_cooling_device_setup_sysfs().
In the Linux kernel, the following vulnerability has been resolved:
drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()
drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo
needs to be put when msm_gem_get_and_pin_iova fails.
In the Linux kernel, the following vulnerability has been resolved:
regulator: scmi: Fix refcount leak in scmi_regulator_probe
of_find_node_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe
of_find_node_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
a6xx_gmu_init() passes the node to of_find_device_by_node()
and of_dma_configure(), of_find_device_by_node() will takes its
reference, of_dma_configure() doesn't need the node after usage.
Add missing of_node_put() to avoid refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
amt: fix memory leak for advertisement message
When a gateway receives an advertisement message, it extracts relay
information and then it should be freed.
But the advertisement handler doesn't free it.
So, memory leak would occur.
In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe
platform_get_resource() may return NULL, add proper check to
avoid potential NULL dereferencing.
In the Linux kernel, the following vulnerability has been resolved:
ARM: versatile: Add missing of_node_put in dcscb_init
The device_node pointer is returned by of_find_compatible_node
with refcount incremented. We should use of_node_put() to avoid
the refcount leak.
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix missed rcu protection
When removing the rcu_read_lock in bond_ethtool_get_ts_info() as
discussed [1], I didn't notice it could be called via setsockopt,
which doesn't hold rcu lock, as syzbot pointed:
stack backtrace:
CPU: 0 PID: 3599 Comm: syz-executor317 Not tainted 5.18.0-rc5-syzkaller-01392-g01f4685797a5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
bond_option_active_slave_get_rcu include/net/bonding.h:353 [inline]
bond_ethtool_get_ts_info+0x32c/0x3a0 drivers/net/bonding/bond_main.c:5595
__ethtool_get_ts_info+0x173/0x240 net/ethtool/common.c:554
ethtool_get_phc_vclocks+0x99/0x110 net/ethtool/common.c:568
sock_timestamping_bind_phc net/core/sock.c:869 [inline]
sock_set_timestamping+0x3a3/0x7e0 net/core/sock.c:916
sock_setsockopt+0x543/0x2ec0 net/core/sock.c:1221
__sys_setsockopt+0x55e/0x6a0 net/socket.c:2223
__do_sys_setsockopt net/socket.c:2238 [inline]
__se_sys_setsockopt net/socket.c:2235 [inline]
__x64_sys_setsockopt+0xba/0x150 net/socket.c:2235
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f8902c8eb39
Fix it by adding rcu_read_lock and take a ref on the real_dev.
Since dev_hold() and dev_put() can take NULL these days, we can
skip checking if real_dev exist.
[1] https://lore.kernel.org/netdev/27565.1642742439@famine/
In the Linux kernel, the following vulnerability has been resolved:
PCI: mediatek: Fix refcount leak in mtk_pcie_subsys_powerup()
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
In the Linux kernel, the following vulnerability has been resolved:
soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc
The allocation funciton devm_kcalloc may fail and return a null pointer,
which would cause a null-pointer dereference later.
It might be better to check it and directly return -ENOMEM just like the
usage of devm_kcalloc in previous code.
In the Linux kernel, the following vulnerability has been resolved:
dpaa2-eth: retrieve the virtual address before dma_unmap
The TSO header was DMA unmapped before the virtual address was retrieved
and then used to free the buffer. This meant that we were actually
removing the DMA map and then trying to search for it to help in
retrieving the virtual address. This lead to a invalid virtual address
being used in the kfree call.
Fix this by calling dpaa2_iova_to_virt() prior to the dma_unmap call.
[ 487.231819] Unable to handle kernel paging request at virtual address fffffd9807000008
(...)
[ 487.354061] Hardware name: SolidRun LX2160A Honeycomb (DT)
[ 487.359535] pstate: a0400005 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 487.366485] pc : kfree+0xac/0x304
[ 487.369799] lr : kfree+0x204/0x304
[ 487.373191] sp : ffff80000c4eb120
[ 487.376493] x29: ffff80000c4eb120 x28: ffff662240c46400 x27: 0000000000000001
[ 487.383621] x26: 0000000000000001 x25: ffff662246da0cc0 x24: ffff66224af78000
[ 487.390748] x23: ffffad184f4ce008 x22: ffffad1850185000 x21: ffffad1838d13cec
[ 487.397874] x20: ffff6601c0000000 x19: fffffd9807000000 x18: 0000000000000000
[ 487.405000] x17: ffffb910cdc49000 x16: ffffad184d7d9080 x15: 0000000000004000
[ 487.412126] x14: 0000000000000008 x13: 000000000000ffff x12: 0000000000000000
[ 487.419252] x11: 0000000000000004 x10: 0000000000000001 x9 : ffffad184d7d927c
[ 487.426379] x8 : 0000000000000000 x7 : 0000000ffffffd1d x6 : ffff662240a94900
[ 487.433505] x5 : 0000000000000003 x4 : 0000000000000009 x3 : ffffad184f4ce008
[ 487.440632] x2 : ffff662243eec000 x1 : 0000000100000100 x0 : fffffc0000000000
[ 487.447758] Call trace:
[ 487.450194] kfree+0xac/0x304
[ 487.453151] dpaa2_eth_free_tx_fd.isra.0+0x33c/0x3e0 [fsl_dpaa2_eth]
[ 487.459507] dpaa2_eth_tx_conf+0x100/0x2e0 [fsl_dpaa2_eth]
[ 487.464989] dpaa2_eth_poll+0xdc/0x380 [fsl_dpaa2_eth]
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix list protocols enumeration in the base protocol
While enumerating protocols implemented by the SCMI platform using
BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is
currently validated in an improper way since the check employs a sum
between unsigned integers that could overflow and cause the check itself
to be silently bypassed if the returned value 'loop_num_ret' is big
enough.
Fix the validation avoiding the addition.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump
up the sysctl), but whilst the preallocation circular buffers have 32 slots
in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket
is closed because rxrpc_service_prealloc_one() allocated one too many calls
and rxrpc_discard_prealloc() won't then be able to get rid of them because
it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries
to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match
the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086
...
RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace:
<TASK>
? __wake_up_common_lock+0x7a/0x90
? rxrpc_notify_socket+0x8e/0x140 [rxrpc]
? rxrpc_abort_call+0x4c/0x60 [rxrpc]
rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]
rxrpc_release+0xc9/0x1c0 [rxrpc]
__sock_release+0x37/0xa0
sock_close+0x11/0x20
__fput+0x89/0x240
task_work_run+0x59/0x90
do_exit+0x319/0xaa0