When checking for a potential UMIP violation on #GP, verify the decoder found
at least two opcode bytes to avoid false positives when the kernel encounters
an unknown instruction that starts with 0f. Because the array of opcode.bytes
is zero-initialized by insn_init(), peeking at bytes[1] will misinterpret
garbage as a potential SLDT or STR instruction, and can incorrectly trigger
emulation.
E.g. if a VPALIGNR instruction
62 83 c5 05 0f 08 ff vpalignr xmm17{k5},xmm23,XMMWORD PTR [r8],0xff
hits a #GP, the kernel emulates it as STR and squashes the #GP (and corrupts
the userspace code stream).
Arguably the check should look for exactly two bytes, but no three byte
opcodes use '0f 00 xx' or '0f 01 xx' as an escape, i.e. it should be
impossible to get a false positive if the first two opcode bytes match '0f 00'
or '0f 01'. Go with a more conservative check with respect to the existing
code to minimize the chances of breaking userspace, e.g. due to decoder
weirdness.
Analyzed by Nick Bray <ncbray@google.com>.
Fixes: 1e5db22369 ("x86/umip: Add emulation code for UMIP instructions")
Reported-by: Dan Snyder <dansnyder@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Stefan Mätje <stefan.maetje@esd.eu> says:
The first patch makes some error messages also print the error
code to achieve a higher significance. Removes also a duplicate
message and makes the register / unregister messages symmetric.
The second patch avoids emitting any error messages during the
disconnect of CAN-USB devices or the driver unload.
Changes in v2:
- Second patch:
- Convert all occurrences of error status prints to use
"ERR_PTR(err)" instead of printing the decimal value
of "err".
- Rename retval to err in esd_usb_read_bulk_callback() to
make the naming of error status variables consistent
with all other functions.
Link: https://patch.msgid.link/20250821143422.3567029-1-stefan.maetje@esd.eu
[mkl: only take paches 4+5, which are new features, adjust cover letter accordingly]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The kernel linear mapping is painted in very early stage of system boot.
The cpufeature has not been finalized yet at this point. So the linear
mapping is determined by the capability of boot CPU only. If the boot
CPU supports BBML2, large block mappings will be used for linear
mapping.
But the secondary CPUs may not support BBML2, so repaint the linear
mapping if large block mapping is used and the secondary CPUs don't
support BBML2 once cpufeature is finalized on all CPUs.
If the boot CPU doesn't support BBML2 or the secondary CPUs have the
same BBML2 capability with the boot CPU, repainting the linear mapping
is not needed.
Repainting is implemented by the boot CPU, which we know supports BBML2,
so it is safe for the live mapping size to change for this CPU. The
linear map region is walked using the pagewalk API and any discovered
large leaf mappings are split to pte mappings using the existing helper
functions. Since the repainting is performed inside of a stop_machine(),
we must use GFP_ATOMIC to allocate the extra intermediate pgtables. But
since we are still early in boot, it is expected that there is plenty of
memory available so we will never need to sleep for reclaim, and so
GFP_ATOMIC is acceptable here.
The secondary CPUs are all put into a waiting area with the idmap in
TTBR0 and reserved map in TTBR1 while this is performed since they
cannot be allowed to observe any size changes on the live mappings. Some
of this infrastructure is reused from the kpti case. Specifically we
share the same flag (was __idmap_kpti_flag, now idmap_kpti_bbml2_flag)
since it means we don't have to reserve any extra pgtable memory to
idmap the extra flag.
Co-developed-by: Yang Shi <yang@os.amperecomputing.com>
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
cdns_pcie::ops might not be populated by all the Cadence glue drivers. This
is going to be true for the upcoming Sophgo platform which doesn't set the
ops.
Hence, add a check to prevent NULL pointer dereference.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
[mani: reworded subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com
The USB stack calls during disconnect the esd_usb_disconnect() callback.
esd_usb_disconnect() calls netdev_unregister() for each network which
in turn calls the net_device_ops::ndo_stop callback esd_usb_close() if
the net device is up.
The esd_usb_close() callback tries to disable all CAN Ids and to reset
the CAN controller of the device sending appropriate control messages.
Sending these messages in .disconnect() is moot and always fails because
either the device is gone or the USB communication is already torn down
by the USB stack in the course of a rmmod operation.
Move the code that sends these control messages to a new function
esd_usb_stop() which is approximately the counterpart of
esd_usb_start() to make code structure less convoluted.
Then change esd_usb_close() not to send the control messages at all if
the ndo_stop() callback is executed from the USB .disconnect()
callback. Add a new flag in_usb_disconnect to the struct esd_usb
device structure to mark this condition which is checked by
esd_usb_close() whether to skip the send operations in esd_usb_start().
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Link: https://patch.msgid.link/20250821143422.3567029-6-stefan.maetje@esd.eu
[mkl: minor change patch description to imperative language]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
- esd_usb_open(): Get rid of duplicate "couldn't start device: %d\n"
message already printed from esd_usb_start().
- Fix duplicate printout of network device name when network device
is registered. Add an unregister message for the network device
as counterpart to the register message.
- Add the printout of error codes together with the error messages
in esd_usb_close() and some in esd_usb_probe(). The additional error
codes should lead to a better understanding what is really going
wrong.
- Convert all occurrences of error status prints to use "ERR_PTR(err)"
instead of printing the decimal value of "err".
- Rename retval to err in esd_usb_read_bulk_callback() to make the
naming of error status variables consistent with all other functions.
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Link: https://patch.msgid.link/20250821143422.3567029-5-stefan.maetje@esd.eu
[mkl: minor change patch description to imperative language]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
- mvsdio: Fix dma_unmap_sg() nents value
- sdhci: Fix clock management for UHS-II
- sdhci-pci-gli: Fix initialization of UHS-II for GL9767
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmjNMrgXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCkARg//Uhtnaqiy7KN2fxmV7Pa181O6
YN0TvjDBFT2vtChZFwJWAKrDjMphrRRf0yEcvF6u7O/BKQJEDjzM6A5cDs2rw4sZ
6uQuVAf8o1WaFdlz1M9mI+YFi4gHMhjuuJ6PtcphfT59GrN9T4qJZZY7hxs2xFVl
RX7Jxe9Nuye+fKhs0fdyA/aiRiWLW3p31pTglnCtPeUNvUBl99TQWTDHgOKRoqsT
ZuXespd8MZQqodIAQAOA2YoiL8/9kw+PZHU/TC9GyMCeQ4NPBHbarkp+1Kc2yZFW
WKkUdH+BJ8L6vco6lXXPBWU3eI3dpr6dyEtPcZ7tHVL52UK7jcO4o/wN4uj1uajG
SkfAHG8QFFeNYbSLZojwZ0ATKnqVA8HJwvVV6MYqThSZ1CLPYQfckoAihHuKnX5G
18g9oEXlb7tgEAZdoflHJxfYNWQMNI6WKIYuD/MiN4CHMEuZehLIVT/GdfnFw+bS
t3/PTz793KP5GXp9dxK4eysPdMBVBOUiy+PEEd/UmlePXChWvfFZnYp2tYvUX6MF
xCPblVUAiEiPqJum/6G9q3Mjia8NzfPVUZ+iGs0+1ioQA+I9VRk71S77Ber9yxFy
LIJY1oMNZcMAKwPHNgdVRC0GrJlgDFz9X5QMxPZDYdO7WiQNUFzUGdHeoMoJzMTV
gwzG8DwY0bRcy+SiHAg=
=+dn4
-----END PGP SIGNATURE-----
Merge tag 'mmc-v6.17-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC host fixes from Ulf Hansson:
- mvsdio: Fix dma_unmap_sg() nents value
- sdhci: Fix clock management for UHS-II
- sdhci-pci-gli: Fix initialization of UHS-II for GL9767
* tag 'mmc-v6.17-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-pci-gli: GL9767: Fix initializing the UHS-II interface during a power-on
mmc: sdhci-uhs2: Fix calling incorrect sdhci_set_clock() function
mmc: sdhci: Move the code related to setting the clock from sdhci_set_ios_common() into sdhci_set_ios()
mmc: mvsdio: Fix dma_unmap_sg() nents value
Add the newly introduced Arm C1-Nano/Pro/Premium/Ultra core and PMU
compatible strings. These cores are part of the Lumex CSS. The new names
are replacing the long lived Cortex-A/X branding going forward.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Currently, users of Mediatek UFOe (Unified Frame Optimization engine) DT
bindings set mediatek,gce-client-reg node property, which is missing from
the DT schema.
For example, device tree arch/arm64/boot/dts/mediatek/mt8173.dtsi is
causing the following dtb check error:
arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: ufoe@1401a000 (mediatek,mt8173-disp-ufoe): 'mediatek,gce-client-reg' does not match any of the regexes: '^pinctrl-[0-9]+$'
This commit adds the missing node property in the DT schema and updates the
example as well.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250911151001.108744-7-ariel.dalessandro@collabora.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Currently, users of Mediatek OD (display overdrive) DT bindings set
mediatek,gce-client-reg node property, which is missing from the DT schema.
For example, device tree arch/arm64/boot/dts/mediatek/mt8173.dtsi is
causing the following dtb check error:
arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: od@14023000 (mediatek,mt8173-disp-od): 'mediatek,gce-client-reg' does not match any of the regexes: '^pinctrl-[0-9]+$'
This commit adds the missing node property in the DT schema and updates the
example as well.
Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Link: https://lore.kernel.org/r/20250911151001.108744-6-ariel.dalessandro@collabora.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the APM XGene EDAC binding to DT schema. Add the missing
"apm,xgene-edac-soc" compatible, and drop the unused
"apm,xgene-edac-pmd-v2" compatible.
Link: https://lore.kernel.org/r/20250828223023.2409337-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the Marvell Armada AP80x/CP110 thermal binding to schema. It is
a straight forward conversion.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20250822225701.766947-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the Marvell Armada 3xx/XP thermal binding to schema.
Drop the AP80x and CP110 as they have long been deprecated and have
been replaced by a new binding.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20250822225645.766397-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Convert the rockchip,rk3368-mailbox binding to DT schema format. Add
the missing 'clocks' and 'clock-names' properties. Document that it's
one interrupt per mailbox channel (and there are 4 channels).
Link: https://lore.kernel.org/r/20250812181348.62137-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
"moxa,moxart-watchdog" is already documented in faraday,ftwdt010.yaml,
so drop the old text binding.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 289660a4af ("dt-bindings: watchdog: convert faraday,ftwdt010 to yaml")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250807214222.4170236-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
If alloc_candev() failed due to out-of-memory, the core memory
allocation code has already printed an error message.
If alloc_candev() failed for a different reason, alloc_netdev_mqs() has
already printed an error message.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/2d6ad4be211a35492570fd7219ca7a89b384bfad.1755857536.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Convert CAN Mailbox Register field accesses to use the FIELD_PREP() and
FIELD_GET() bitfield access macro.
This gets rid of explicit shifts, and keeps a clear separation between
hardware register layouts and offical CAN definitions.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/c75c7d6ed5929c4becf7c9178cec04a0731e8ab1.1755857536.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Convert CAN Bit Configuration Register field accesses to use the
FIELD_PREP() bitfield access macro. While at it, fix the misspelling of
BRP.
This gets rid of custom function-like field preparation macros.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/01cfaedba2be22515ba8700893ea7f113df959c0.1755857536.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Convert CAN Control Register field accesses to use the FIELD_PREP()
bitfield access macro. Add a few more comments and definitions while at
it.
This gets rid of explicit (and sometimes confusing) shifts.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/077640e31949dc3c9d128a08ade94c9e9cd25672.1755857536.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmjMFIQWHGNoZW5odWFj
YWlAa2VybmVsLm9yZwAKCRAChivD8uImeljpD/9U5QOKD2EpTpRJ2gaOxvAQe3r7
GRqA8Y5wSHDL//eg3/gyDi/uWkS69boHxkEGqGpfeeXLBH/nR3/6r41DJ44PIwqE
FW5foMmwZbGHzyo9jqmoyXU+TfF4yJX09YOvGWsZAnhuE7li3UndWzm07B/tfzMP
xKh8+dOz/5BsoORw9hPym3/4QtpKEnpkUpvFBoJ0dcG3YSk7+1lotIfPrc0X9zSm
GbP46P/X4Cz5cgnNADajuPr3O856yZadqAAfi1+gUF85G9y92TwjcloWif5LtQtu
1JdonjW51x6RlS+uBr4VW0Il6X1US1Rs058TmoiIDf+lRPpYVuGmBX4Ekxp3D92j
09hnZEoSs1cxwDdMM0fttJpmS7IZEA28tJiO+20CRk3EuvBKGPNdXsQ+169OHDD9
/jnGA8ksukCN6e1UBsjA0VzxNUTT5u0cw9sXMVaQcfCWzIa2J8PtRMLoJEtDeJ7/
gXSrPtk6a9AK6QcgX5MGAlMtR+HJnZTCSJBv/i7T0E743BdWClwBq5RgTfklFHTw
FXEFUX1RbgIdi4CyqZ+ilwbpIah8+7BdIK5NMNALojsLEWM5y6v88PPOIz9hsdqp
PgxQKGxZh00p04WWJun3DmIO4KNvn+AYM/uMpd4TCa9Rtqi+hrm2pBDS+9K4hHDi
mT+7ZweDnRX8YPt44Q==
=aJ23
-----END PGP SIGNATURE-----
Merge tag 'loongarch-fixes-6.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
Pull LoongArch fixes from Huacai Chen:
"Fix some build warnings for RUST-enabled objtool check, align ACPI
structures for ARCH_STRICT_ALIGN, fix an unreliable stack for live
patching, add some NULL pointer checkings, and fix some bugs around
KVM"
* tag 'loongarch-fixes-6.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
LoongArch: KVM: Avoid copy_*_user() with lock hold in kvm_pch_pic_regs_access()
LoongArch: KVM: Avoid copy_*_user() with lock hold in kvm_eiointc_sw_status_access()
LoongArch: KVM: Avoid copy_*_user() with lock hold in kvm_eiointc_regs_access()
LoongArch: KVM: Avoid copy_*_user() with lock hold in kvm_eiointc_ctrl_access()
LoongArch: KVM: Fix VM migration failure with PTW enabled
LoongArch: KVM: Remove unused returns and semicolons
LoongArch: vDSO: Check kcalloc() result in init_vdso()
LoongArch: Fix unreliable stack for live patching
LoongArch: Replace sprintf() with sysfs_emit()
LoongArch: Check the return value when creating kobj
LoongArch: Align ACPI structures if ARCH_STRICT_ALIGN enabled
LoongArch: Update help info of ARCH_STRICT_ALIGN
LoongArch: Handle jump tables options for RUST
LoongArch: Make LTO case independent in Makefile
objtool/LoongArch: Mark special atomic instruction as INSN_BUG type
objtool/LoongArch: Mark types based on break immediate code
Add a test that verifies that the currently running kernel does not
report support for any features that are unrecognized by kublk. This
should catch cases where features are added without updating kublk's
feat_map accordingly, which has happened multiple times in the past (see
[1], [2]).
Note that this new test may fail if the test suite is older than the
kernel, and the newer kernel contains a newly introduced feature. I
believe this is not a use case we currently care about - we only care
about newer test suites passing on older kernels.
[1] https://lore.kernel.org/linux-block/20250606214011.2576398-1-csander@purestorage.com/t/#u
[2] https://lore.kernel.org/linux-block/2a370ab1-d85b-409d-b762-f9f3f6bdf705@nvidia.com/t/#m1c520a058448d594fd877f07804e69b28908533f
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
When UBLK_F_BUF_REG_OFF_DAEMON was added, we missed updating kublk's
feat_map, which results in the feature being reported as "unknown." Add
UBLK_F_BUF_REG_OFF_DAEMON to feat_map to fix this.
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Simplify the definition of feat_map by introducing a helper macro
FEAT_NAME to avoid having to type the feature name twice. As a side
effect, this changes the names in the feature list to be the full macro
name instead of the abbreviated names that were used before, but this is
a good change for clarity.
Using the full feature macro names ruins the alignment of the output, so
change the output format to put each feature's hex value before its
name, as this is easier to align nicely. The output now looks as
follows:
root# ./kublk features
ublk_drv features: 0x7fff
0x1 : UBLK_F_SUPPORT_ZERO_COPY
0x2 : UBLK_F_URING_CMD_COMP_IN_TASK
0x4 : UBLK_F_NEED_GET_DATA
0x8 : UBLK_F_USER_RECOVERY
0x10 : UBLK_F_USER_RECOVERY_REISSUE
0x20 : UBLK_F_UNPRIVILEGED_DEV
0x40 : UBLK_F_CMD_IOCTL_ENCODE
0x80 : UBLK_F_USER_COPY
0x100 : UBLK_F_ZONED
0x200 : UBLK_F_USER_RECOVERY_FAIL_IO
0x400 : UBLK_F_UPDATE_SIZE
0x800 : UBLK_F_AUTO_BUF_REG
0x1000 : UBLK_F_QUIESCE
0x2000 : UBLK_F_PER_IO_DAEMON
0x4000 : unknown
Signed-off-by: Uday Shankar <ushankar@purestorage.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Vincent Mailhol <mailhol@kernel.org> says:
Four drivers, namely etas_es58x, hi311x, sun4i_can and mcba_usb forgot
to populate their net_device_ops->ndo_change_mtu(). Because of that,
the user is free to configure any MTU on these interfaces.
This can be abused by an attacker who could craft some skbs and send
them through PF_PACKET to perform a buffer overflow of up to 247 bytes
in each of these drivers.
This series contains four patches, one for each of the drivers, to add
the missing ndo_change_mtu() callback. The descriptions contain
detailed explanations of how the buffer overflow could be triggered.
Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-0-0d1cada9393b@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.
Unfortunately, because the mcba_usb driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:
$ ip link set can0 mtu 9999
After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
to inject a malicious CAN XL frames. For example:
struct canxl_frame frame = {
.flags = 0xff,
.len = 2048,
};
The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:
1. the skb->protocol is set to ETH_P_CANXL which is valid (the
function does not check the actual device capabilities).
2. the length is a valid CAN XL length.
And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.
This can result in a buffer overflow. The driver will consume cf->len
as-is with no further checks on these lines:
usb_msg.dlc = cf->len;
memcpy(usb_msg.data, cf->data, usb_msg.dlc);
Here, cf->len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame->flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!
Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.
Fixes: 51f3baad7d ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.
Unfortunately, because the sun4i_can driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:
$ ip link set can0 mtu 9999
After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
to inject a malicious CAN XL frames. For example:
struct canxl_frame frame = {
.flags = 0xff,
.len = 2048,
};
The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:
1. the skb->protocol is set to ETH_P_CANXL which is valid (the
function does not check the actual device capabilities).
2. the length is a valid CAN XL length.
And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.
This can result in a buffer overflow. The driver will consume cf->len
as-is with no further checks on this line:
dlc = cf->len;
Here, cf->len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame->flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs a
couple line below when doing:
for (i = 0; i < dlc; i++)
writel(cf->data[i], priv->base + (dreg + i * 4));
Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.
Fixes: 0738eff14d ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.
Unfortunately, because the sun4i_can driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:
$ ip link set can0 mtu 9999
After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
to inject a malicious CAN XL frames. For example:
struct canxl_frame frame = {
.flags = 0xff,
.len = 2048,
};
The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:
1. the skb->protocol is set to ETH_P_CANXL which is valid (the
function does not check the actual device capabilities).
2. the length is a valid CAN XL length.
And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
not able to correctly handle and will thus misinterpret it as a CAN
frame. The driver will consume frame->len as-is with no further
checks.
This can result in a buffer overflow later on in hi3110_hw_tx() on
this line:
memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
frame->data, frame->len);
Here, frame->len corresponds to the flags field of the CAN XL frame.
In our previous example, we set canxl_frame->flags to 0xff. Because
the maximum expected length is 8, a buffer overflow of 247 bytes
occurs!
Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.
Fixes: 57e83fb9b7 ("can: hi311x: Add Holt HI-311x CAN driver")
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb->len fits the interface's MTU.
Unfortunately, because the etas_es58x driver does not populate its
net_device_ops->ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:
$ ip link set can0 mtu 9999
After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));
to inject a malicious CAN XL frames. For example:
struct canxl_frame frame = {
.flags = 0xff,
.len = 2048,
};
The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:
1. the skb->protocol is set to ETH_P_CANXL which is valid (the
function does not check the actual device capabilities).
2. the length is a valid CAN XL length.
And so, es58x_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN(FD)
frame.
This can result in a buffer overflow. For example, using the es581.4
variant, the frame will be dispatched to es581_4_tx_can_msg(), go
through the last check at the beginning of this function:
if (can_is_canfd_skb(skb))
return -EMSGSIZE;
and reach this line:
memcpy(tx_can_msg->data, cf->data, cf->len);
Here, cf->len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame->flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!
Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU or
CANFD_MTU (depending on the device capabilities). By fixing the root
cause, this prevents the buffer overflow.
Fixes: 8537257874 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-1-0d1cada9393b@kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Driver configures register to choose controller mode before
setting all channels to reset mode leading to failure.
The patch corrects operation of mode setting.
Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com>
Signed-off-by: Tranh Ha <tranh.ha.xb@renesas.com>
Link: https://patch.msgid.link/TYWPR01MB87434739F83E27EDCD23DF44B416A@TYWPR01MB8743.jpnprd01.prod.outlook.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This issue is similar to the vulnerability in the `mcp251x` driver,
which was fixed in commit 03c427147b ("can: mcp251x: fix resume from
sleep before interface was brought up").
In the `hi311x` driver, when the device resumes from sleep, the driver
schedules `priv->restart_work`. However, if the network interface was
not previously enabled, the `priv->wq` (workqueue) is not allocated and
initialized, leading to a null pointer dereference.
To fix this, we move the allocation and initialization of the workqueue
from the `hi3110_open` function to the `hi3110_can_probe` function.
This ensures that the workqueue is properly initialized before it is
used during device resume. And added logic to destroy the workqueue
in the error handling paths of `hi3110_can_probe` and in the
`hi3110_can_remove` function to prevent resource leaks.
Signed-off-by: Chen Yufeng <chenyufeng@iie.ac.cn>
Link: https://patch.msgid.link/20250911150820.250-1-chenyufeng@iie.ac.cn
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
bugs in the af_alg interface.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEn51F/lCuNhUwmDeSxycdCkmxi6cFAmjL0EIACgkQxycdCkmx
i6ddxQ/+MaVwfK6Bkr0j4irBbTYXmV7jJCFxB13QaQhqW3QHMU/F670+epT7jI47
97sz53E967ORuvAK1K6mcHKhuk3cJ+D/8VRKc/S/vwLy51sB+6qWg0QTKdam7aYD
KrtQKwSM8KHEFmCXl3qdAcbZ80PeqMo1y2vfO4bXr7ng9FETguxQgK2HAdkrnkc+
ksT4r+r2DTIJK8Yvs9MjklMG+vpkvxCVnYZcRu2Q6+GBqsXiLPb0LH4dlv9EO7iR
JdwfxBOggauYE4WGv1XC8GYCp75el5w/VogVLl9NaXB5JVS9sOysvaV0CKtrVGW7
mb0Vb1f8DXXSXIHY0BDC8PImTWX/t87ArsZfCjgUXmPIaWW86nQQSdT7Z4Mabb9E
DK6X/BVvvEOeJYlPDAx8lUOjKN/4DLHbjkf4NHF9eu7PwvVXWj2N8Rq5j32UVU8g
rCt0uB2FvSPH3NpvCAwnHEsnQQFzWdixYUpD/VUYl3mHSrHptQ7wgSpX97XG6/r0
1jzBae7XF0sO9NrIKy9z8ZGyO1qU+WzAZvHHBvSu52S98mHu6K/SkWOxCE77kOqs
QaoWBobW7Bbk1Fg/e6OZscvCdtS4LuDMdvCV1pqXW041hKb8rmPHI5wxRlT6jr7m
Vhf9AAnwBtG2D1etwzvZg6Uu/VQBrbgK18J1qM/j+yBetPe3VM4=
=47U8
-----END PGP SIGNATURE-----
Merge tag 'v6.17-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:
"This fixes a NULL pointer dereference in ccp and a couple of bugs in
the af_alg interface"
* tag 'v6.17-p3' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg
crypto: af_alg - Set merge to zero early in af_alg_sendmsg
crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()
A previous patch fixed a bug where new_prs should be assigned before
checking housekeeping conflicts. This patch addresses another potential
issue: the nocpu error check currently uses the xcpus which is not updated.
Although no issue has been observed so far, the check should be performed
using the new effective exclusive cpus.
The comment has been removed because the function returns an error if
nocpu checking fails, which is unrelated to the parent.
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Reviewed-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The 'isolcpus' parameter specified at boot time can be assigned to an
isolated partition. While it is valid put the 'isolcpus' in an isolated
partition, attempting to change a member cpuset to an isolated partition
will fail if the cpuset contains any 'isolcpus'.
For example, the system boots with 'isolcpus=9', and the following
configuration works correctly:
# cd /sys/fs/cgroup/
# mkdir test
# echo 1 > test/cpuset.cpus
# echo isolated > test/cpuset.cpus.partition
# cat test/cpuset.cpus.partition
isolated
# echo 9 > test/cpuset.cpus
# cat test/cpuset.cpus.partition
isolated
# cat test/cpuset.cpus
9
However, the following steps to convert a member cpuset to an isolated
partition will fail:
# cd /sys/fs/cgroup/
# mkdir test
# echo 9 > test/cpuset.cpus
# echo isolated > test/cpuset.cpus.partition
# cat test/cpuset.cpus.partition
isolated invalid (partition config conflicts with housekeeping setup)
The issue occurs because the new partition state (new_prs) is used for
validation against housekeeping constraints before it has been properly
updated. To resolve this, move the assignment of new_prs before the
housekeeping validation check when enabling a root partition.
Fixes: 4a74e41888 ("cgroup/cpuset: Check partition conflict with housekeeping setup")
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Reviewed-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
